Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
Create a free account

Large number of rolls / rolls with many sided dice unsupported

1599688642

Edited 1599688779
Setup: Google Chrome 64-bit v85 / OSX 10.15.6 / Javascript enabled Issue: Roll20 doesn't support rolling many (&gt;999) dice or rolling many-sided (&gt;9999999) dice. This can be reproduced by typing a large roll&nbsp;(e.g. `/roll 99999d6`)&nbsp;into the chat window -- if you look at the sum totals they do not converge to the expected value. It would be great if the Roll20 interface supported higher rolls or at the very least gave players some indication their roll has been modified.&nbsp; Mechanism : Looking at the client side code (`app.js`), it seems like large rolls are silently rounded down. The `MAX_NUM_ROLLS` and `MAX_ROLLS` variables set the limits for these roll parameters. This check appears to only exist on the client side -- larger rolls can be performed by dispatching POST requests to the `" <a href="https://dice.roll20.net`" rel="nofollow">https://dice.roll20.net`</a> server.&nbsp;The `dice.roll20` server supports up to 2^48 sided dice and can complete up to ~50,000 rolls before experiencing performance regressions. It should be possible to support even larger numbers of rolls by switching the roll outcome representation from an array of results to a frequency map. Console log : The console log reported no errors.
1599690748

Edited 1599690834
Gold
Forum Champion
You can roll those kind of numbers the same way we used to roll d100 by using 2d10's. You can easily roll a&nbsp; d10 d99, d10 d99, d10, d10 d99, .... and get large integer results like that. This seems like a stop-infinity safety net for the site &amp; dice server. How is it a bug?
It's still a bug.&nbsp; A bug is any flaw in a program that causes it to produce an unexpected result. Roll20 silently changes the invoked roll without notifying the user. When someone makes a high roll they receive the results of a different roll. I would think this would qualify as an unexpected result. Of course you can roll for each digit separately but it really shouldn't be necessary. Even very low-end modern computers are perfectly capable of generating more than 1000 random numbers quickly, so I would be shocked if this was the bottleneck. Now, there should obviously be limits to the size of the dice rolls. However, the limits that are currently in place are really low and it is not communicated to the user when they are violated.
1599698260
Oosh
Sheet Author
API Scripter
Grellward L. said: Now, there should obviously be limits to the size of the dice rolls. However, the limits that are currently in place are really low and it is not communicated to the user when they are violated. Why do you need to roll 1000d9999999? What could you possibly need that level of precision for? Please point me to a set of rules which justifies these probabilities. Of course Roll20 are going to impose a limit so you don't have a bunch of people rolling ridiculous dice and causing lag on the roll server for everyone else. You even seem to recognise that in your comment, but still think it's a bug? It seems to be a feature that is currently achieving its goal (ie stopping unnecessary abuse of the free dice roll server). Why would Roll20 have any interest in removing the limit, to cause more complaints from their users?
You can get Excel to give you the wrong answer as well. Try writing&nbsp;=1000000000000001/10 and check the result. Why? Because it is oriented towards a standard consumer and it is accurate enough to handle everyday calculations, like the household budget, the kcal you eat etc. There is a reason why scientists use super computers to get the correct results when dealing with huge calculations. Back in the good ol' days, programs would crash when the user provided data outside of the intended use, but today we have better ways to handle that.
Grellward L. said: It's still a bug.&nbsp; A bug is any flaw in a program that causes it to produce an unexpected result. Roll20 silently changes the invoked roll without notifying the user. When someone makes a high roll they receive the results of a different roll. I would think this would qualify as an unexpected result. It isn't a bug if it is simply a capacity limit; those are just system capacities.