Bug related to today's hotfix about custom DC

Hi :)

I just wanted to update my extensions for the hotfix of today :) Thanks for the fix about custom DCs, but I see still some problem, the following code

Code:

---

            local nDC = getActionSaveDC(nodeAction);
            if nDC ~= nCustomDC then
                DB.setValue(nodeAction, "savedctype", "string", "fixed");
                DB.setValue(nodeAction, "savedcmod", "number", nCustomDC - nDC);
            end

---

should be

Code:

---

            DB.setValue(nodeAction, "savedctype", "string", "fixed");
            DB.setValue(nodeAction, "savedcmod", "number", nCustomDC);

---

The previous version was about when the savedctype was not going to be fixed such that the "native DC" had to be taken into account (which though resulted into some scaling problems when the corresponding ability of the (N)PC got edited afterwards, as reported (at least this is what I think was the problem)

But when it is now defined as fix one does not need to subtract nDC :)

Though I understand the idea of the previous code. Because DC numbers in brackets of spell entries of NPCs are just meant as a result of the value, they are still dynamic with the ability. The previous code allows this dynamic, but not the new one; I just tested with the old code and it is dynamic and behaves as expected (in a positive way) (for both, PC and NPC)

Hence, I am not sure what exactly happened with the reported module, the reported things here, https://www.fantasygrounds.com/forum...l=1#post529128, looks like as if nDC got not subtracted in that module (as if it was 0?), when I understand it correctly. I hope I didn't provide a red hering related to this bug (sorry if so; when I wrote my suggestion related to this problem, then I didn't look at the code again, was just a spantaneous idea) :)

Therefore I am still more on the side of the first code, and I have no idea what went wrong in the reported module. May be related to how it got created?

Sorry for the stress-testing :) Now I took a closer look :) (but also a very edge case I think)

Best,

Kelrugem

Thanks for the catch on that one. Fixed.

JPG

I think I may know what happend:

1. The spells got added to the NPCs before its abilities got adjusted. The way how the code is coded would then result to nDC= 0 in that moment. Thus, the full custom DC is added to the mod.
2. The problem: The custom DC in such spell entries are calculated with the correct ability value of the NPC entry
3. When then the ability gets entered, then the advantage of having the mentioned dynamic results into that the full ability mod is accounted into the DC, again

Hence, when one wants to have the advantage of the dynamics of the old code, then it is necessary that the abilities of the NPCs are entered before the spells get added (by a parser for example; manual drag&drop of spells is normally without the custom DC, from some library). Difficult for me now to decide what is the better design. The new code is of course less error-prone for module developers, while the old one allows dynamic (imagine the NPC buffs their ability and then the DCs have to increase, and so on.)

Quote:

---

Originally Posted by Moon Wizard

Thanks for the catch on that one. Fixed.

JPG

---

Cool, thank you :) I just also posted something about what I think went wrong in the creation of the reported module. Not sure which of the mentioned designs you prefer :)

Yeah, it was originally built, such that it assumed that it could calculate the DC. (i.e. existing NPC and spell list) However, if the tag existed on a new import, the DC wasn't calculated yet and returned 0 initially, and then updated correctly after that. This caused the DC to essentially be doubled (or close to it).

Regards,
JPG

Quote:

---

Originally Posted by Moon Wizard

Yeah, it was originally built, such that it assumed that it could calculate the DC. (i.e. existing NPC and spell list) However, if the tag existed on a new import, the DC wasn't calculated yet and returned 0 initially, and then updated correctly after that. This caused the DC to essentially be doubled (or close to it).

Regards,
JPG

---

Aaah, oki, thanks for the clarification and quick fix :)