DndMonsterAttack: no period after damage type

[pepper-jk]

Using extra in DndMonsterAttack with only only "basic" damage specs, requires the manual addition of a period and a space in extra.

Meaning there is no period and space after the damage type.

comparison:

code that works:

%Default values are shown commented out
\DndMonsterAttack[
  name=Bite,
  distance=melee, % valid options are in the set {both,melee,ranged},
  %type=weapon, %valid options are in the set {weapon,spell}
  mod={+3 + PB},
  %reach=5,
  %range=20/60,
  %targets=one target,
  dmg=\DndDice{2d4 + 3},
  dmg-type=bludgeoning,
  %plus-dmg=,
  %plus-dmg-type=,
  %or-dmg=,
  %or-dmg-when=,
  extra={. If the target is a Medium or smaller creature, the camel tries to grab onto the targets equipment and the target must succeed on a DC 9 + PB Dexterity saving throw or suffer a -2 penalty to AC until it uses have its movement action to fix his armor}
]

code source

[BrianCriswell]

That is by design. The extra field's contents are inserted before the final period with no processing whatsoever, so you typically need to insert the ". " manually. The decision to not automate whether a period was included was one of simplicity. The current design can handle any use of the extra field, while automatically inserting a period would give weird output for attacks that do not do damage (such as the rug of smothering's smother attack). The current implementation avoids getting caught out by weird edge cases.

[pepper-jk]

Maybe insert the "final period" before the extra field then?

It is way more intuitive to add a period at the end of the sentence than at the beginning.

What about the manual insertion of a space in the beginning? It works for other fields right?

[BrianCriswell]

I think it got caught out by the goblin hurler in Storm King's Thunder or another edge case. I don't fully remember why this implementation was chosen in the end except that it avoids trying to guess what every possible valid attack action will look like. The heavy lifting of formatting the extra field is left to the user.

At this point, modifying this behavior would cause a breaking change and not one I am keen on having to check inputs on to cover whether a warning/error needs to be raised based on whether the user's legacy input is incompatible with the new behavior of the function.

[pepper-jk]

Sorry, I misunderstood. What you are saying is you want to support other use cases like "damage, extra text" or "damage-extra text". I get that now. I do not see a situation, where this would be the case though.

Especially as you support or-dmg with or-dmg-when, which already supports the "damage, "-thingy.

But at least I get your point now.

I still disagree though, as it is a pain to add ". " every time and this is most likely 99% of attack actions. And for the 1% where you need it you can also use the normal MonsterAction, where you can write freely. So why support it in the MonsterAttackAction where it is a pain?

To be honest this kinda makes me just want to use MonsterAction in all cases that I would use extra for.

At this point, modifying this behavior would cause a breaking change ...

Yes. You are right about that. I guess it is to late now then.

Maybe you could consider this change, if there is a major revision of other things as well, that make breaking changes and you make a big version jump?

[BrianCriswell]

Now I remember why we chose this: we had to support all of the following situations:

1. ". . . damage. If the target is a creature. . . "
2. ". . . damage, and the target is. . . "
3. "Hit: The creature is. . . "

Placing a period at the end of damage only handles number 1. The only place where we can reliably place a period is at the end of the entire attack.

The purpose of the attack functions is to avoid mistakes in typing out and formatting entire stat blocks. We support or-dmg, or-dmg-when and all the other optional bits to cover common situations such as versatile weapons and help the user avoid errors where we have established precedent of what the output should be.

[pepper-jk]

The purpose of the attack functions is to avoid mistakes in typing out and formatting entire stat blocks.

I understand that, but this is also why I disagree. I had 2 formatting issue while using extra as it is now:

1. No period and space before my extra field text.
2. Two periods after the extra field text.

That was not very intuitive and I feel like this could be handled better.

Another alternative would be to add a separator option, that defaults to the current behavior, but allows the user to switch between comma, period and nothing. In any case after the separator there should be a space.

[BrianCriswell]

I am sorry that it takes some time to get used to the implementation of the extra field. I have heard your feedback. If a situation arises where a change to the implementation would make sense, we will take it, but it is not changing at this time.

[pepper-jk]

No, problem. I get that you do not want to break compatibility.

Thanks for considering it in the future. I hope this issue helps people to figure this out as well.