Printable View
very odd behavior with auras tonight. once when the aura killed someone, all the FROMAURAs were removed from the other tokens. Randomly the auras would be dropped despite no movement happening. closing and reopening the map forced the auras back on, but in some cases doubled them up.
Are you using the current live version? The only issue I've noticed recently was when I had to change all my foe auras to !ally and all my friend ones to ally. Also had a similar thing but I was doing questionable testing IMHO - had the following effect:Quote:
Originally Posted by mattekure
YOU IN MY SPACE; IFT: !DYING; AURA: 10 all; You In My Space; IF: FACTION(notself); TDMGADDS: BACK AT YOU; IF: !DYING; SAVEA: 14 CON (H); SAVES: 14 CON (H); SAVEDMG: 1d4 slashing
where the "BACK AT YOU" was defined as a roll
"BACK AT YOU; DMGA: 5 slashing"
Which was questionable at best.
Yeah, using version 1.22. I may need to modify some auras to change foe to !ally, but this was very different behavior. I was not DM, so just seeing it as a player
Yep my auras started going nuts when the faction changes came out - per my previous post I had to do the following:Quote:
Originally Posted by mattekure
Turns out it was the new foe logic that did me in. I had a bunch of
AURA: 15 foe
in my effects which really now need to be
AURA: 15 !ally
and friends would need to be ally.
Ah, the other thing is that FROMAURA effects that were there before 1.22 will need to be removed as the extension will no longer realize they're there.
Sorry I wasn't clear about that. It'll probably feel pretty weird when that happens, although I didn't expect it to require closing and opening the map and your description sounds pretty different than I'd have expected.
Something everyone probably realized but me, aura distances are from the outer edge of a tokens size. I've been told this but it never really sank in - I just finished editing all my existing campaign auras to insure they are defined as they should be. I noticed this once in my earlier post when I was flying over a mine and it triggered when I thought I was out of range - bmos explained it to me but it never sank in.
So now I only have one vehicle burning type - as I used to have large, huge, gargantuan with the aura of a similar size - but I now realize I only have one effect of 5ft as the actual NPC size will take into account 1/2 its size already in the aura (not from center of thing aura is emanating from but from edge of size). I'm sure everyone knows this already, but I figured I hammer it home again.
a Large Gas Mine has an aura of 5ft.
a Huge Gas Mine has an aura of 5ft.
a Gargantuan Gas Mine has an aura of 5ft.
Still looks weird to me even now. But I finally get it.
Wow, I honestly never thought of that.Quote:
Originally Posted by SilentRuin
I'd consider such behavior more of a bug as it goes against how such abilities are defined in most systems I know.
Yet that is how it works. Kept having gas mines trigger when I had 15 declared but it was - as you told me - 15 plus the size of the token.Quote:
Originally Posted by bmos
I can almost guarantee that wasn't me.Quote:
Originally Posted by SilentRuin
Was token height author my bad. The way auras work is that aura size is the distance from someone. Drop a gargantuan creature and target a medium thing and put it right next to it - 5ft. That is not from the center. That is the distance between the tokens borders. Hence, me dropping auras out with the literal sizes I wanted from center would never work - would always be triggering farther out than I thought. Nature of targeting, auras, etc. as I understand it - now.Quote:
Originally Posted by bmos
This whole target distance logic is always confusing to me - just posted a bug in FGU for it even...
Gist is - I have a huge thing which means its 15ft wide - or from center to edge 7.5ft then add in whatever aura and... just very hard to figure out. I have that gas cloud and it does not trigger until targeting is 5 ft away because I have set it to aura: 5 - but that is based on targeting distance (FGU code calcs). And with bug shown in post above - it means aura will trigger when I get to 1 grid unit away from that huge tokens border - and if I go 1/2 a grid farther in that causes it to disable the aura because I've gone back to 10ft according to FGU targeting calcs.
It's all quite confusing but explains some very weird things I've been seeing with auras. And of course, any SAVEA type of stuff will actually fail to roll the second half of the effect (damage) when I move out of range even though the saving throw was triggered and rolled. I truly do not understand why an in progress saving throw is somehow truncated simply because the effect was removed. I mean it was in progress - the whole effect string should be processed regardless of the current state of the CT entry itself - you already started processing it and trying to reread the rest of the effect after the roll is looking for trouble.
Distances between two tokens in FGU are found by looking at the closest square of a grid centered around the token based upon the creature size to the target and then "backing up" half a square (and vice versa). For a 5' grid, between two adjacent medium tokens, the two squares will be touching, so bringing each back 2.5', you get a distance of 5'. If there are two squares between a medium and a huge token is 10' for the empty squares and 2.5' for each of the tokens, for 15'.
Attachment 55616
If that huge creatures is emanating an aura of 5', it's going to be emanating 2.5' from every outer square, which would include all adjacent targets, regardless of size. If you started from the middle of the creature, a 5' aura wouldn't affect any creature, which I don't think is what you'd want. Otherwise, a huge creature with a 5' reach would also never be able to make a melee attack against an adjacent creature. Unless I'm missing what the discussion is about...
If you really want a distance from the center of a token and not half a square from the edge, you can pass in the coordinates of the center of the token and not the token itself (I think). In regards to the comment about token height a few posts back - I've confirmed that it matches the calculations of raw FGU in 2 dimensions (of course extending to 3 dimensions if one has a height). If you think it doesn't match the raw calculations, I'd ask that you post the differences on that thread and not imply it's messing you up on this thread.
Baring their current bug I mentioned - its just weird. But correct as you state.Quote:
Originally Posted by GKEnialb
For now, until FGU fixes their distance bug I mentioned, I will assign all my minimum auras to 10 ft so they will not flip out when they run into that issue.
Oh, then just working as most game systems dictate range.
Nothing for me to fix there, hooray.
Yeah, I think you're good. If you do decide to go from a point instead of a token, you can use my getTokenWithinShape functions (sphere or cube) in Image instead of Token (or steal the code to use directly in Aura Effects).Quote:
Originally Posted by bmos
(sigh) Another issue - I'm finding that if I have one of the things in range of an aura set invisible - the Token.getDistanceBetween is returning #0 which basically makes the aura ignore that token. Just FYI for some who may have noticed this happening.
To clarify, since Invisible is a separate condition that can be set, this is in reference to the state of tokenvis under the actor's combattracker node?Quote:
Originally Posted by SilentRuin
In reference to the physical token setting of setVisible. If its marked invisible, even though from the host this code runs - it will get a 0 result on distance. In your world, that means any trigger of onChangeEffect that calls that routine where one of the tokens is not visible on the map it will fail to process it (fails your range check).Quote:
Originally Posted by bmos
Keep in mind tokenvis on CT will set the token visibility but setting token visibility will not set the tokenvis in CT - the CT is not a reliable check for map token visibility.
I get an odd reaction with this setup. The Sorcerer (caster) has two auras on:
AURA: 20 ally; REGEN: 4
AURA: 20 !ally; DMGO: 4
her ally gets healed when in range, her enemy gets damaged when in range, all good. But she gets both healed and damaged on her turn. Why?
edit: fixed it with IF: FACTION notself
Because she is part of the aura - you needQuote:
Originally Posted by ColoradoGM
AURA: 20 !ally; IF: FACTION(notself); whatever
I noticed that SR showed you the fix and you fixed it but I wanted to explain it.Quote:
Originally Posted by ColoradoGM
Currently if you have an effect on you which "AURA: 20 ally; REGEN: 4" it's detecting you have that effect. Because of the ; REGEN: 4
So in order to stop that, you need the IF: FACTION(notself) else it will run it on yourself.
You wouldn't need this if you had another IF check that limited yourself also, like "IF: CUSTOM(Hexed)" then unless you had Hexed effect on you it wouldn't run it either. Just to give you more info than you likely wanted but maybe others will read it too.
Love the extension, but have a question that hopefully somebody knows the answer to. I have an issue where an aura is removed from those in it when an effect is removed either from them or from the source of the aura. No error messages pop up in the console and if I move the token that is the source of the aura back and forth the effects is reapplied to the other tokens.
Confirmed! Thanks for reporting that.Quote:
Originally Posted by ZetaSupreme
I wanted to note for some people to help explain this a bit better.Quote:
* 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.
***Example***
PCs are normally set to friendly/green. NPC monsters are normally set to foe/red. NPCs non monsters (like a bartender) would be set to neutral/yellow/faction, and completely Unknown Creatures/Things would be set to non-faction/blue.
ALLY = creatures matching same faction as you.
-Example of ALLY as if aura effect is placed on each of these types named to the left and who would get the "FROMAURA" is the second part of the list.
In this case;
PCs (friendly/green) would be allies "ALLY" to ONLY PCs (friendly/green);
NPC monsters (foe/red) would be allies "ALLY" to ONLY NPC monsters (foe/red);
NPCs non monsters (neutral/yellow/faction) would be allies "ALLY" to ONLY NPCs non monsters (neutral/yellow/faction);
Unknown Creatures/Things (non-faction/blue) would be allies "ALLY" to ONLY Unknown Creatures/Things (non-faction/blue);
ENEMY = creatures opposing faction (friend vs foe only)
-Example of ENEMY as if aura effect is placed on each of these types named to the left and who would get the "FROMAURA" is the second part of the list.
In this case;
PCs (friendly/green) would be the only enemies "ENEMY" to NPC monsters (foe/red);
NPC monsters (foe/red) would be the only enemies "ENEMY" to PCs (friendly/green);
NPCs non monsters (neutral/yellow/faction) would have NONE matching;
Unknown Creatures/Things (non-faction/blue) would have NONE matching;
!ALLY = creatures not matching your faction (AKA old AURA system = foe)
-Example of !ALLY as if aura effect is placed on each of these types named to the left and who would get the "FROMAURA" is the second part of the list.
In this case;
PCs (friendly/green) would be not-allies "!ALLY" to everyone EXCEPT PCs (friendly/green);
NPC monsters (foe/red) would be not-allies "!ALLY" to everyone EXCEPT NPC monsters (foe/red);
NPCs non monsters (neutral/yellow/faction) would be not-allies "!ALLY" to everyone EXCEPT NPCs non monsters (neutral/yellow/faction);
Unknown Creatures/Things (non-faction/blue) would be not-allies "!ALLY" to everyone EXCEPT Unknown Creatures/Things (non-faction/blue);
!ENEMY = creatures who are friendly to your faction (foe vs friend only)
-Example of !ENEMY as if aura effect is placed on each of these types named to the left and who would get the "FROMAURA" is the second part of the list.
In this case;
PCs (friendly/green) would be not-enemy "!ENEMY" to everyone EXCEPT NPC monsters (foe/red);
NPC monsters (foe/red) would be not-enemy "!ENEMY" to everyone EXCEPT PCs (friendly/green);
NPCs non monsters (neutral/yellow/faction) would be not-enemy "!ENEMY"" to EVERYONE including same faction (neutral/yellow/faction);
Unknown Creatures/Things (non-faction/blue) would be not-enemy "!ENEMY" to EVERYONE including same faction (non-faction/blue);
Any time frame on when Auras will be getting a fix for the FROMAURA appearing and disappearing when moving around in an aura? Gave an example in DM to you a while back.
Nope. I've been slowly working on the issue mentioned above and associated things I have encountered during that. I think they're likely related, but don't know that for sure. I'm very busy with work right now so my time for this is pretty limited.Quote:
Originally Posted by SilentRuin
I started working on re-implementing the triggering and processing of auras. Here is an early (generally working) build of v2 for those who are curious.
If you install this by putting it into your extensions folder, it will override the live Forge version. If you do that, be sure you remove it when you're done testing to begin using the live Forge version again.
The primary changes:
Breaking up the code into smaller functions and a variety of lua scripts to facilitate easier maintenance, repair, and collaboration.
Moving toward parsing the appropriate auras by scanning tokens on the map rather than all combat tracker entries. This should be useful for people with massive combat trackers or with extensions that leave a ton of hidden entries in the combat tracker.
Notable things from v1 that are not included:
Deferring processing until after token movement is complete.
Limiting movement to whole squares.
Things that are working much better than V1:
Triggering aura removal/addition. For This might also fix the issue SR was talking about?
Feedback I am most interested in:
Speed. Is this faster or slower, especially when used on large/complex campaigns?
Behavior. Do the effects work the way you'd expect? Are effects added/removed appropriately?
Feedback I pretty much don't want to hear yet:
Extension compatibility. If you're testing this, please don't load anything else. Before I start looking into that stuff I need to make sure this all works right with the base rulesets most FG DMs are running on.
As with all testing, if you are going to test this on a real campaign, BACK IT UP FIRST.
Thanks Bmos for all your hard work, I will try testing it out. FINGERS CROSSED!
Starting to do some performance testing.
More later this week hopefully.
Not had a chance to test it yet - maybe later this week unless you think I should just build it straight out of your current source. My monday game had that triggering everytime you moved through an aura issue I gave you a simple example campaign of via DM the other week. If you can get that to work I'm sure my games would work fine.Quote:
Originally Posted by bmos
Has anything like this suggested feature been added at all? I've been having this issue with distance calculation discrepancy aswell. Would love to have circular auras with the standard diagonal distance setting.Quote:
Originally Posted by GEONE
not yet, but GKEnialb added the resources in Token Height that could enable that, so hopefully someday soon™Quote:
Originally Posted by xxXEliteXxx
Has something changed recently? I'm still using the Forge version and my game last night had issues I've never encountered before. I've been using this extension for quite a while with no issues. Last night, a player Cleric had the Spirit Guardians Aura on him: Spirit Guardians; AURA: 15 foe; IF: FACTION(foe); SAVES: WIS [SDC] (M)(H); SAVEDMG: 3d8 radiant; (C)
He was surrounded by wolves. When a wolf within the aura came up in the combat tracker, it would sometimes work, but then other times, the effect would just kind of drop off one of the wolves on its own. I had to move them out and back into the aura and then adjust the combat tracker to get it to work again. I have never had to do this.
I haven't changed anything on my campaign. I have quite a few other extensions but all of them have been enabled with this working perfectly in the past.
I replaced the call to the api distance calculation with celestian's old distance calculation method from the below thread (since it worked using proper circles) and with a few tweaks to accommodate larger sized creatures and adjusting for distance-to instead of distance-between, it works pretty well for my purposes.Quote:
Originally Posted by xxXEliteXxx
https://www.fantasygrounds.com/forum...-for-FGU/page2
Feel free to post the ext file here :)Quote:
Originally Posted by GEONE
Congrats on the 100 page milestone of this thread ;)
Here's a new build with a bunch of changes under the hood.Quote:
Originally Posted by bmos
https://github.com/FG-Unofficial-Dev...ag/v2.0-beta.1
I will check it out. I was testing it before and seems to be working just fine.
Latest beta.3 build is now on TEST channel.
https://github.com/FG-Unofficial-Dev...ag/v2.0-beta.3
AS WITH BETA.2 THIS REQUIRES v4.3.3+.
I'm now starting to validate against some other extensions.
Currently there is an issue with Better Combat Effects saving throws when entering auras, although this is with v4.0-rc2 of BCE which is currently on TEST as well.