Keep highest and drop lowest rolls display red and green when they shouldn't

I found that when you set up a roll to drop the lowest or keep the highest, that the roll output still shows the color of those that were effectively discarded from the result of the roll. This leads to confusion for situations like fumbles or critical failures. I believe that this should be changed if it doesn't interfere with any other game mechanics. For example, you roll 2d20kh1 for an attack. If one of those d20 rolls is a 1 then the output in the chat window will highlight the number red, even though your other d20 roll is not a 1. What do you think? Magik

Not a bug, expected behaviour. There are game systems where even the discarded numbers are relevant.

Ok, good. I appreciate the response!

Magik said: Ok, good. I appreciate the response! No problem. Good example is D&D 5e and halflings with the lucky trait. They get to re-roll ones, so without knowing there was a one... they wouldn't know they get to re-roll it without mousing over.

Well, I am referring to the use of the roll mechanics where you have Roll20 reroll automatically for you. In your example, you would use the 1d20r1 mechanic and you would see the result you expect. In my situation, I'm asking Roll20 to roll 2 dice then keep the higher. It can still show the dice in the mouse-over, but I don't want the chat window to show a red result when the higher kept roll isn't a 1. I'm just looking for some improvements in the color output. No change in the mouse-over is required.

Not possible without use of the API.

True, which is why if this makes sense for all games then the Roll20 Devs can make a server side change. That's what I'm shooting for.

For your suggestions, we offer the Suggestions & Ideas forum, which is based on voting from the whole community. Please review our Forum Voting wiki page for more information on how voting works, and our Suggestions & Ideas Posting Guidelines for the added expectations above and beyond our standard Code of Conduct . Since, as HoneyBadger point out, this is not a bug, I'm going to mark this issue as resolved. Thank you.