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
This post has been closed. You can still view previous posts, but you can't post any new replies.

#rollWasCrit() and dice modifiers to attack rolls

1429085774
Kryx
Pro
Sheet Author
API Scripter
Problem: When using #rollWasCrit() the attack is considered a crit if any dice crits. For example if you add a d4 to your attack modifier (Bless in 5e) and that 4 is a crit then the attack appears as a crit and the roll template adjusts accordingly. This slows down play considerably to see if it was actually a crit. Reproduction: Add a dice modifier (example d4) to an attack roll that uses roll templates and #rollWasCrit(). Browser: Should happen on all browsers, but I am using Chrome Version 41.0.2272.118 m I feel like this may be closed as this is the expected behavior, but it shouldn't be the expected behavior.
1429088654
Lithl
Pro
Sheet Author
API Scripter
Mark said: I feel like this may be closed as this is the expected behavior, but it shouldn't be the expected behavior. Why not? The roll did crit when you rolled the 4 on a d4. Why would you expect a system-agnostic platform to automatically know to care about a d20 critting and not care about a d4 critting? The critical success point syntax may solve your problem, though. See if #rollWasCrit captures your 4 when you roll d4cs0.
1429089281

Edited 1429090538
Kryx
Pro
Sheet Author
API Scripter
Brian said: Why not? The roll did crit when you rolled the 4 on a d4. Why would you expect a system-agnostic platform to automatically know to care about a d20 critting and not care about a d4 critting? I agree that a "fix" shouldn't affect other systems, but assuming all dice in an attack roll can influence a crit is not a good way of handling it as that is not system agnostic. It causes undesired behavior on the most popular systems used by roll20 (PF, 5e, 3.5 based on the numbers they released). *Note: I don't remember any dice mods to atks in 3.5 or PF, but they may exist or may be houserules Ideally the system should be able to identify between the roll and modifiers. Modifiers should not make the attack roll crit unless specified. The critical success point syntax may solve your problem, though. See if #rollWasCrit captures your 4 when you roll d4cs0. d4cs0 does indeed fix this. Thank you. Though it still causes a "fumble" on a 1. Any idea how to fix that? EDIT: d4cs0cf0 seems to fix both crit success and crit failure.
1429138863
Kryx
Pro
Sheet Author
API Scripter
There is a workaround, but I do not consider this resolved. It's clearly a bug for many systems.
Not a bug. The current method is system agnostic. Anything in a roll is considered part of that roll and you have to exclude them via cs0cf0 to match your preferred system.
1429210824

Edited 1429211000
Kryx
Pro
Sheet Author
API Scripter
HoneyBadger said: Not a bug. The current method is system agnostic. Anything in a roll is considered part of that roll and you have to exclude them via cs0cf0 to match your preferred system. Best quote I can find on system agnostic relating to IT: Device agnostic is a description for computing components that work with various systems without requiring any special adaptations . Assuming all dice in an attack can crit is not system agnostic. That's very specific and requires adjustments in many systems. Therefore not agnostic.
Roll20 doesn't know what is or is not an attack roll. Roll20 only knows that something was a roll that may or may not include more dice than one. Thus, system agnostic is not treating any specific die within a roll any differently so as not to give preference to any specific game system.
1429211762

Edited 1429211809
Kryx
Pro
Sheet Author
API Scripter
HoneyBadger said: Roll20 doesn't know what is or is not an attack roll. Roll20 only knows that something was a roll that may or may not include more dice than one. Thus, system agnostic is not treating any specific die within a roll any differently so as not to give preference to any specific game system. Well, assuming all dice can crit/fumble is not agnostic either. Semantics aside. It works this way and is unlikely to change. In that case the best way to handle this is to have a shorter syntax to prevent any crits (fumbles or successes) as I suggested in the suggestion forum: <a href="https://app.roll20.net/forum/post/1841393/create-n" rel="nofollow">https://app.roll20.net/forum/post/1841393/create-n</a>...
Assuming they all can roll min/max is system agnostic. System agnostic means the parser does not care what system you're using. A die rolled min or max and is highlighted to let you know.
1429213047
Kryx
Pro
Sheet Author
API Scripter
HoneyBadger said: Assuming they all can roll min/max is system agnostic. System agnostic means the parser does not care what system you're using. A die rolled min or max and is highlighted to let you know. I've already quoted above to define system agnostic. Every dice being able to crit succeed/fumble does not meet that definition as it is not the desired behavior in many systems. It requires modification, therefore not agnostic.
You quoted something for IT, not game systems. Has no relevance here.
1429216340

Edited 1429216798
Stephen Koontz
Forum Champion
Marketplace Creator
Sheet Author
API Scripter
Compendium Curator
This isn't really the place for a discussion on the definition of system agnostic, so I'm closing the post. But, to not leave without answering your question Mark, in order to stay system agnostic the same behavior needs to apply to all dice in all rolls. In this case we have the default behavior set to crit on the highest and fumble on the lowest, with optional syntax and tools to adjust as needed. Whether the default should be no crits or fumbles, unless you use syntax to turn them on, is fine to discuss and we welcome any feedback. The bug report forum just isn't the place for that.