Good Day Rhagelstrom :)Quote:
Originally Posted by rhagelstrom
Thanks for the link :)
Printable View
Good Day Rhagelstrom :)Quote:
Originally Posted by rhagelstrom
Thanks for the link :)
Yep - was easy to do. I'd appreciate if whomever does the code now replaces this function with the changes I made so I can do the above - pretty much do any condition checking supported via extensions currently in use - I tested above with ONLY Aura and BCEG in a test campaign with only two tokens (this is 5E specific also if you need to put some guards around due to that). Also found bug in FGU that Moon says he will fix in some later release that has every single Token.onMove getting double tapped for any one single move (twice the work for everything right now). Here is the code let me know if you plan to stick it in or if I have run my own version of this extension... the comments can be uncommented to watch the internal magic if you wish for verification its doing what I say its doing... DO NOT CREDIT ME FOR THIS IN THE CODE/COMMENTARY - credit implies I'll support this going forward... got enough to do with my own stuff :)Quote:
Originally Posted by SilentRuin
manager_effect_aura.lua
Code:...
local function getAurasForNode(nodeCT, searchString, targetNodeCT)
local nodeEffects = DB.getChildren(nodeCT, 'effects')
if not nodeEffects then return {} end
local rActor = ActorManager.resolveActor(nodeCT)
local rTarget = ActorManager.resolveActor(targetNodeCT)
-- Debug.console(rActor.sName);
local auraEffects = {}
for _, nodeEffect in pairs(nodeEffects) do
if DB.getValue(nodeEffect, aEffectVarMap['nActive']['sDBField'], 0) == 1 then
local sLabelNodeEffect = getEffectString(nodeEffect)
if sLabelNodeEffect:match(searchString) then
-- make sure conditions allow for this to be processed.
-- Debug.console(" ")
local aEffectComps = EffectManager.parseEffect(sLabelNodeEffect);
-- Debug.console(sLabelNodeEffect)
local bSetAura = true
for _,sEffectComp in ipairs(aEffectComps) do
local rEffectComp = EffectManager5E.parseEffectComp(sEffectComp);
-- Debug.console(rEffectComp.type)
-- Check conditionals
if rEffectComp.type == "IF" then
-- Debug.console("Check IF conditions")
-- Debug.console(rEffectComp.remainder)
if not EffectManager5E.checkConditional(rActor, nodeEffect, rEffectComp.remainder) then
bSetAura = false
break
end
elseif rEffectComp.type == "IFT" then
-- Debug.console("Check IFT conditions")
-- Debug.console(rEffectComp.remainder)
if rTarget and not EffectManager5E.checkConditional(rTarget, nodeEffect, rEffectComp.remainder, rActor) then
bSetAura = false
break
end
elseif rEffectComp.type == "AURA" then
-- Debug.console("AURA - so done Checking conditions");
break
end
end
if bSetAura then
-- Debug.console("Conditions passed")
table.insert(auraEffects, nodeEffect)
else
-- Debug.console("Conditions failed")
end
end
end
end
return auraEffects
end
...
function updateAuras(sourceNode)
...
-- Check if the moved token has auras to apply/remove
for _, auraEffect in pairs(getAurasForNode(sourceNode, auraString, otherNode)) do
checkAuraApplicationAndAddOrRemove(sourceNode, otherNode, auraEffect, nodeInfo)
end
-- Check if the moved token is subject to other's auras
for _, auraEffect in pairs(getAurasForNode(otherNode, auraString, otherNode)) do
checkAuraApplicationAndAddOrRemove(otherNode, sourceNode, auraEffect, nodeInfo)
end
...
end
...
Thanks! I copied that into a new branch on the repo.
I've got it working in the other supported rulesets, but it's not yet removing aura updates when conditions are removed.
I'll get that sorted soon and then push the release.
EDIT: all set. released.
I've got your live thing which was working fine - but when I started playing with multiple effects each named slightly differently and turning the effects I was not currently testing to "off" I got an infinite loop situation. I'm going to investigate it now. Not sure it was something always happening or just after this live bit.Quote:
Originally Posted by bmos
Ok I'm not sure what is going on but its hard to duplicate (as in it does not always happen). But when it does happen I'm testing with two aura effects and out of the blue it infinite loops placing FROMAURA's in the targets eventually getting a C overload error in chat. The following is your latest build with just the following change:Quote:
Originally Posted by SilentRuin
I'm running with the following effects (which work when they do and infinite loop when they do not - can't seem to duplicate issue with only one aura defined and one token in range).Code:...
function updateAuras(sourceNode)
printstack()
...
Fragmentation Mine2; IF: !WOUNDS(=,1); IFT: !WOUNDS(=,1); IFT: TYPE(Vehicle); AURA: 15 foe; Fragmentation Mine2; IF: FACTION(notself); SAVEE: 14 DEX (H); SAVEDMG: 2d10 kinetic
Fragmentation Mine; IF: !WOUNDS(=,1); IFT: !WOUNDS(=,1); AURA: 15 foe; Fragmentation Mine; IF: FACTION(notself); SAVEE: 14 DEX (H); SAVEDMG: 2d10 kinetic
I tend to turn them on and off or keep both active.
When it works the call stack looks like this...
Attachment 55476
When it infinite loops the call stack looks like this...
Attachment 55477
Not really sure what is going on or if its something that has always happened and I'm just new to AURA testing.
No longer relevant.
I am getting errors using the Aura Effects EXT in a up to date campaign without any other extensions loaded. I applied Spirit Guardians to a PC and moved the PC to the NPC to trigger adding the effect to the NPC. I then moved the PC away to remove the Effect. When I try to trigger the Aura Effect a second time the FG console error window opens and the Effect is applied to the NPC multiple times, See the chat window and NPC in CT. I have attached a screenshot.
https://cdn.discordapp.com/attachmen...ts_applied.png
just posted a hotfix. if that doesn't solve it, i'll have to roll back one of the v1.18 changes
Can't break it now. Thanks. Still get confused on IF and IFT with who is moving where :)Quote:
Originally Posted by bmos
Yeah, I probably would have skipped supporting IFT.Quote:
Originally Posted by SilentRuin
I think there is a function I can call to get a table of who you're targeting when the aura is parsed, although this seems like it might feel even weirder.
Rather have it than not - which is why I added it - for sure has its uses in reducing CT effect overhead.Quote:
Originally Posted by bmos
Thanks again for reworking this!
[Post edit] Also the whole point of Auras is they don't care about targeting. I'd not look up real targets in that table - AURA is its own thing - let it be unique (says the pseudo expert who has literally only been using it in detail for a few days - so take any opinions or code suggestions with a grain of salt) ;)
Please fix the manager_effect_aura.lua: getAurasForNode where I cut pasted without thinking about what it was really doing... fix in bold red...Quote:
Originally Posted by SilentRuin
This should resolve targeting issues when you make the fix - now it should be....Code:-- Check if the moved token has auras to apply/remove
for _, auraEffect in pairs(getAurasForNode(sourceNode, auraString, otherNode)) do
checkAuraApplicationAndAddOrRemove(sourceNode, otherNode, auraEffect, nodeInfo)
end
-- Check if the moved token is subject to other's auras
for _, auraEffect in pairs(getAurasForNode(otherNode, auraString, sourceNode)) do
checkAuraApplicationAndAddOrRemove(otherNode, sourceNode, auraEffect, nodeInfo)
end
[conditions before AURA];AURA: * *;[conditions after AURA]
[conditions before AURA] = IF applies to CT entry with the AURA effect defined. IFT applies to CT entry with the FROMAURA applied.
[conditions after AURA] = normal FGU conditions as applied in CT entry with the FROMAURA applied
Successfully tested with the following AURA in a complex environment - it only assigned FROMAURA when the mine was NOT destroyed, the target was NOT dying/dead, and the TYPE was a Vehicle. None of the humanoids triggered the mine while the vehicle did. Worked. [I used AURA, BCEG, and Equipped Effects (why there is name in front to match item) extensions]
BOOM; DMGA: 1 fire
Incendiary Mine; IF: !DYING; IFT: !DYING; IFT: TYPE(Vehicle); AURA: 15 foe; IF: FACTION(notself); Incendiary Mine; TDMGADDS: BOOM; IF: !DYING; SAVEA: 14 DEX (H); SAVEDMG: 2d8 fire
The BOOM custom effect was so that my 1 hp mine would trigger and with Death Indicators switch out to crater token.
Also tested as shown in this image below by parking two vehicle ships next to eachother in range of the same cannon AURA - then I just hit end turn constantly until one ship was destroyed. I am one lazy DM :)
Attachment 55489
Very powerful stuff. Let me know when it goes LIVE.
1.18-hotfix.2 is now live
Updated this post with more examples on how the new condition checks can work.
Hotfix 3 works great! Thanks bmos!
So now that this is present, it might make sense to stop checking whether characters are dead or dying.
Some auras could be only applicable for characters that are dying, for example.
Not sure what you mean - but I have to check for sure in the AURA effect if they or their target is dying for certain things. Can you explain what you mean based on some of what I do? For example:Quote:
Originally Posted by bmos
Mines (static):
Incendiary Mine; IF: !DYING; IFT: !DYING; AURA: 15 foe; Incendiary Mine; IF: !DYING; SAVEE: 14 DEX (H); SAVEDMG: 2d8 fire
Fragmentation Mine; IF: !DYING; IFT: !DYING; AURA: 15 foe; Fragmentation Mine; IF: !DYING; SAVEE: 14 DEX (H); SAVEDMG: 2d10 kinetic
Gas Mine; IF: !DYING; IFT: !DYING; AURA: 15 foe; Gas Mine; IF: !DYING; SAVEE: 14 CON (H); SAVEDMG: 2d6 poison
Clouds (moving or static):
Toxic Cloud; IFT: !DYING; AURA: 20 all; Toxic Cloud; IF: FACTION(notself); IF: !DYING; SAVES: 14 CON (H); SAVEDMG: 5d8 poison; Poisoned
Gas Cloud_Gas Cloud (Huge); IFT: !DYING; AURA: 15 all; Gas Cloud; IF: FACTION(notself); IF: !DYING; SAVES: 14 CON (H); SAVEDMG: 2d6 poison; Poisoned; Blinded
Gas Cloud_Gas Cloud (Large); IFT: !DYING; AURA: 10 all; Gas Cloud; IF: FACTION(notself); IF: !DYING; SAVES: 14 CON (H); SAVEDMG: 2d6 poison; Poisoned; Blinded
Incendiary Cloud; IFT: !DYING; AURA: 20 all; Incendiary Cloud; IF: FACTION(notself); IF: !DYING; SAVES: 14 DEX (H); SAVEDMG: 10d8 fire
Bodak NPC from Monsters of the Universe (need two - one for the effect - and one for generating immunity to the effect:
Aura of Annihilation_Bodak; IFT: TYPE(undead, fiend); AURA: 30 all; Aura of Annihilation_Bodak; IF: FACTION(notself); IMMUNE: CUSTOM(Aura of Annihilation_Bodak)
Aura of Annihilation_Bodak; AURA: 30 all; Aura of Annihilation_Bodak; IF: FACTION(notself); IMMUNE: CUSTOM(Aura of Annihilation_Bodak); DMGO: 5 necrotic
When I have a campaign with Token Height Extension and Aura Effect Extension loaded with no maps up - then when I key in the Wounds field in CT the map for that CT entry pops up. Also does when you add effects to the extension. It's completely weird. Especially if during startup something is coming up and modifies an effect or something in the CT - a blank map for that entry pops up. I'm posting to both of these extensions - suspect some sort of conflict as nothing happens if only one or the other is loaded.
I have about 130 FROMAURA effects, mostly identical, in my custom effects window under Tools. It looks like it makes and saves a custom effect every time someone enters an aura. Is there a way to prevent this?
Does your chat say its v1.18-hotfix.3?Quote:
Originally Posted by ColoradoGM
If not update you have one of the bad versions before the hot fixes.
I can't seem to find any effects strings for Aura of Life.
So far I have:
I'm sure that isn't correct, and the effect of not being able to have the character's MAX HP be reduced is eluding me.Code:Aura of Life; AURA: 30 friend; Aura of Life; RESIST: necrotic; IF(WOUNDS = 1) HEAL 1;
Any suggestions?
The syntax of the "IF" usually requires "IF:".Quote:
Originally Posted by ZelieDad
I think this will work out? It won't do the "non-hostile" partQuote:
Originally Posted by ZelieDad
or maybeCode:Aura of Life; AURA: 30 friend; Aura of Life; RESIST: necrotic; IF: DYING; REGEN: 1;
I haven't tried either of those.Code:Aura of Life; AURA: 30 all; Aura of Life; IF: FACTION(!foe); RESIST: necrotic; IF: DYING; REGEN: 1;
Thanks. I'll give them a shot.
What about the "...and its hit point maximum can't be reduced."? Is that even possible?
Is it possible to code Aura to use Faction(notself) and ignore NPC with a CUSTOM(TAG)
I have a PC with the ability to detect all living creature within 60' that have a INT higher than 3, I am the GM and typically always forget to notify the Player when his PC gets within range of a NPC. I do not see where AURA can IFT a STAT so I thought putting a custom tag like "MINDLESS" on the NPC with a 3 or lower would solve the problem.
Hi all. In our collective effort to automate Spirit Guardians I've been toying with the On-Enter save (unless I'm missing one, the other posts are addressing the On-Starting-Within-Aura effect).
Game System: D&D 5E
Spell: Guardian Spirits
"An affected creature's speed is halved in the area, and when the creature enters the area for the first time on a turn or starts its turn there, it must make a Wisdom saving throw. On a failed save, the creature takes 3d8 radiant damage (if you are good or neutral) or 3d8 necrotic damage (if you are evil). On a successful save, the creature takes half as much damage."
Maybe this is too ambitious, but this is what I'm trying...
Aura for starting within the aura (as expected, this works just fine):
SpiritGuardians_StartTurn; AURA: 15 foe; Spirit Guardians; SAVES: 8, [PRF], [WIS] WIS (M) (H); SAVEDMG: 3d8 radiant; Speed-15; (C)
Now, for the AURA OnEntering here's what I've been trying...
Attempt 1-ish:
This effect is applied to [SELF] on the caster:
SpiritGuardiansEntered; AURA: 15 foe; SpiritGuardiansEntered; SAVEA:8, [WIS], [PRF] WIS (M) (H); SAVEDMG: 3d8 radiant; (C)
Confusion point 1: This applies the roll to the caster too (when first applied). Adding IF:CUSTOM(notself); will stop this from happening (cool). If the notself is not included, the save is forced on the caster and then the SAVEA is removed from the effect string (meaning it is not subsequently applied to the enemies - kinda makes sense). However, with the notself, the initial save is not forced on the caster (good). But, the FROMAURA doesn't force the SAVEA anyway (not sure why). I assume, the removal of SAVEA after the first such use would mean this also fails for multiple targets, but that's a phase 2 of testing concern, haha.
Attempt 2-ish:
My second-ish attempt involved applying a second effect. The caster received the following alternate on [SELF]:
SpiritGuardiansEntered; AURA: 15 foe; SpiritGuardiansEntered; IF:CUSTOM(notself); IF:CUSTOM(!OnEnterApplied); SAVEA:8, [WIS], [PRF] WIS (M) (H); SAVEDMG: 3d8 radiant; SAVEADD: OnEnterApplied; SAVEADDP: OnEnterApplied; (C)
The other is applied based on the saving throw (set to 1 round, hidden):
OnEnterApplied; STURNRS
Now, obviously, the fact I can't get the initial SAVEA to trigger makes the follow-up moot. However, when performing tests on the components. the IF:CUSTOM(!OnEnterApplied); works to stop the saving throw from occurring. The goal (obviously) is to get the FROMAURA to do the SAVEA test (if the OnEnterApplied is missing). This seems like it should apply the On Enter saving throw once per round. (Meaning the cleric can't move away and back several times triggering the save, which isn't the intent of the spell, as I read it.)
I suppose I'd give this a try (but I find AURA/BCEG and effects in general are a trial and error attempt - not tried this myself)...
Spirit Guardians BADNESS; AURA: 15 foe; Spirit Guardians; IF: FACTION(notself); SAVEA: 14 DEX (H); SAVES: 14 DEX (H); SAVEDMG: 3d8 radiant
Spirit Guardians GOODNESS; IFT: FACTION(!foe); AURA: 15 all; Spirit Guardians; IF: FACTION(notself); SAVEA: 14 DEX (H) ; SAVES: 14 DEX (H); SAVEDMG: 3d8 necrotic
Can give it a try if you like. May fail - not sure.
Corrected post and tested - works "I think".
Thanks for taking a look, SilentRuin; I really appreciate the sanity check.
Spirit Guardians GOODNESS; IFT: FACTION(!foe); AURA: 15 all; Spirit Guardians; IF: FACTION(notself); SAVEA: 14 DEX (H) ; SAVES: 14 DEX (H); SAVEDMG: 3d8 necrotic
You're right, those work. It does accomplish part of the goal:
(A) Force a save on a target entering the aura (but not on the caster) - a victory
(B) Apply the At Start of Turn saving throw on anyone who begins their turn in the aura (but not on the caster) - a second victory
I'm still puzzling out the "How to block the ON ENTER AURA save" for individuals who enter the aura more than once in the same round - which, as I read it, they're only subject to 'on enter' once per round (making a max of 2 forced saves: 1 for first entry into aura, and 1 for starting turn in aura). The caster shouldn't be able to do a series of 5-foot steps to force the save over and over in the same round vs the same target. While chasing an enemy who leaves the aura in subsequent turns would force a new On Enter save. Thus...
Follow-up question: Do AURA effects (and FROMAURA for that matter) look for and/or see IF:CUSTOM() or IFT:CUSTOM() tags?
If they don't, then that explains everything, I think. What I tried so far, is adding IFT: CUSTOM (!OnEnterApplied); to the effect string before the AURA: N faction; tag, but this doesn't appear to test for the custom tag. Instead, it breaks it. Then, I tried adding it after IF:FACTION(notself); too. In this case, it applies the FROMAURA as expected; however, neither the SAVEA or SAVES trigger. I've tried both IFT:CUSTOM and IF:CUSTOM, doesn't seem to matter.
How to apply the custom tag (OnEnterApplied) for that test would be the last step. That could be manually applied by the GM or Player. Or using SAVEADD: and SAVEADDP: - though, these vanish once they leave the aura, as they're applied by the FROMAURA...so, that's not really a solution either.
Best I can tell you is to experiment around. For auras per the lastest hot fix (still waiting on next hotfix to fix correct source on FROMAURA's so that you see the "Applied from..." and have BCEG's source stuff work with them (my version does it but not sure when/if Bmos will get those in). Basically I use the following to deal with effects...Quote:
Originally Posted by estrolof
The text description in AURA on forge.
This recent post.
FGU effects rules
And the rules that come in the Readme pdf for BCEG extension.
It was on the Token Height Indicator side. All fixed. In testing I realized that it no longer automatically updates the aura when the height changes (need to move back and forth). Not sure if it's related to the FGU 4.3.1 update that broke the auto update of the pointer or not.Quote:
Originally Posted by SilentRuin
Would it be possible to call onMove on each token after adjusting the height? Do you have the token at that point?Quote:
Originally Posted by GKEnialb
I do have the token, so will give that a try. I used to move the token a pixel and back but that trick no longer work - hopefully calling onMove will work better.Quote:
Originally Posted by bmos
Not sure what I am doing incorrectly here... I had the Aura of Murder working correctly here but when I tried to do the Desecrated Altar.
AURA: 23 foe; Desecrated Altar; IF: FACTION(foe); VULN: all
Supposed to apply vulnerability to everyone except those dedicated to a specific God... it is not working properly.
I guess this worked:
AURA: 20 foe; Desecrated Altar; VULN: all
Hotfix 5 was put out by bmos! Well done!
This should speed things up and also fix the source of FROMAURA effects (you will see who applied them if you expand the effects in CT).
Yeah, that fixed it - I actually broke it myself when taking away the jiggling because it had no effect on the targeting arrows, not realizing that jiggling was useful to Aura Effects. Pushed a fix to the Forge.Quote:
Originally Posted by GKEnialb
Here's my tested and working version. It probably uses some other popular extensions, I don't remember which ones might apply.
Spirit Guardians (C); AURA: 15 foe; IF: FACTION (notself); SAVEO: WIS DC 15 (M) (H); SAVEDMG: 3d8 radiant
I don't know why I needed notself but I did, it kept hitting the caster even though caster is not a foe, until I added it.
That's intended behavior because some auras need to effect the bearer.Quote:
Originally Posted by ColoradoGM
IF: FACTION(notself) is not the clearest possible notation, but it's been around a while now. Maybe v2 will have something else someday.
I just checked and "IF: FACTION(foe)" is keeping the effects after it from applying to the bearer in my testing. Are you using it with other extensions? Have you tried disabling them and seeing whether they're involved?Quote:
Originally Posted by Slagmoth
Your "AURA: 20 foe; Desecrated Altar; VULN: all" will result in the bearer of the aura also being vulnerable, so you may need IF: FACTION(notself) as we figure out why FACTION(foe) isn't working for you.
Aura Effect v1.18-hotfix.5
* Effects like IF: Prone; AURA: 5; SAVES: 2 are now supported.
* HOTFIX: reduce unnecessary processing
* HOTFIX: IFT should now work correctly, consistently
* HOTFIX: sometimes the conditional checking would get stuck and the aura would never get parsed
* HOTFIX: source now works again
* HOTFIX: some other fixes
Click here to see raw code changes
Aura Effect v1.19
* Added faction handler to trigger aura recalculation. Auras will now be added/removed automatically when factions are changed.
* Code cleanup and some performance improvements when not relying on FACTION conditional.
Click here to see raw code changes
Aura Effect v1.20
* If your AURA effect contains "IF: FACTION(notself)" the FROMAURA effect will not (which helps keep the combat tracker a bit cleaner).
* Rewrote much of the logic for faction handling.
* Faction types friend and foe are now interpreted literally based on the tag in FG.
* Faction types neutral and faction are available for use everywhere.
* Relationship types ally and enemy are now added. Ally means the bearer's faction matches the effect source's faction. Enemy just looks at friend/foe and checks that they're different.
* All factions / relationships can be inverted with ! or ~. AURA: 10 ~ally means anyone whose faction doesn't match the source's. AURA: 10 ~neutral means anyone who isn't neutral.
* It's helpful to understand that the effect source's faction is being compared to the faction of the actor bearing the effect.
Click here to see raw code changes