dnd5e icon indicating copy to clipboard operation
dnd5e copied to clipboard

Separate damage lines now shown as 1 line per damage type in the chat roll. Old method divided and labelled per damage line.

Open leborat opened this issue 4 months ago • 26 comments

Damage rolls are now combined into 1 line rather than broken up into their listed damage lines. For example a rogue attacks and it used to display the 1 handed damage roll on 1 line in the damage window, then below that had the formula for sneak attack. It displayed 2 different lines and totals.

now it shows all damaged combined into 1 line like the below image. Makes it very difficult and slow to determine how much damage should be dealt. image

When it used to show this: image

I contacted the author of Ready, Set, Roll and they explained that this is not a change made within their module, but the new system and it isn't something they can modify.

This new change makes using situational damage rolls useless as everything is lumped into one. Many official magic items use situational damage types, and many spells have them as well.

Below is the details tab of the weapon shown in the images: image

leborat avatar Mar 06 '24 16:03 leborat

I'm going to encourage you to see what these looks like in a zero-module environment, which will be quite different. Your old screenshot, for example, is 100% a module with nothing of it being provided by the system.

krbz999 avatar Mar 06 '24 17:03 krbz999

I'm going to encourage you to see what these looks like in a zero-module environment, which will be quite different. Your old screenshot, for example, is 100% a module with nothing of it being provided by the system.

Unfortunately ive already rolled my system back so im not able to test that but the roll from the first image was without ready set roll working properly regardless. If it does look different would you be able to show an image for reference?

I spoke with Mango, the RSR author, and he let me know that the new way it works in this system is to collect all damage of the same type into one group and display it. RSR only displays system calculations, it does not modify.

I dont really care what the interface looks like as long as im able to easily see damage rolls divided. Im sure you can understand that there are several scenarios where having damage breakdowns is convenient. Not to mention reducing the amount of time it takes to calculate if rolls are in 1 window, or not having to find different features/skills/weapons/spells to use what was once all available under 1 click.

leborat avatar Mar 06 '24 17:03 leborat

I'm going to encourage you to see what these looks like in a zero-module environment, which will be quite different. Your old screenshot, for example, is 100% a module with nothing of it being provided by the system.

@krbz999 It doesn't look that different with or without RSR really, for 3.0+. See the comparison here, top being with RSR and bottom being the damage card without RSR. They're the same exact tooltip.

image

Obviously the old screenshot used the old formatting and functionality of RSR that no longer exists, but the main point is that separating damage is now something that the system does in 3.0+ (functionality that didn't exist before so no old screenshot can show it per se), and so complaints about how it does it are a valid system ticket. The arbitrary clustering of damage by type makes no sense given that the vast majority of contextual separated damage that exists in DnD 5e is of the same type (such as Divine Smite's "only on fiends" extra radiant for example).

Why is the decision not left to the user? If they separate it in the item, separate it in the tooltip. If they don't, don't. It feels like a way more sensible approach to things, and better UX design in general.

MangoFVTT avatar Mar 07 '24 07:03 MangoFVTT

"The arbitrary clustering of damage by type makes no sense given that the vast majority of contextually separated damage exists in DnD 5e."

I couldn't agree more with this post. Combining various damage types in the new version of 5e does not make it easier for me as a DM to parse the chat and quickly disperse damage to creatures that have damage resistances/immunities. It feels counterintuitive to have to click on a drop-down to see what previously was given to me at face value.

Dalganoth avatar Mar 09 '24 00:03 Dalganoth

It is definitely a dnd 3.x problem or oversight. I tested with a clean 2.4.1 install no modules and the different damage rolls were seperated just like in ops picture minus the rsr formating. Screenshot 2024-03-19 112036

As a workaround for now i use different types and ignore them to seperate the rolls and use the context field from RSR to show actual damage types.

Bumsbirne avatar Mar 19 '24 10:03 Bumsbirne

The system has always assumed one damage roll is one instance of damage. The types are grouped to give accurate information to the user about how the damage will be applied.

Fyorl avatar Mar 25 '24 16:03 Fyorl

@Fyorl Why can't it be a setting to not group the same type though? What's the difference between showing the user 5+5 instead of 10 for when the damage is going to be applied? Seems like a totally arbitrary limitation for the system, especially because, again, plenty of weapons have situational damage (smite, booming blade, many monsters) that SHOULD be shown separately in the damage total. At least make it a flag that can be passed to the display options so modules can prevent the automatic coalescing of damage if they wish.

MangoFVTT avatar Mar 25 '24 19:03 MangoFVTT

What's the difference between showing the user 5+5 instead of 10 for when the damage is going to be applied?

If a creature has resistance to the damage then applying two instances of 5 damage gives a different result than applying one instance of 10 damage, due to the rules on rounding. Grouping the damage makes it clear that the latter is happening, and not the former.

Seems like a totally arbitrary limitation for the system, especially because, again, plenty of weapons have situational damage (smite, booming blade, many monsters) that SHOULD be shown separately in the damage total.

If there are situational damage bonuses that do not apply to that instance of damage, then they should not be included in the roll, because the total will be wrong. When applying damage via the context menu (a feature that has been in the system for a very long time), the system has always used the total damage number, so the system has always assumed that all of the damage in the roll is included.

At least make it a flag that can be passed to the display options so modules can prevent the automatic coalescing of damage if they wish.

We can look into this.

Fyorl avatar Mar 25 '24 19:03 Fyorl

If a creature has resistance to the damage then applying two instances of 5 damage gives a different result than applying one instance of 10 damage, due to the rules on rounding. Grouping the damage makes it clear that the latter is happening, and not the former.

If this mattered, wouldn't the user put the damage into one damage field? It seems like the whole idea around grouping the damage together should be handled user side by the user combining damage in the item, rather than the roll card automatically doing it for you. Otherwise, what's the point of allowing multiple damage fields to have the same damage type?

But yeah, a compromise in the way of a setting or a flag should definitely exist at least.

MangoFVTT avatar Mar 25 '24 20:03 MangoFVTT

If this mattered, wouldn't the user put the damage into one damage field? It seems like the whole idea around grouping the damage together should be handled user side by the user combining damage in the item, rather than the roll card automatically doing it for you.

There might be global typed damage bonuses in system.bonuses.*.damage or the user might add typed damage in the damage roll's situational bonus field. Neither of these cases are handled by the user combining damage in the Item itself.

Otherwise, what's the point of allowing multiple damage fields to have the same damage type?

There's no downside to allowing it, and it would require more work to disallow it.

Fyorl avatar Mar 25 '24 20:03 Fyorl

Users have always been expected to roll all damage of an item together in one roll, like a Flametongue sword, and implementations are built around this being the expected and wanted outcome. The system does not support alternative damage rolls (beyond the Versatile field) - for now.

That's a different issue though, one that should be solved with a Roll Groups-esque implementation as proposed in #1964

krbz999 avatar Mar 25 '24 20:03 krbz999

If users have always been expected to roll all damage of an item together in one roll, like a Flametongue sword, your system has never shown indications of this before your recent updates. In every campaign I've ever been in since v7 of Foundry, all instances we've had were separated like that for the ease of the DM to calculate damage res of monsters as a glance, and I have been running it the same as well, especially with joint res like fire and poison damage rolls. It also combines different rolls of the same type, which has been different than prior since I would use two other instances of necrotic damage for the toll the dead die calculations at a glance in the chat as well.

Dalganoth avatar Mar 25 '24 20:03 Dalganoth

If users have always been expected to roll all damage of an item together in one roll, like a Flametongue sword, your system has never shown indications of this before your recent updates.

The number you see on the damage card before expanding has always included all of the damage rolled. When applying damage via the system's 'apply damage' context menu option, all the damage has always been applied. These are reasonable indications.

we've had were separated like that for the ease of the DM to calculate damage res of monsters as a glance

The breakdown is still split by damage type.

Fyorl avatar Mar 25 '24 21:03 Fyorl

Yes that is all fine but before the breakdown also split per damage formular and effect even if all were the same damage. It really is helpful to have a breakdown of how the damage comes together especially in higher level games where more and more effects stack together. Now it is just one long calculation and at a glance much harder to determine if everything is correct.

Bumsbirne avatar Mar 25 '24 22:03 Bumsbirne

Pretty nuts that you flag it as 'wont change' when people have been using it this way for years thanks to mods like RSR and the one that preceded it. I think it should be at least looked at to allow mods like RSR to allow for users to have it back to the way it was before. Not having this feature is the sole reason I havent updated and wont. Im sure theres many others that feel the same way. Being able to include all the potential rolls in one click is vastly superior to disallowing it from the way it was before, and to be honest many people i know from the dnd space were expecting it to become a part of the main system.

Every online campaign ive been in has used it this way due to how convenient it is. If i told you that you needed to click multiple times now to accomplish the same thing you previously did in 1, you would probably agree that its a needless change and rather annoying.

Whether or not you feel damage rolls "should roll all damage of an item together in one roll" doesn't mean that what were asking for should be disallowed. Its clear many people want this feature.

Maybe we werent clear either on just how important this is. Like i said above, i dont want to update until this feature gets implemented or once again allowed via mods like RSR. Everyone appreciates the work that goes into the dnd5e module and those that create mods for it. But also saying that something many people seem to ask for "wont change" without much discourse is a bit disheartening. Ive had several people message me asking if i received any out of thread updates or work arounds for the new mode since i asked about it in the discord and posted here.

Maybe in the games you run this feature isnt used or doesnt seem useful. I can tell you in everything ive been a part of its been core and used every single session. All we can ask is that you take the time to listen and allow at the very least mods like RSR to once again do what they did previously. Sure. we would prefer it a part of the main package as a choice but it doesnt seem like that will happen.

Hopefully this topic gets a second look. i know myself and dozens other (that have reached out) are awaiting some positive news for this.

leborat avatar Mar 25 '24 23:03 leborat

The original rolls are still available in the chat message, we are simply modifying copies of them when we display. If a module like RSR wanted to display the rolls separately, that is still entirely possible so long as they are willing to just replace our rendered HTML and use their own.

arbron avatar Mar 26 '24 00:03 arbron

Just wanted to add my two cents that that the automatic summing of various damage types in a single total display is definitely not my expected nor preferred experience as a user, as a player or a dm. It is far too common that players and creatures will have resistances/immunities/triggers to specific damage types. I find myself expanding the card far more often than not when there is more than one damage type, which in my personal experience would mean that having that as the default (or at least facilitating mods to do it) would be preferable. And given that there are examples of cases where even same damage types from an item or spell can have different triggers, it would be nice to simply break it down on a per damage formula line basis.

HavocHank avatar Mar 26 '24 01:03 HavocHank

Just wanted to add my two cents that that the automatic summing of various damage types in a single total display is definitely not my expected nor preferred experience as a user, as a player or a dm. It is far too common that players and creatures will have resistances/immunities/triggers to specific damage types. I find myself expanding the card far more often than not when there is more than one damage type, which in my personal experience would mean that having that as the default (or at least facilitating mods to do it) would be preferable. And given that there are examples of cases where even same damage types from an item or spell can have different triggers, it would be nice to simply break it down on a per damage formula line basis.

For resistances etc., that should now no longer be necessary given the damage application doodad handles all of those automatically so you shouldn't be needing to do any calculations for those yourself anymore.

arbron avatar Mar 26 '24 03:03 arbron

The original rolls are still available in the chat message, we are simply modifying copies of them when we display. If a module like RSR wanted to display the rolls separately, that is still entirely possible so long as they are willing to just replace our rendered HTML and use their own.

@arbron Asking RSR to duplicate code word for word from the base system to create "its own html" (which is literally just the system html but without damage combined) just to bypass half a line of code, when it could very easily be a simple flag on the system that is just passed to the same function to accomplish the same result is a bit ridiculous. Not only is that just bad code design because of redundant duplicate code, it will make the module all the more difficult to maintain, as that function will need to be changed and updated every single time someone changes a part of the identical function in the base system.

All that's needed here is a simple conditional check that skips the aggregateDamageRolls() function call in _enrichDamageTooltip() and uses the full roll array that's given in the parameters instead of creating its own with aggregated rolls. It's a relatively trivial change comparatively, the only work would be making sure it is correctly passed in via options.

image

MangoFVTT avatar Mar 26 '24 15:03 MangoFVTT

For resistances etc., that should now no longer be necessary given the damage application doodad handles all of those automatically so you shouldn't be needing to do any calculations for those yourself anymore.

That's pretty neat! I have only just recently got back into working with foundry after about a year break, so I wasn't aware of that. But while that is handy, I do still feel that the current output is overly simplified in presentation and rigid to work with as a result.

The initial example of the sunsword is a good case for this. There are different formula being used for different purposes, but because of the way the current system works the output gets lumped together indiscriminately. What brought me to look into this and found this thread was my old booming blade and green flame blade solutions not working the way I'd like them to, due to the same issue. The old output screenshot was a roll using RSR and not core, granted. But the core functionality was there to let it exist. It would be nice to have core functionality that was more flexible in the way that it used to be.

HavocHank avatar Mar 26 '24 21:03 HavocHank

Chiming in to add another voice in support. With the help of BR and RSR, I used to use multiple damage rolls of the same type for many different purposes in the past, such as simplifying the application of conditional damage for abilities like Divine Smite and Toll the Dead, or saving on clicks when rolling Magic Missile bolts individually. Now that it no longer works, I've used a few workarounds to keep things going up til now, but I really miss the convenience these modules used to be able to bring in this regard, and always wondered why it wasn't a base-game feature in the first place.

I can think of so many situations where I would want separate damage rolls of the same type on the same item sheet. I can't think of a single instance where I would ever want those rolls aggregated together. (If I did, I would simply put the calculation on the same damage roll, rather than separate it into a new roll.) Can anyone here think of any use cases where it would be good practice to always combine the result of multiple damage rolls of the same type? It feels like it's just a carry-over from the old damage-aggregation method, especially now that the capability was arranged in the base system for damage rolls to be presented separately if they are of different types.

Please reconsider your decision on this request.

TremendoDude avatar Mar 28 '24 17:03 TremendoDude

What I miss about separate damage lines is applying them as a player.

You used to be able to do it yourself in the chat window, at least with the module my game is running, and when you're playing a character with specific resistances to things (A barbarian raging, for an example), it made applying damage a breeze compared to when we tried to move to the new version.

If you'd like to move the "norm" to being fully on one damage line, may I suggest making it an option in some setting? It's a compromise, but it'd surely make everyone happy.

Redfurs avatar Mar 28 '24 18:03 Redfurs

Just wanted to add my two cents that that the automatic summing of various damage types in a single total display is definitely not my expected nor preferred experience as a user, as a player or a dm...

Totally agree.

Split rolls makes things easier as a GM and as a player.

When I count the rolls out to a player I have them right there so I can say "thats 24 to hit, 13 slashing damage and 15 cold damage" If my player has 20hp left they might want to Absorb Elements so I can easily mark that off. If I say "Thats 28 damage" the player may already be resigned to death saves and forget about the spell by the time ive clicked the box to say "of which 15 is cold".

For resistances etc., that should now no longer be necessary given the damage application doodad handles all of those automatically so you shouldn't be needing to do any calculations for those yourself anymore.

I hit a a creature immune to fire with a flametongue longsword and they took all the damage, so im not sure what's going on there but separate damage would mean I just omit clicking that button. Im unsure if this is just me this has happened to but the fact that it could happen is concerning.

The system has always assumed one damage roll is one instance of damage. The types are grouped to give accurate information to the user about how the damage will be applied.

This is assuming that everyone uses a fully automated system. Many people (including myself) don't as we want to emulate the actual tabletop experience. This assumes that all the players use a heavily automated system where rolling attacks automatically removes the damage and does all the checks for walls and cover. It assumes the GM is just an assistant. The system (and developers) making a lot of assumptions here.

If a creature has resistance to the damage then applying two instances of 5 damage gives a different result than applying one instance of 10 damage, due to the rules on rounding.

This seems rather nit picky as the DM would be aware of the monsters vulnerabilities, residences and immunities anyway so if they see the rolls and how they break down, they can do the math there. In fact, when the math is being done and the damage numbers are read out this is usually the players biggest hint that "this isn't very effective"

This current system is not conductive of an optimised game of D&D. It will actively drag the pacing down as GMs need to click the damage roll to see the damage types and how much each damage is worth. No other system does it this way to my knowledge. Even when playing IRL not all players do it that way.

Its-Scottih avatar Mar 29 '24 17:03 Its-Scottih

This actively makes the game worse. At least give module-makers an option to change this.

CrazierIvan avatar Apr 02 '24 12:04 CrazierIvan

Just adding another request to address this issue or ideally provide an option for the system to display/label damage separately instead of always combining the same damage type. Many find it a more efficient play style to include extra information in every attack and simply ignore any parts not relevant to the current situation (as opposed to adding extra attack steps when that extra information is needed).

Consider this attack with a Giantslayer Quarterstaff in Roll20 compared to versions of Foundry with and without modules:

Roll20_FVTT_Attacks

Options in Roll20 allow me to click the attack once and display all the information I want in one place for easy reference. I can see two attack rolls (in case dis/advantage applies or just use the left number if not), damage with custom labels (so it's easy to see which only applies to Giants), and critical damage (if either roll is a 20) as clearly separate numbers so it's easy to ignore if it doesn't apply. If I need to see the actual damage dice rolled, it's a matter of hovering over each number to see a pop up.

Better Rolls lets me have almost that exact experience in Foundry v9 and Ready Set Rolls previously got fairly close in v10 and 11, but unfortunately it's farther away now with changes to the DnD5e system. To get the same information for the attack in Foundry with no modules, I need to sacrifice a lot of screen real estate and:

  1. Click the item on the sheet/bar to produce the item chat card.
  2. Click the attack button on the chat card.
  3. Click the advantage button on the attack pop up window.
  4. Click the expand button on the attack chat card (to see the actual rolls).
  5. Click the damage button on the item chat card.
  6. Click the critical button on the damage pop up window.
  7. Click the expand button on the damage chat card (to see the actual rolls).

In the kind of long combats my tables like to run with dozens of combatants, inefficiency really adds up. Being able to glance at a single chat card and easily parse which information applies to the situation is a great time saver and being able to separate the same damage type into different contexts is important for that.

Sometimes you're using some feature that ignores critical hits or facing an enemy that does the same and seeing how much extra damage those criticals could have otherwise done is a big part of the fun.

Sometimes you think you're smiting a Fiend, but they're actually a Fey in disguise... it would be nice to immediately know how much of that radiant damage the DM shouldn't apply without immediately giving away why.

Sometimes you think you're stabbing a Humanoid, but they're secretly a shapeshifted Dragon... it would be nice to immediately know how much extra piercing damage the DM should apply without asking for an additional roll and spoiling the surprise.

Sometimes you're smashing Goblins, Giants, Ogres, and Hobgoblins all in the same turn and it would be nice to not have to make extra clicks each time your target is a Giant, but instead just be able to click once per attack and easily see which extra bludgeoning damage applies to that situation.

I understand that some people don't want to add up damage after an attack or manually subtract hit points from tokens, but for those who shy away from full automation there are good reasons to consider damage types and contexts before applying damage. I also understand there's an underlying design philosophy that perhaps seeing damage roll results upfront could influence some player's decision of whether to use a feature affecting the attack roll. However not all tables share those concerns nor play the same way. Options for more styles of play are a good thing to include in the system (and a bad thing to remove, even if only by removing easy support for modules that do the heavy lifting in those areas). Please reconsider this issue.

Dumbhuman avatar Apr 02 '24 22:04 Dumbhuman

I assume this is just a dead thread now as the devs have stopped interacting and have given no word on any updates and marked this as "Won't Change" which is disappointing. I guess I'll be on 2.4 until I find something that can split the damage or a new VTT.

As Arbon said:

The original rolls are still available in the chat message, we are simply modifying copies of them when we display.

But they won't give us the option on how the damage is displayed as that is not how they want us to play our games. They want module developers to make it harder to maintain and update their code. Why would they do that? That doesn't seem right. Why would you actively try and make the end-user experience more difficult?

Its-Scottih avatar Apr 21 '24 22:04 Its-Scottih