5E - Aura Effects

[rhagelstrom]

1. Last year BMOS told me to use isAuraApplicable to override so I could add my NOTTARGETING effect checking to insure aura did not target things it should not. This year I noticed this function is no longer even being triggered. Please insure this is put back in the relevant loops it needs to check on processing things within range of an aura. What follows is the override that I was told to do - and used to work...
   

   -- Override AURA to respect NOTARGETING effect
   function isAuraApplicable(nodeEffect, rSource, rTarget, aFactions)
   	local isAura = saveisAuraApplicable(nodeEffect, rSource, rTarget, aFactions);
   	if isAura then
   		if EffectManager.hasEffect(rTarget, "NOTARGETING") then
   			isAura = false;
   		end
   	end
   	return isAura;
   end

2. When a CT token is added to the map the aura effects are not being processed. This makes things like BCEGs SAVEA (and likely other stuff) not get applied when the CT entry with aura effects has its token placed on the map. This is because currently AURA only processes an effect when its added or modified (not when it already exists). This creates inconsistent behaviors. The only work around is to manually change aura effect in CT or turn it off and on to get it to process after token is placed. It should be overriding one of the add token hooks to insure aura effects are processed after it is placed.
   

To be fair this was never a thing. Diff of HEAD vs e44373d which is Feb 6, 2023

-function isAuraApplicable(nodeEffect, rSource, token, auraType)
-       local rTarget = ActorManager.resolveActor(CombatManager.getCTFromToken(token))
+function isAuraApplicable(nodeEffect, rSource, rTarget, aFactions)
+       local rAuraSource
+
+       local sSourcePath = DB.getValue(nodeEffect, 'source_name', '')
+       if sSourcePath == '' then
+               rAuraSource = rSource -- Source is the Source
+       else
+               rAuraSource = ActorManager.resolveActor(DB.findNode(DB.getPath(DB.getChild(nodeEffect, '...'))))
+       end
+
+       local aConditions = { 'FACTION(' .. table.concat(aFactions, ',') .. ')' }
+       local aCondHelper = {}
+       if EffectManager4E then
+               aCondHelper.remainder = aConditions
+               aCondHelper.original = DB.getValue(nodeEffect, 'label')
+       else
+               aCondHelper = aConditions
+       end
        if
                rTarget ~= rSource
                and DB.getValue(nodeEffect, 'isactive', 0) == 1
-               and checkConditionalBeforeAura(nodeEffect, ActorManager.getCTNode(rSource), ActorManager.getCTNode(rTarget))
-               and AuraFactionConditional.checkFaction(rTarget, rSource, auraType)
+               and checkConditionalBeforeAura(nodeEffect, rSource, rTarget)
+               and AuraFactionConditional.DetectedEffectManager.checkConditional(rAuraSource, nodeEffect, aCondHelper, rTarget)
        then
                return true
        end

[dbachen]

So it wasn't in the base extension, but if he did an override in his own extension it would add the support he is looking for on that additional tag?

[SilentRuin]

To be fair this was never a thing. Diff of HEAD vs e44373d which is Feb 6, 2023

-function isAuraApplicable(nodeEffect, rSource, token, auraType)
-       local rTarget = ActorManager.resolveActor(CombatManager.getCTFromToken(token))
+function isAuraApplicable(nodeEffect, rSource, rTarget, aFactions)
+       local rAuraSource
+
+       local sSourcePath = DB.getValue(nodeEffect, 'source_name', '')
+       if sSourcePath == '' then
+               rAuraSource = rSource -- Source is the Source
+       else
+               rAuraSource = ActorManager.resolveActor(DB.findNode(DB.getPath(DB.getChild(nodeEffect, '...'))))
+       end
+
+       local aConditions = { 'FACTION(' .. table.concat(aFactions, ',') .. ')' }
+       local aCondHelper = {}
+       if EffectManager4E then
+               aCondHelper.remainder = aConditions
+               aCondHelper.original = DB.getValue(nodeEffect, 'label')
+       else
+               aCondHelper = aConditions
+       end
        if
                rTarget ~= rSource
                and DB.getValue(nodeEffect, 'isactive', 0) == 1
-               and checkConditionalBeforeAura(nodeEffect, ActorManager.getCTNode(rSource), ActorManager.getCTNode(rTarget))
-               and AuraFactionConditional.checkFaction(rTarget, rSource, auraType)
+               and checkConditionalBeforeAura(nodeEffect, rSource, rTarget)
+               and AuraFactionConditional.DetectedEffectManager.checkConditional(rAuraSource, nodeEffect, aCondHelper, rTarget)
        then
                return true
        end

As it was last July when I did all this - I can't really verify what "thing" it was - but its what I was told? (not sure how it came to be) to do and was "supposedly" being called to verify that something in range of aura was to be processed or not. For sure I did not make it up - though it being a year ago I really don't remember much about it and how I came to override it. If there is something else that hooks into AURA now that determines if things it picks up are valid or not - let me know and I'll override that.

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. Previously aura did not pick up things with NOTARGETING meaning something was working at one point. Likely shuffle in code made it no longer being triggered when it was before.

Thank goodness I never have to look at an effect again (I hope) as new 5EAE PHB will be taking over all that stuff.

[dbachen]

1. When a CT token is added to the map the aura effects are not being processed. This makes things like BCEGs SAVEA (and likely other stuff) not get applied when the CT entry with aura effects has its token placed on the map. This is because currently AURA only processes an effect when its added or modified (not when it already exists). This creates inconsistent behaviors. The only work around is to manually change aura effect in CT or turn it off and on to get it to process after token is placed. It should be overriding one of the add token hooks to insure aura effects are processed after it is placed.
   

Specifically, this was in regards to timing. If you go 1) Token to CT 2) Token to Map 3) Apply Aura to token, it works as expected. In the reported scenario, if you go 1) Token to CT, 2) Apply Aura to token 3) Place token on map it won't fire the savea section because it's not seeing the tokens in the aura until they move or the turns progress allowing saves or savee to work.

It may not be possible to apply the aura before its on the map in this case, but hopefully there is a series of steps that could allow it to work with the aura activation itself.

[SilentRuin]

Specifically, this was in regards to timing. If you go 1) Token to CT 2) Token to Map 3) Apply Aura to token, it works as expected. In the reported scenario, if you go 1) Token to CT, 2) Apply Aura to token 3) Place token on map it won't fire the savea section because it's not seeing the tokens in the aura until they move or the turns progress allowing saves or savee to work.

It may not be possible to apply the aura before its on the map in this case, but hopefully there is a series of steps that could allow it to work with the aura activation itself.

Exactly, but I honestly can't imagine a scenario where if I have an NPC with aura effects defined in CT - that I'm going to place the token first before I build out the effects (or in EE - this is all 5E here - case it would auto add the effects in when NPC was placed in CT). If I'm building a list of CT entries I build them all then completely - I don't place a token in between before the effects creation (in fact effects will already auto in CT by EE in my world).

Anyway, just a suggestion to close any inconsistencies. Currently only work around is to move anything within aura range to trigger aura effect or to change the CT entry aura effect in some way (turning off and on aura effect being simplest). Still should not be necessary to do this to keep things consistent. Obviously its only going to apply on first placement of token but spell casting with proxy NPCs - well - its always going to be the first token placement likely with things in the aura range that may need to be insta effected.

[MrDDT]

Exactly, but I honestly can't imagine a scenario where if I have an NPC with aura effects defined in CT - that I'm going to place the token first before I build out the effects (or in EE - this is all 5E here - case it would auto add the effects in when NPC was placed in CT). If I'm building a list of CT entries I build them all then completely - I don't place a token in between before the effects creation (in fact effects will already auto in CT by EE in my world).

Anyway, just a suggestion to close any inconsistencies. Currently only work around is to move anything within aura range to trigger aura effect or to change the CT entry aura effect in some way (turning off and on aura effect being simplest). Still should not be necessary to do this to keep things consistent. Obviously its only going to apply on first placement of token but spell casting with proxy NPCs - well - its always going to be the first token placement likely with things in the aura range that may need to be insta effected.

In every case I would do this. How are the players going to target a token not on the map and know that's the token they should target?

Don't get me wrong, I like your exts that allows to automate this, but in most people don't use that ext at all and it's a little buggy still with the having to click 2 times to get things to look right.

[Arnagus]

In every case I would do this. How are the players going to target a token not on the map and know that's the token they should target?

Don't get me wrong, I like your exts that allows to automate this, but in most people don't use that ext at all and it's a little buggy still with the having to click 2 times to get things to look right.

With including the functionality in AE, this will be more widely used. But isn't the effect placed last if the token is added to the CT with GenericActionLayers and EE?

[SilentRuin]

In every case I would do this. How are the players going to target a token not on the map and know that's the token they should target?

Don't get me wrong, I like your exts that allows to automate this, but in most people don't use that ext at all and it's a little buggy still with the having to click 2 times to get things to look right.

I'll be fascinated how you create PCs/NPCs in CT and remember to not place aura effects on it before you place token Not to mention anything that has EE running (which places matching effects as soon as it gets dropped in CT which is before a token is placed in map). Or encounters with EE.

Anyway, that bug in FGU assets with scaling has been there for a year I've lost hope they will ever fix it so not my lookout. I just make sure I bring up webm assets (search string) in FGU start of session and scroll through them all (sometimes that prevents it). As its only first time in a session that the scaling error happens for any one first time displayed asset - once done in a session for a particular asset it no longer fails. As you say, double clicking the effect twice as a work around is no skin off me - simple and works.

My suggestions for changes to AURA are just things I see as common sense (one was working before - you were one that pointed out it was no longer working to me I think - the other a simple safety measure to insure AURA works the same whether a CT token is placed with aura effect or adding/changing the aura effect while CT token is out there).

As with FGU - I don't expect changes I want to be implemented. I mention them - and move on

[SilentRuin]

With including the functionality in AE, this will be more widely used. But isn't the effect placed last if the token is added to the CT with GenericActionLayers and EE?

Who knows. Proxy NPCs may become in vogue - or not. I use them all the time but that's me and I have full control of the extensions I use to do them. Extensions outside of my control are outside of my control and I just try to have work arounds or follow directions on overrides they want me to do to make things work the way I want them to. I have no control over when things change.

EXTENSION = RISK!

And yes, as in all things I do the CT has all effects fleshed out before token is placed - hence the override the add token hooks to process aura effects request.

I'm as lazy a DM as you will ever find and want to do as little thinking about the mechanics as I can as I manage the flow of the session. Works by magic is what I want in all things

[bmos]

When a CT token is added to the map the aura effects are not being processed.

Added to issue tracker, will look for solution when I have time:
https://github.com/FG-Unofficial-Dev...fect/issues/37