Rewrite the Dice Roller

Ok, I know this sounds like an absurd suggestion at first, but hear me out. I am not suggesting that the dice roller is "broken" as it is, or that the random function needs work. The current dice roller is pretty good, and the random function is rock solid. But I think we can probably agree the dice roller has some issues. I have seen suggestions once or twice for changing something in the dice roller to work in a way that the user thought was more intuitive, and the response was basically "Sorry, that would break this, that and/or the other thing because of how it is written". Usually the things that would be broken were the macros that are already written for the way the system works now, so it certainly made sense to keep the dice roller the way it was. However, as more features have been added, some of them seem to have been limited by the need to maintain compatibility with the way other things were already handled. One example would be that we cannot combine math only rolls and regular rolls when using the drop/keep function. Another is the inability of the system to handle anything other than a basic number as the target when checking for success. Or the fact that [] to add information to a roll dont work inside an inline roll. I am sure there is a reason we can list multiple specific numbers for a die to re-roll on, but we can only tell it to explode on > or <, but I can only guess what the reason is(no system anyone knows of calls for weird exploding like that?). One of the new suggestions you added, was to implement support for new dice mechanics(specifically re-roll once, I suggested re-roll a selectable number of times). But I have to ask, does it really makes sense to add more functions to the existing dice roller? It seems like you have already added a 2000sq.ft second level to a house where the first level is only 1000sq.ft and are looking to expand it even more. What I propose is not getting rid of the old dice roller, but creating a "Dice Roller 2.0" and having it be a selectable option in the campaign settings. Maybe it would be the default for new campaigns after it launches, maybe it wouldn't. Either way I think you should take a good look at all the mechanics you want the dice roller to support, and decide what is the best way to set up the interaction between each mechanic, and how the order of operations(or any other aspect of the dice roller) might need to change to make everything work together seamlessly. Then you might want to give some thought to how it could be designed to allow you to add new features without breaking anything it already does, but still let the new features work seamlessly with the old(I know, that's the hardest part).

I like this idea. As long as it doesn't lose any functionality, it should be reasonable to write an API script that would automatically convert existing macros to the new format.

See the following for reasons for which this needs to be done: <a href="https://app.roll20.net/forum/post/1276194/better-s" rel="nofollow">https://app.roll20.net/forum/post/1276194/better-s</a>... <a href="https://app.roll20.net/forum/post/1276271/better-s" rel="nofollow">https://app.roll20.net/forum/post/1276271/better-s</a>... Essentially, GURPS needs to be able to efficiently compare a total of dice to a value. "/roll 3d6 &lt; 12" doesn't work, because it compares each d6 to 12, resulting in 3 successes, where there should only ever be 1. There's virtually no practical way to take an attribute pool, a skill pool, sum them, add bonus dice, add a modifier, and roll them against a target. You need to use a lot of % and @ symbols to specify your character name and the attribute name respectively; it's impossible for characters to type in response to a GM asking you for a "Charisma & Martial Arts" check, to impress that cute vampire girl you're on a date with by defending her honor from some mouthy werewolves. It should be nearly as simple as "/roll charisma + martialarts d10 + 5" or so, but it isn't.

/roll {3d6}&lt;12

Yeah, that should work in theory, but doesn't. It will give you 3 successes. They really screwed the pooch when they decided that curly braces should only total rolls when there's a comma present.

/ roll [[3d6]]&lt;12

HoneyBadger , /r [[3d6]]&lt;12 will not work because the left side of the inequality requires a roll. However, this will work: /r {1d1-1+[[3d6]]}&lt;12

I think the example above is a good way to make my point about the dice roller needing to be rewritten. HoneyBadger gave the 2 obvious ways to do what Tenacious Techhunter wanted to do, but neither of them actually works. The only ways to get the result Tenacious Techhunter is looking for are to use Gauss' work around, or add something else inside the curly brackets like so /r {3d6,18}&lt;12 which gives an automatic failure. Both the methods above are kinda silly as workarounds to get a simple success check. If anyone else has examples of things that seem like they should work, but don't, or things that just don't work the way you think they should, or require silly/overly complicated workarounds, post them here. I will try to figure out a new syntax/order of operations for the proposed dice roller. That would probably make it a lot easier for the devs to review/implement if we can get some more votes, or if they decide it just actually does need to be done.

Roger A. said: The only ways to get the result Tenacious Techhunter is looking for are to use Gauss' work around, or add something else inside the curly brackets like so /r {3d6,18}&lt;12 which gives an automatic failure. It's worse than that. /r {3d6,18}&lt;12 doesn't work, because you can't mix both dice rolls and math in a group. You'd have to do /r {3d6,18*d1}&lt;12

More generally, Roll20 is just missing a lot of math-related rolling features. We can't roll something X amount of times and add it together (like in GURPS where automatic weapons hit multiple times), the order of operations is utterly illogical, we don't have access to math stuff like sqrt() or log(). A lot of important bits are hacked together, like how we do min and max functions using kh1. Dice pools in particular can behave unexpectedly because of the order of operations. No ability to save a dice result for later use in the same macro. I'm gonna upvote this just as a general "we want more math and rolling" suggestion. Lots of little things that would be pretty easy to implement and make handling character sheets easier without relying on an API script to make them work.

I've encountered a few situations where exploding dice need to be rolled a limited number of times... how it is currently, if the die lands on a number that would explode it will continue to explode and roll again until no more dice explode. Some systems only explode on the initial roll and others only explode up to X times.... Also you missed something when you were testing exploding on specific numbers... 1d6!4 will only explode on 4. Personally I would rather see these changes made to the existing dice roller rather than have a new alternative one made... most of the stuff that will "break" should some changes be made can easily be fixed... most of them I'm certain people would rather use the simpler and more reliable solutions that an improved dice roller would bring with it.

Moving my original post and vote here to keep the suggestions for roll-related expansion in one place / one pool of votes; it overlaps Roger's suggestions mostly in the sense of pointing out the limitations of not being able to mix fixed expressions with random variables in a roll group, and one of the workarounds I've been using is almost identical to Brian's reply. Teh L. said: Amongst the basic math functions, I'd quite like to see min and max. I am currently using a crazy workaround for those; more on that in a bit. While one is at it, pow (or p^q notation) might as well be present, and perhaps even log. sqrt could be convenient though is obviously not essential if pow is present. Grouped rolls do not quite do what they say in the Dice Reference; when trying to 'implement' my own max function so I could roll d6 and set a result lower than 3 to be equal to 3, I tried {3,d6}k1 and it threw an error with "Cannot mix M and sum rolls in a roll group". I'm not quite seeing/understand why not; intuitively, {3,d6} looks like it should do the equivalent of /roll 3 and /roll d6, then operate on those results. I eventually achieved what I wanted by using {3d1,d6}k1, which I refined to {d0+3,d6}k1 so as not to spam the chat with a load of summed 1s, but {3,d6}k1 or max(3,d6} would make a lot more sense. In a similar vein, I can't find any way at all to roll e.g. 2d6 then use the total result in a success test, e.g. succeed if the sum is greater than 8. 2d6&gt;8 will apply the &gt;8 test to each d6 individually, so will always return 0 successes, but {2d6}&gt;8 does the same thing as if it were {d6,d6}&gt;8, where intuitively (and by the description of roll groups), it should compute the 2d6 total first. {d0,2d6}&gt;8 is a workaround, which gets even more clunky with a less-than test, since one needs {d0+9,2d6}&lt;8. Finally, a conditional operator which interacts with successes would also be quite handy, e.g. "if 2d6&gt;10 succeeds then roll d8, else roll d6". Notation-wise, I'm thinking something like {2d6}&gt;10 ? d8 : d6 to mimic most popular programming languages, if the ? doesn't interfere with the prompt system. Obviously, if the above workaround were still needed then this would be {d0,2d6}&gt;10 ? d8 : d6.

I also wish the dice roller would support exploding dice in the other direction (IE exploding 1s and 20s)

Keep voting, people! :D

I realize this is an old post but the formula I've been using to compare a dice pool versus a target number (and if I'm reading this correctly is basically what you want) {3d6,0d6}kh1&lt;12. I use this basic formula for Champions and Aliens.

I recognise this suggestion and it's discussion are relatively ancient however nearly everything mentioned is still problematic. The required fixes and quality of life improvements likely represent a major refactor of the dice roller. However I believe significant improvement is possible that remains backwards-compatible. The issues raised Mixing of roll-types is disallowed Consider the following macro [[ {3, 1d6, 3d6&gt;4, 6d6mt} ]] The roller is adamant that M, Sum, Success and Match rolls cannot be mixed within a group-roll. This is particularly problematic with M rolls since it is highly common to want to roll a die but with a minimum or maximum value. This problem also happens in sub-rolls of groups and also generally in roll expressions. [[ {1d6 + 3d6&gt;4 + 4d6mt} ]] [[ 1d6 + 3d6&gt;4 + 4d6mt ]] However all these roll-types can coexist within the same roll with additional group-roll syntax [[ { {3}, 1d6, {3d6&gt;4}, {6d6mt} } ]] [[ 1d6 + {3d6&gt;4} + {4d6mt} ]] This makes the restriction feel arbitrary as a result since the workaround doesn't require altering the results or how it runs. However this is not the workaround you're most likely to see. The more common workaround would be to put all the rolls inside their own nested roll; this is much slower as each roll has to be handled individually and is less desirable as it hides the dice rolls. Reducing the syntax required avoids these problems. Not all Roll Modifiers can be specified multiple times There are three that can be used multiple times Reroll (r), Critical Success (cs) and Critical Failure (cf) But the others can only be specified once. The most glaring of which is Reroll-Once (ro) since it's counterpart can be used multiple times. For something 'simple' such as rerolling once 1's &amp; 6's on a d6 (A question that's cropped up multiple times) you need something like [[{(1d5r1+100)*{1d3&gt;2},1d6}k1%100]] and that needs to be done per die which can be a lot in d6 based games. The target success/failure modifiers are also frequently asked over. The need for double successes or failures is a common help topic that can result in some very large complex macros or require the creation of several rolltables to handle all the possible cases. For comparison this &amp;{template:default} {{[[ (?{Dice Pool|1}-$[[22]])d9&gt;?{Target Number|7}f1cs0sa + 2*$[[43]]d0&gt;0 ]] Successes}} $[[[[{ {?{Dice Pool}d10&gt;10},{20} }kl1+1]]]]] [[[ [[ [[ [[ [[ [[ [[ [[ [[ [[ [[ [[ [[ [[ [[ [[ [[ [[ [[ [[ [[ [[0]] ]] ]] ]] ]] ]] ]] ]] ]] ]] ]] ]] ]] ]] ]] ]] ]] ]] ]] ]] ]] [[20]][[19]][[18]][[17]][[16]][[15]][[14]][[13]][[12]][[11]][[10]][[9]][[8]][[7]][[6]][[5]][[4]][[3]][[2]][[1]][[0]] [[20]][[19]][[18]][[17]][[16]][[15]][[14]][[13]][[12]][[11]][[10]][[9]][[8]][[7]][[6]][[5]][[4]][[3]][[2]][[1]][[0]] could become &amp;{template:default} {{[[?{Dice Pool|1}d10&gt;10&gt;?{Target Number|7}f1]] Successes}} if only multiple target numbers could be used. Exploding mechanics I'd say repeatedly gets asked how to explode on non-consecutive numbers, the answer being don't. Instead work out your explosion count first and the values afterwards leaving you with some rather opaque results. This is an area I feel cannot be succinctly represented as the mechanics involved can vary wildly but being able to be specified multiple times is a good start. Keep/drop mechanics has an occasional topic on how to keep both the highest and the lowest values, something the current syntax doesn't allow but easily done if you could specify both kh and kl together. Also being able to dh and dl together would simplify instances where just middle values are kept. Although I cannot say what the expected behaviour of specifying any specific version twice would be. This is also an area that could benefit from an extended syntax but I don't feel is within the scope of this suggested change. Dice matching (mt) could also benefit similar to the target number syntax. Being able to count the number of matches with additional matches for matching greater amounts and/or higher values. One example being counting each distinct match Consider the following [[ {1, 1, 1}mt ]] This would return 1 but the count of distinct matches is 3 (1st &amp; 2nd, 2nd &amp; 3rd, 1st &amp; 3rd) With multiple mt modifiers this could be written [[ {1, 1, 1}mt3mt3mt ]] Comparing summed dice pools with a target number Whilst allowing the mixing of roll-types would help with the current workaround it is still prone to errors since the dummy number has to be chosen with care based on the comparison and target number used, doubly so if a failure target is also used. Especially since if some variation of the target and failure numbers are consecutive the workaround then fails since the dummy number would always be in one of the ranges. My recommendation is to look at the current dice pool syntax for single sub-roll success checks [[ {3d20+5}&gt;21 ]] This would add 5 to each d20 roll then compare against the target of 21. However this isn't the only syntax that this works with. It can be used with rolltables [[ {3t[custom_die]+5}&gt;21 ]] It even "works" with success/match rolls [[ {3d20&gt;0+5}&gt;21 ]] [[ {3d20mt+5}&gt;21 ]] Although in this instance the success/matching doesn't actually occur and the raw dice values are used for the final comparison. In fact the only roll-type that doesn't work with it is the group-roll. If group-roll syntax were allowed the GURPS style roll would become [[ { {3d6} }&lt;12]] Whilst not perfect since it still has the learning curve associated with single sub-roll success check it is at least consistent with the idea that appears in other circumstances of group-rolls using total values and with the theme of more permissive rolls of this suggestion. It would also allow a greater range of roll handling making rolls such as the following possible [[{ {d20,10}k1 +3 +[[1d4]][bless] }&gt;?{Target|15} ]] The equivalent current workaround being [[ {d20+3,{10+3} }k1&gt;[[{?{Target|15}-{1d4},{0} }k1]] ]] Which scatters the modifier across the macro, hiding the 1d4 aspect completely, confusing the actual target value and is generally a mess. Backwards compatibility The fixes and enhancements I've listed above all involve syntax that currently wouldn't work and then making it work. As such it would be possible to make these changes without affecting any current usage. However I cannot rule out that breaking changes could occur. The original suggestion called for a Dice Roller 2.0 to be a selectable campaign option. I feel this isn't the best way to handle the different schema since it could mean a macro that works in one game could be broken in a different game. It would also mean that old-style and new-style macros couldn't coexist and as such would be a barrier to entry and generally cause confusion around macro writing. My recommendation would be to create a new roll option. Currently only &amp;{template:} and &amp;{noerror} exist. This seems like the perfect way to differentiate between the two schemas and I'd suggest &amp;{roll_schema:2} unlock the Dice Roller 2.0 and &amp;{roll_schema:1} could be used to force old-style handling. It also gives a way to manage further changes to the dice grammar without breaking existing functionality. As for which is default is something for Roll20 to decide and change as they see fit. In summary Allow different roll-types to be mixed (Both in groups and generally) Allow all modifiers to be used multiple times Allow group-rolls in single sub-roll success checks Create a new roll option &amp;{roll_schema:} for backwards compatibility

I want to tag in&nbsp; my own already posted proposal &nbsp;to this thread. While my proposal was specific to critical highlighting, having in general the ability of "grouping" multiple dice rolls and formulas and considering the final result as the output of an individual dice roll would have many applications (including the mentioned one for GURPS)