Truestrike not calculating properly

[Raekur]

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
The cantrip will appear as a button in the description box with most weapons once a spellcaster has the cantrip active.
Clicking in this button will generate a roll to hit and a roll for the weapons standard damage.
The output is where the problem appears. The calculation will be based upon the standard method (Str or Dex).

Expected behavior
The calculation should be using the spellcasting stat modifier instead of Strength or Dexterity. In the example provided it should be intelligence (+3) whereas it is using dexterity (+2).

Screenshots

Browser Info (please complete the following information):

• Browser chrome
• Version 144.0.7559.133 (Official Build) (64-bit)

[dmportella]

can you link your character you used for this?

[Raekur]

can you link your character you used for this?

The situation is repeatable with any character that uses truestrike. I have repeated it on many characters.
These test characters are High elf wizards. First screenshot is a 1st level, 2nd is a 5th level to activate extra damage die.
https://www.dndbeyond.com/characters/161126286

Test with a 5th level character https://www.dndbeyond.com/characters/161126657

[kristiandueholm]

I have had a look at this one. The root cause for the regression is likely the changes made to True Strike in the 2024 rules. True Strike went from being a concentration advantage against a target, to using your spell modifier (and choosing original or radiant damage).

This is not implemented as far as I can tell.

I have had a look at this, and while I am slower than @dmportella, I have a proposal for an implementation in the works.

[dmportella]

We need to support both versions of course.

It's a spell too, so I can't be done with any features or references.

Could get very hard to manage it, it can be a problem where it's not worth doing any changes.

I will wait for you proposal before I look in to it.

[dmportella]

Like I suspected, we cant currently determine which version of True Strike someone is using from the weapon property spell group buttons.

To support this properly, we would need a user configurable setting that tells us whether to use True Strike (2014) or True Strike (2024).

I would rather avoid adding a setting just for True Strike, because:

• it could snowball into a long list of per spell settings, and
• since we dont scan/parse the spell list, we also cant reliably “force 2024” based on the character being 2024 - some tables mix 2014 spells with 2024 characters (and vice versa).

Workarounds for now:

• Create a custom weapon action that uses your INT modifier for attack and damage, or
• Create a custom attack modifier that adds the difference, and hotkey it for quick toggling.

I dont think we can visibly do anything about the attack modifier at the moment.

[Raekur]

As far as it being implemented, if you look at the 5th level example, the Radiant damage is listed, the 2014 version does not include this. Towards determining which aspect to include, the 2014 version is tagged as Legacy while the 2024 version is not in the spell list. Another possible way to seperate them is class selection (2014 version vs 2024 version) if that is possible in the detection routine. For a work around I just customize the weapon and add bonus to hit and damage. Where this might be a problem is with AOO since it would not include the spell casting stat modifier and be just base (unless you have warcaster). Yes, D&D just had to make everything complicated, I think it is a hobby of theirs. If you look at the spell list most all of the 2014 spells now include a Legacy tag with the exception of ones from expansion books like Tasha's and Xanathar but I dont think any of those are presenting any issues as far as I know.

[kristiandueholm]

@Raekur I think the hurdle here is, that we do not parse the spells list, and as such we do not have any information available on versioning when rolling.

Although, after some testing I can see that only the 2024 True Strike injects a button on weapons. As such, it could be assumed that the 2024 version is being rolled, when executing rollItem. It is that assumption I have been working with for a solution, but is that too far fetched @dmportella ?

If it is far out of reach for now, is there some way we can hide the button?

[dmportella]

@Raekur I think the hurdle here is, that we do not parse the spells list, and as such we do not have any information available on versioning when rolling.

you are correct, we do not parse the spell list.

Although, after some testing I can see that only the 2024 True Strike injects a button on weapons. As such, it could be assumed that the 2024 version is being rolled, when executing rollItem. It is that assumption I have been working with for a solution, but is that too far fetched @dmportella ?

If it is far out of reach for now, is there some way we can hide the button?

The problem is not the group handle call, it is the handle special spells function that is called on every spell cast. We would have no way of figuring out which is being cast. Other then starting parsing all spells.

there is another issue that someone can have both spells in their character sheet.

dndbeyond is not always easy sadly.

[Raekur]

@Raekur I think the hurdle here is, that we do not parse the spells list, and as such we do not have any information available on versioning when rolling.

Although, after some testing I can see that only the 2024 True Strike injects a button on weapons. As such, it could be assumed that the 2024 version is being rolled, when executing rollItem. It is that assumption I have been working with for a solution, but is that too far fetched @dmportella ?

If it is far out of reach for now, is there some way we can hide the button?

You are correct in that the 2024 version inserts the button, the function that is missing is that the equasions to hit and damage are still using the normal call for either str or dex based on the presence of finesse and not replacing it with the value from spell cast modifier. The 2014 version does not have the button so I doubt using that spell will cause any issues moving forward and just focusing on the button call might be a better approach.

[Raekur]

Oh, and Thank you all Very much for looking into this. Your work on and creation of this entire extension is very much appreciated.