That’s perfectly fine, but if you have a system that has 3 systems of rarity that could get a bit confusing for not only the player but the system.
Several scripts running at the same time (complicated, I’m assuming) could lag, crash, or even straight up freeze the server.
Edit: I don’t do rarities so this is new to me lol.
Now that I think about it, no, that would not be efficient.
If you were to do this and not follow this post, you would have to do different percentages each to prevent the server from being overloaded.
And, of course, every single scripter knows that server problems = client problems and therefore client lag.
Edit: Client AND server lag. Sorry, I’m tired today.
But yours didn’t add up to a 100% either.
Instead of using purely percentages, you can try using weights per rarity instead which is a lot easier than trying to squeeze numbers to 100% in summary. The whole weight shall be a number that is the summary of all weight per rarity. You can for instance distribute a number of 50 000 to each rarity and 1 in 50 000 is quite low already.
Thank you for pointing that out. I’ve edited my reply.
So people would accept it, if I said that an item the rarity is like 25% of appearing in the list, but not saying where it would land on the yellow bar, because it would be impossible to calculate that, as there are lots of different devices, each with different scales(what I am saying is the yellow bar doesn’t land smack dab in the middle of the box, as you can see in the video… so in summary I cannot calculate the actual drop, just if it will appear in the list
As I said, I am not good with rarities/percentages so I have no idea about this lol.
All I know is math and scripting (mostly datastores).
You’ll have to ask someone else for that, sorry!
Apologies for acting like a know-it-all. I actually wanted to point out that you could have multiple rarities, each with “cramped” chances, but as long as each value is increased carefully, the system is fine.
Worth noting that this is not what the virtual random items policies says. What it demands is that if Robux is involved with your lootboxes, you must fully disclose the chances available to get certain items and make a fair algorithm.
If it’s impossible to directly or indirectly buy a lootbox with Robux, then you do not need to make the chances fair and you don’t need to disclose the chances of earning anything either (that then just becomes a question of ethics, not rules/legality). If you can use Robux, you must fully disclose chances. Using Robux is defined as either directly buying a box with Robux or buying boxes with currency that can be purchased with Robux.
Ideally if you’re doing your generation right then regardless of what you do, the percentages of getting all types of items will naturally add up to 100%. There’s no way it’ll go over unless you’re doing very primitive generation like a Random statement or something. For this, it’d be good to look into weighted generation. Here’s a good article on that:
If you want a good resource to help you map out weighted chance, check out LootPlan.
Yea, I just assumed that the loot box would be something that could be indirectly purchased with robux. I forgot to mention hat you don’t have to disclose the odds if it’s not bought with robux in any way.
This is where I run into a problem because mine do use robux, indirectly. The thing is I can’t disclose the exact drop, because my loot box works like this, it makes a list and scrolls through that list until one of the boxes lands on a yellow bar. The problem is the percentages and randomness, only apply for the next box appearing in the list, but not if the bar will land on it.
You can see what I mean if you watch the video.
robloxapp-20210314-1837373.wmv (2.9 MB)
Can I leave like that, or should I have a note at the bottom saying “*Percentages are for the chance of the item appearing in the list, NOT whether or not that item will land on the bar.”
Would that be acceptable?
Would that also be a problem with “fully” disclosing the chances?
You need to find a way to make complete disclosure regardless of any reasoning you have; if you can’t compromise and be able to disclose exact percentages then you need to take Robux out of the equation and find a different way to monetise.
In your case disclosing the appearance chances is sufficient but you also need to add that note about the bar at the bottom. Full disclosure is required if Robux is involved is the rule here. In your system, the rarity of an item determines its frequency to appear on the wheel and you’ve clarified that the chances affect its appearance on the wheel rather than the chances of the selection bar landing on the item (though the latter is implicit).
This all being said, the loot of your system should be predetermined and the spinning should only be a way of visually showing the player obtaining the item. The moment the player buys a box, the server should be selecting a random loot according to the given chances and then the spin animation should only be there as a visual; the spinner should not actually determine what item the player gets.
If you’ve ever played Phantom Forces, they have the box animation you’re talking of. There’s a reason why when a player obtains a legendary item (melee weapon + a skin from it) from a crate, the message is sent to the chat before the player themselves see the spinning animation completed. The loot is predetermined, the spin is purely for the sake of visuals.
Ok I see, I think I’ll go find a different method, I used the crate system from SpooksHD, and I don’t think I am going try to change it, so I’ll find another kind. Thanks!