5E - Aura Effects

[bmos]

Though when I noticed it no longer working I had to rewrite all my effects to insure (in current case IF: !CUSTOM(Object)) was not processed.

This is the sort of thing that is to be expected when major version numbers are iterated.
October 2023 was the release of v3 which was a very substantial rework of how the extension functions.

I also looked back at the old code and don't see a function called "saveisAuraApplicable." As this is weirdly named, I think it might also have been part of your workaround/modification?

[SilentRuin]

This is the sort of thing that is to be expected when major version numbers are iterated.
October 2023 was the release of v3 which was a very substantial rework of how the extension functions.

I also looked back at the old code and don't see a function called "saveisAuraApplicable." As this is weirdly named, I think it might also have been part of your workaround/modification?

Any overridden function from anywhere should have the original function available to be called back so you don't stomp the original code and what it or others have done. The only exception to this is if the function cannot be overridden without completely being replaced - which usually means its a function not written friendly to being overridden (evil in my book).

Any original function I store as save<name of function> so that I can call it before, after, or alternately with my changes.

The function I'm overriding does exist - its "isAuraApplicable" - which was a very handy and reasonable hook to have so that others could insure aura does not process things it should not process. I understand the entire functionality shifted and was divided etc. - but it used to work last year. I would think it a reasonable request to have anything aura is trying to "process in range" be checked for the true/false of this function if it should actually be processed. It was a good idea. And still is. Why I overrode it (as I was informed to do at the time I "think" but of course to long ago to be sure).

[bmos]

v3.3 posted with improvements for when auras are recalculated (when adding/removing tokens)
https://github.com/FG-Unofficial-Dev.../v3.3-hotfix.1

Thanks to rhagelstrom for doing most of this improvement!

EDIT: There was a bug with the faction filter, so I pushed a hotfix.

[SilentRuin]

Well done on the add token to map processing auras. Works like a charm. Consistent behavior now no matter when aura is applied.

If you do end up putting isAuraApplicable back into play - or something new comes up - let me know. For now I'm just leaving my override to try to tell aura what is applicable to process even though it does not work.

[SilentRuin]

Removed this post - Never mind - figured it out.

[bmos]

If you do end up putting isAuraApplicable back into play

AuraEffect.isAuraApplicable does still exist and is still called by AuraEffect.updateAura.
https://github.com/FG-Unofficial-Dev....lua#L189-L216
https://github.com/FG-Unofficial-Dev....lua#L246-L258

I'd recommend looking it over to see if perhaps it's a different change like the supplied arguments, what is returned, etc

[SilentRuin]

AuraEffect.isAuraApplicable does still exist and is still called by AuraEffect.updateAura.
https://github.com/FG-Unofficial-Dev....lua#L189-L216
https://github.com/FG-Unofficial-Dev....lua#L246-L258

I'd recommend looking it over to see if perhaps it's a different change like the supplied arguments, what is returned, etc

As I stated - it is no longer being called. Yes it still exists in your code, but that has been rewritten so that when the AURA is processed for say a FOG cloud (or most other auras) it is not being processed.

Fog Cloud; (C); LIGHT: 20/20 darkness; AURA: 20 all, point, gray; Fog Cloud_; IF: !CUSTOM(Object); OBSCURED: physical

Now the updateAura and this function did used to get triggered for this I believe - but the new branch of code no longer does any filtering with it. Whether it is because new if statements have been added for the holistic use of updateAura and isAuraApplicable was mistakenly kept in that to block it out - or whether whole new branches of processing occur - I'm not sure. But it for sure no longer gets triggered. No definition of the aura should escape this check when being processed for any reason IMHO.


Tomorrow Ill double check its still getting overridden but Debug.printstack() at top of override is for sure not being triggered. If somehow raw aura call is getting called (would need to add print at top of your function) then something very weird is going on.

[bmos]

If you look at my second link, you can see that it is definitely still being called.
The only way it would not be called is for tokens that have no CT node.

[rhagelstrom]

If you look at my second link, you can see that it is definitely still being called.
The only way it would not be called is for tokens that have no CT node.

Which is probably SR's problem, too early in the call chain. If the token isn't linked to the CT entry yet, that function isn't going to behave properly.

[SilentRuin]

I guess next time im fooling around on computer ill try to put printstack in your code and rebuild auras and see if its being called as it never seems to trigger on my override. I can just put a normal aura effect with one ct token in range and see if it triggers. Not sure why targets in aura would not be triggering call but obviously im doing something weird as you guys tell me it is being called, so i will start with raw Aura no other extensions and verify it is called for fog cloud like aura effect - then if it is see why override is not called.