3D dice results are not random

[Weissrolf]

I think people are much less likely to notice a 0.5% difference in frequency of a single result than they are a trend in results (periods of low or high numbers being more frequent).

It's more of a 1.5% absolute difference, which results in over 16% relative difference. Quite large actually.

Here is an emphasized version using a median noise filter (radius 4).

FGU 3D dice




FGU Instant Dice extension




Random.org



Like I wrote before, I do not consider these results "imperfections", but a plain broken/bugged state.

[Neovirtus]

Like I wrote before, I do not consider these results "imperfections", but a plain broken/bugged state.

And you are welcome to that opinion, I was merely stating mine.

[Weissrolf]

I was not questioning that, sorry if it "sounded" that way.

But FGU's 3D dice are far beyond real dice "imperfections", those dark band distributions should not happen with even bad random generator (/die isn't so shiny either). And real dice are thrown very differently (more variable!) to how FGU does it, so real imperfections lead to different results compared to FGU's engine. Not to mention that every single real die is weighted differently, too, while in FGU they are all the same.

[eporrini]

I am by no means requiring perfection in the randomness of rolling, but clearly this really needs to be addressed. I don’t care about physics vs random generation, only that rolls are “reasonably random”. Moon Wizard has indicated this will not be addressed, which is concerning. My players (and I) LIKE seeing rolls, so simply using the extension would feel bad and take away from the game. For me the randomness of /die is “sufficiently” random.

A couple of questions and a suggestion.

Questions:

Do these ratios apply to the “seeded” rolls being made by dragging dice and virtually throwing them in the box?

Do these ratios apply to drag/drop roles that apparently generate some kind of “seeding” when u lift a die?

Suggestion: Can we brainstorm fixes that solve this while allowing rolling (both in the box as well as drag/drop or click) to continue to be used? Preferably something relatively easy to implement for the dev team?

[Jiminimonka]

I am by no means requiring perfection in the randomness of rolling, but clearly this really needs to be addressed. I don’t care about physics vs random generation, only that rolls are “reasonably random”. Moon Wizard has indicated this will not be addressed, which is concerning. My players (and I) LIKE seeing rolls, so simply using the extension would feel bad and take away from the game. For me the randomness of /die is “sufficiently” random.

A couple of questions and a suggestion.

Questions:

Do these ratios apply to the “seeded” rolls being made by dragging dice and virtually throwing them in the box?

Do these ratios apply to drag/drop roles that apparently generate some kind of “seeding” when u lift a die?

Suggestion: Can we brainstorm fixes that solve this while allowing rolling (both in the box as well as drag/drop or click) to continue to be used? Preferably something relatively easy to implement for the dev team?

Moon Wizard said that is doesn't need attention because its not broken.

My players have streaks of good rolls and streaks of bad rolls. And that also happens when you are sitting at a table with real dice.

Humans used to think the world was flat too (and that is making a come back recently).

Also dice rolls are not totally random which is why casino dice that are made one special machines so each side is exactly the same dimensions as all the others so the dice rolls are more equal. Eventually they get discarded (is it 10,000 rolls?) and sold off. D&D dice are not as precise nor do they ever have to be.

I'm unsubbing to this thread because its kinda doing my head in.

[Weissrolf]

Do these ratios apply to the “seeded” rolls being made by dragging dice and virtually throwing them in the box?

Since I had to collect data for a very high number of rolls it was not possible to seed them using mouse-movement. My players click-role and any ruleset automation also do not use mouse-movements.

Do these ratios apply to drag/drop roles that apparently generate some kind of “seeding” when u lift a die?

I don't know about the lifting part, but I read that you have to generate a minimum of mouse-movement for it to be used for rolling. If you move too slow then a fixed minimum is used (or maybe a RNG minimum). My results only apply to click-roles and automation, which always use random/minimum movements.

[Weissrolf]

Edit: I fixed the Instant Dice extension to use a proper seed. It used the same C library Rand() function that /die should be using. This means that it uses different implementations on each OS (Windows/OS X/Linux).

[Weissrolf]

I am currently in the process of editing the "Instant Dice" extension. It currently used the math.random function to create random numbers and depends on the system it is being run on. I may either include a changing seed or try to implement a better PRNG to begin with. Since I am not experienced in coding LUA this may take some tries.

[Weissrolf]

3D dice, 1 mio. rolls, distribution of D20 results:

#16: 5.49%
vs.
#1: 4.62%

There are 18.8% more #16 than #1 results (54863 vs. 46177).


It will take time to get either Instant Dice extension or Random.org distribution for comparison. I expect both to be much better, though.

Instant Dice, 1 mio. rolls, distribution of D20 results:

#6: 5.05%
vs.
#7: 4.98%

There are 1.8% more #6 than #7 results (50453 vs. 49631).

[eporrini]

If another D20 1m was rolled using 3D is the expectation it would gravitate into the same pattern as the prior 1m?

Does anyone think this can be fixed just by adding some kind of additional seeding to the auto and click rolls?