Running score method: Primitive, simple, but not as good as others
| Min |
Max |
| -2147483648 |
2147483647 |
Details
The simplest solution is not to use an actual random generator at all, because it's not really needed. The randomness can come from a user input instead.
What I mean by that is that you can have a rapidly changing scoreboard objective, and evaluate the score at the moment a button is pressed.
First set up your randomness objective using
scoreboard objectives add RNG dummy
There used to be a stat.playOneMinute which would automatically increase it by 1 every single game tick without another command needed, and it will not be the same for every player (if that is not desired, resetting it for everyone works). However, because updates have removed this statistic, we would need to implement our own commands to increase it by one tick.
1.13+ : scoreboard players add @a[scores={RNG=9..}] RNG 1
1.12- : scoreboard players add @a[score_RNG_min=9] RNG 1
Now create a fill/setblock clock and have it run
1.13+ : scoreboard players set @a[scores={RNG=9..}] RNG 0
1.12- : scoreboard players set @a[score_RNG_min=9] RNG 0
and you're done. To use your random numbers, make one command block for every single outcome and include [score_RNG=X,score_RNG_min=X] with your target selector arguments, where X is the score to use, running from 0 to 8(!). Trigger all of these at the same time. For example
...
/give @a[score_RNG=4,score_RNG_min=4,team=PlayingTheGame] diamond_sword
/give @a[score_RNG=5,score_RNG_min=5,team=PlayingTheGame] dirt
...
If your command does not use a target selector argument, you can (ab)use execute for that, e.g.
/execute @a[score_RNG=4,score_RNG_min=4] ~ ~ ~ setblock 1 2 3 stone
Nowadays in 1.13+, it is advised not to use this as there are much better alternatives and it requires a running function. This is however the most easy way to generate random numbers.
Best Answer
When entering NBT, the provided data type mostly doesn't matter. It gets converted to the correct type for that field automatically.
Regular numbers become
ints, so entering e.g. 3000000000 results in the value overflowing and becoming negative, even if it then gets converted to along.Numbers with decimal points become
doubles, including.0and0..Just a
.seems to be accepted as a number, but I wasn't able to figure out what type. It plays along with other numbers labeled "i", but that shouldn't be a number suffix. Strange.In arrays (like
Motion) only one number type is accepted, even if they are compatible for conversion. So[1.0,2.,3d]is accepted, but[0.0,0.0,0.0f]is not.Apparently arrays don't convert from whole number types to floating point types. Summoning an entity with
Motion:[1,0,0]does not give it motion.The remaining types are trivial: Array, compound and string. They don't have type suffixes.
Now to the other side of things: When reading NBT, you do have to match the correct type. Because your input gets implicitly converted to
intordoubleif you provide no format suffix and only then it's compared with the existing NBT, it often fails.So even if you summon an entity with
Motion[0.0f,0.0f,0.0f], you still can't test for it withMotion[0.0f,0.0f,0.0f], you needMotion[0.0d,0.0d,0.0d].