[extension] Advanced Spell Damage Extension - casting spells at higher level.

[bratch9]

v3.13 Updated NPC effects line evaluation when used in 'innate spells'

note. Innate Spells need to start with both the 'level' and 'cast level' text. See attached.

-pete

[Vaall]

Hey,

I'm really confused to tell you that this doesn't work for me.
I think this is because I'm using the MeAndUnique extension (5E - Kit'N'Kaboodle) to create the spell effect and you not.
If it's really too much of a hassle, don't bother. I will find another solution of my own.

Thanking you

Edit: As an alternative, I found the CT scroll 5e extension which allows me to increase or reduce the damage that is registered into an effect. So there is no urgency/obligation to think about a solution to my problem.

[bratch9]

v3.14 update for FGU 4.5.0 changes.

[Arnagus]

Hello Pete,

I found a bug in the 'Advanced Spell Damage' extension, reproduced with only this extension loaded (plus your Core extension), and verified by loading my usually stack except this (and only this) extension for the bug to vanish. Ruleset is 5e.

When you apply an effect from the (spell) actions to another token on the CT, which is containing the "LIGHT: 0/y" condition, it only applies "LIGHT: y".
Screenshot 2024-05-25 170746.png

When using the "LIGHT: x/y" format, it applies "LIGHT: x y" (which screws up the overall format).
Screenshot 2024-05-25 173216.png

Can you please have a look? It seems it's the "/" character which is not correctly processes in the parseEffectComp(s) function, but I cannot test as your source contains unprintable characters which my editor does not like: Screenshot 2024-05-25 181315.png

[bratch9]

Hello Pete,

I found a bug in the 'Advanced Spell Damage' extension, reproduced with only this extension loaded (plus your Core extension), and verified by loading my usually stack except this (and only this) extension for the bug to vanish. Ruleset is 5e.

When you apply an effect from the (spell) actions to another token on the CT, which is containing the "LIGHT: 0/y" condition, it only applies "LIGHT: y".
Screenshot 2024-05-25 170746.png

When using the "LIGHT: x/y" format, it applies "LIGHT: x y" (which screws up the overall format).
Screenshot 2024-05-25 173216.png

Can you please have a look? It seems it's the "/" character which is not correctly processes in the parseEffectComp(s) function, but I cannot test as your source contains unprintable characters which my editor does not like: Screenshot 2024-05-25 181315.png

I can take a look and see if I can re-create it and locate a fix. As I think the light format was not part of the effects system back in the day for the extension, I'm sure its just needs a slight update to current code standard.

-pete

[bratch9]

Not sure why your editor can not show the '#' letter... but thats the 'number' of items in they array of words..

I use notepad++ for most of my edits, and lists the file as a utf-8 format... Maybe your editor is listing in a different format.

Taking a look now, but I can already see that the delimiters have changes to also include the '/' which might be the only change...

I'm just setting up a replication without extensions, and then I'll enable my extension. I've added debug on input and output of this function in the ruleset and my extension. So will be able to see just how different things end up..

-pete

[bratch9]

v3.15 should fix the effect 'LIGHT' parse issue.

Was just additional delimiters that were missing in my code.. This seems to have been an issue for about 2 years looking back on the ruleset changes which added the extra delimiters.

So good spot on this one... I guess many people do not add light into effects lists while also using my extension. ( Or just not many people using my extension, which I think will be the case !! )

-pete