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

Roll Highlighting while using kh/kl syntax

There is unexpected behavior with roll highlighting (red/green box around the result of an inline roll) when using the "keep highest" or "keep lowest" functionality.  If I make the following inline roll:  [[{1d20, 1d20}kh1]], I would not expect that a result of 1 on the die not used would highlight the roll, however it does.  Here is a screenshot illustrating what I mean. In the above case the 6 was used and the 1 was not, however the output is quite confusing because a 6, while a terrible roll, is not a critical failure.  It would be much clearer to only use roll highlighting on the actual result of the kh/kl syntax, rather than all dice used in the roll.
1459166943
Kryx
Pro
Sheet Author
API Scripter
Same behavior with the normal syntax of [[2d20kh1]]
1459191342
Phil B.
Forum Champion
Sheet Author
Yup, that would definitely make more sense. I've documented it on our bug list and will fix it when I get a chance.
1459209054
Silvyre
Forum Champion
Thanks, Phil!
1459556766

Edited 1459556805
Phil B.
Forum Champion
Sheet Author
I've made this fix, as well as graying out all of the "dropped" dice when using the "keep" mechanic. Makes it a lot easier to read and it will also no longer mark the end result as a crit/fumble when one of the dropped dice is triggering it. Since it's close to the weekend the fix won't go out until probably early next week, then you can check it out on dev.
1459561012
Silvyre
Forum Champion
Great!!
Awesome, thanks Phil!
Thanks for this, Phil. Would it make sense to extend the same fix to the "reroll" mechanic (e.g. [[3d6r1]])?
1459891115
Phil B.
Forum Champion
Sheet Author
That's a good point Joe, that would make sense. It'll be an easy fix since I've already got the logic there. I've added this back to the "work" list and will make this last change when I get a chance.
Thanks, Phil!
I disagree with this change. It is not system agnostic at all and favors game systems that only use the numbers being kept. Greying out numbers dropped will make it more difficult for players and GM's needing to see all the numbers for whatever reason.
1459893657

Edited 1459893709
Kryx
Pro
Sheet Author
API Scripter
How is showing the correct border color not system agnostic? 2d20kh1 wants one roll. It doesn't matter if the lower roll rolled a 1. The number is still there and can be seen when hovering, it just doesn't change the border color now if it isn't the final result.
HoneyBadger said: I disagree with this change. It is not system agnostic at all and favors game systems that only use the numbers being kept. Greying out numbers dropped will make it more difficult for players and GM's needing to see all the numbers for whatever reason. Are you objecting to the "keep" change, the "reroll" change, or both? I must admit to ignorance of systems not derived from some flavor of D&D. Can you provide an example of a situation where this change would be problematic? Also, have you seen how the greying-out looks in practice? The "keep" change is already live on the servers. The greyed-out numbers are still in the same place and quite visible, just grey instead of white.
My own game system requires the use of all dice in a roll even if they're dropped. They determine whether a roll is a hit, crushing blow, or critical hit. Having one or more dice greyed out is simply annoying to me as a player and GM. Greying out dice is simply not system agnostic.
1459899782

Edited 1459899829
Phil B.
Forum Champion
Sheet Author
All of the numbers are still easily readable. Even if you need to read all of the numbers you still should be able to tell, at a glance, what number are being added together to make the end result which is what this achieves. If the numbers are too dark, we can always change that.
1459899908

Edited 1459899983
They're not readable at a glance to me. I have to actually take a moment to concentrate on the dice to read them. As they were before, I could quickly glance over, see what I needed, and look back at the camera as I interpret the results. 
This change also makes using inline rolls with keep/drop mechanics more difficult to use since low rolls on the dropped dice won't trigger the highlights. That means anyone running an rpg system that uses all the dice for whatever reason will have to give up any roll templates, scripts, or macros that use inline rolls or constantly have to mouseover the rolls to see if the dropped roll was a number that would have triggered the highlight.
HoneyBadger said: This change also makes using inline rolls with keep/drop mechanics more difficult to use since low rolls on the dropped dice won't trigger the highlights. That means anyone running an rpg system that uses all the dice for whatever reason will have to give up any roll templates, scripts, or macros that use inline rolls or constantly have to mouseover the rolls to see if the dropped roll was a number that would have triggered the highlight. While I understand the concern, the same can be said for it's current implementation for games that don't use a keep/drop on rolls... it makes roll highlighting confusing at best.
1459902100

Edited 1459902144
The change is not system agnostic. Roll20 is supposed to be system agnostic. It wasn't a bug and didn't need to be fixed. And it's only confusing the first couple times and then you get used to it. It's easier for users to ignore the highlight than it is to have to mouseover every roll.
As Phil said, if this is a readability issue (i.e. the exact shade of grey we are using is not readable or something like that) we will take a look and see what we can do. But I don't see an issue whatsoever with the underlying change being "dice that aren't used in the final total calculation are differentiated from other dice." There's nothing that's system specific about that, it matches the behavior of the dice engine as specified by our Dice Reference (dropped means "don't use in final calculation"), and it matches the behavior we were already using elsewhere in the application -- it was already the case that when you used keep/drop for a /roll command (as opposed to an inline roll) we fade the dice that were dropped.
This change favors game systems that don't use the dropped dice over dice that do use the dropped dice. That goes against being system agnostic, regardless of readability. And it makes inline rolls harder to use for those systems that do use all the dice, whether they were dropped or not.