Improper/inequivalent Parsing of Dice Modifiers

[aaclayton]

Originally in GitLab by @tmun

Environment Details

• Foundry VTT Version: 0.8.9
• Operating System: Windows/Linux (Ubuntu)
• How Are You Using Foundry: Native Application (Electron)/Firefox
• Which Game System: PF2e Development/PF2e Release (Confirmed in SWNR by Spice_King)
• Modules Enabled?: No

Issue Description

The following rolls should be equivalent: /r 3d20ddh, /r 3d20d1dh, /r 3d20dldh, /r 3d20dl1dh, /r 3d20dhdl, /r 3d20dh1dl,/r 3d20k2kl, and /r 3d20kh2kl

Of those rolls, any in the format d#dn# do not resolve (3d20dldh and 3d20dhdl - they resolve as 3d20d) but the dice modifiers page says that d and dl are equivalent.

[aaclayton]

I think I may be a bit confused here about which are the bugs and which are correct.

• 3d20ddh - dropped 3 (lowest), dropped 19 (highest), result 16 = CORRECT
• 3d20d1dh - dropped 7 (lowest), dropped 13 (highest), result 10 = CORRECT
• 3d20dldh - dropped 4 (lowest), did not drop highest, result [19,16] = INCORRECT
• 3d20dhdl - did not drop highest, dropped 1 (lowest), result [12,14] = INCORRECT
• 3d20k2kl - kept highest 2 (11, 4), kept lowest (4), result 4 = CORRECT

So it looks like there is a problem here, but that problem doesn't map directly to your comment of:

Of those rolls, any in the format d#dn# do not resolve (3d20dldh and 3d20dhdl - they resolve as 3d20d) but the dice modifiers page says that d and dl are equivalent.

Are we on the same page?

[aaclayton]

Originally in GitLab by @tmun

Yes. I was trying to figure out a good way to write it. It was late. But that's correct. It seems like when parsing when the roll parser hits a d and then an l or an h character and the character following it is not a digit it ignores everything that follows in that Dice Term.