Hi all! I'm totally dumb when it comes to coding and it amazes me how you code-savvy guys can solve pretty much everything. Big thumbs up!
Printable View
Hi all! I'm totally dumb when it comes to coding and it amazes me how you code-savvy guys can solve pretty much everything. Big thumbs up!
I just released v1.20 to LIVE. There is a significant chance that some auras that you all have written will not work the same, unfortunately.
I highly recommend everyone reads the README on GitHub or the Forge so they understand the new faction system and how it works.
Sorry for the inconvenience.
Aw, thanks! The FG developer community is so good to work with.Quote:
Originally Posted by eriktedesco
Got some mod updating to do lol
I could include a 'legacy mode' option that keeps more of the old behavior, but I think it's probably best to avoid that.Quote:
Originally Posted by MrDDT
I personally don't think this is needed. As it would be missing a lot of the options that are much needed that you just added.Quote:
Originally Posted by bmos
I think the last update broke the fix I put into Token Height for automatically evaluating the auras when the height changes. Moving the token does re-evaluate (and takes height into account), but the onMove isn't doing anything anymore. :(
Looks like it has to move a full half square away before the re-evaluation occurs (I added 1 to x on every height change to test and the re-evaluation occurs once the token moves half a square away)
That is correct - as I explained to you in the other thread. Aura gets hammered by onMoves and the code I referenced in that math thread makes sure it only processes every 1/2 grid unit - as designed. Also I have a new version to keep it from confusing tokens on multiple maps in CT waiting on bmos to drop it out there.Quote:
Originally Posted by GKEnialb
Ah - somehow I missed that post in between Moon's post and my response. So you sped it up, but broke the integration between the two extensions... Maybe we can add something to Aura Effects that gets called when the height changes (or registers for the a change or even onWheel) instead of depending upon the underlying move.Quote:
Originally Posted by SilentRuin
Get with me on discord then as its less cumbersome than here for texting.Quote:
Originally Posted by GKEnialb
I'm having an issue where when one of my players attempts to apply the Hex disadvantage condition to a creature, I'm getting an error popping up in the console. I have narrowed it down to something about the Aura of Protection that is being adding when the PC is added to the CT. If the Aura is active on the PCs effect list in the CT, and the Hex condition is applied I get the error. If I then remove the Aura of Protection, and apply the Hex condition, it works as intended.
Basically, if the Aura is active on the player, before the Hex is added to the creature, then I get the error.
This is the stacktrace of the error:
Code:[12/23/2022 3:32:58 PM] [ERROR] Handler error: [string "CoreRPG:scripts/manager_effect.lua"]:578: getValue: Invalid parameter 1
stack traceback:
[C]: in function 'getValue'
[string "CoreRPG:scripts/manager_effect.lua"]:578: in function 'isGMEffect'
[string "CoreRPG:scripts/manager_effect.lua"]:677: in function 'addEffect'
[string "Exhausted:..ts/manager_effect_exhausted.lua"]:285: in function 'addEffect'
[string "..erCombatEffectsGold:..ager_effect_bce.lua"]:260: in function 'addEffect'
[string "CoreRPG:scripts/manager_effect.lua"]:310: in function 'fHandler'
[string "CoreRPG:scripts/manager_oob.lua"]:30: in function <[string "CoreRPG:scripts/manager_oob.lua"]:22>
[C]: in function 'deliverOOBMessage'
[string "CoreRPG:scripts/manager_effect.lua"]:341: in function 'notifyApply'
[string "CoreRPG:scripts/manager_action_effect.lua"]:132: in function 'fResult'
[string "CoreRPG:scripts/manager_actions.lua"]:632: in function 'fORA'
[string "RequestedRolls:..ipts/rr_manager_staged.lua"]:65: in function 'resolveAction'
[string "CoreRPG:scripts/manager_actions.lua"]:607: in function 'handleResolution'
[string "CoreRPG:scripts/manager_actions.lua"]:566: in function 'fRollOriginal'
[string "RequestedRolls:..ipts/rr_manager_action.lua"]:156: in function 'roll'
[string "CoreRPG:scripts/manager_actions.lua"]:424: in function 'applyModifiersAndRoll'
[string "CoreRPG:scripts/manager_actions.lua"]:400: in function 'actionRoll'
[string "CoreRPG:scripts/manager_actions.lua"]:167: in function 'actionDrop'
[string "CoreRPG:scripts/manager_combat_drop.lua"]:156: in function 'handleActionDropEvent'
[string "CoreRPG:scripts/manager_combat_drop.lua"]:90: in function <[string "CoreRPG:scripts/manager_combat_drop.lua"]:70>
(tail call): ?
SilentRuin and I identified the new incompatibility with Token Height (not automatically updating the aura when height is changed until you move the token) and a fix for it. Token Height has a new version on the Forge with the fix, though needs to have a new version of Aura Effects pushed as well (to make notifyTokenMove global).
Not sure when bmos will get back to it as its the holidays but he has the fixes to expose the routine you needed and also to fix the auras interacting with tokens in other images (but in same map coords). He will let you know when he gets around to all this.Quote:
Originally Posted by GKEnialb
Thanks for that.
Aura Effect v1.21
* Restructured a bunch of code
* Added trigger for when adding creatures to the map during a battle. Resolved issue #17.
* Found an issue with Faction checks which is now fixed. In some cases, the wrong actor was being checked resulting in auras being added/removed incorrectly.
* Limited processing to actors that have tokens on the same map
* Add !self and ~self as an alternative to notself for logical consistency. self, however, is not supported.
* Allow use of decimal places in aura range
Click here to see raw code changes
Can you re-test this with the latest update and let me know if it's still happening?Quote:
Originally Posted by ZelieDad
And Token Height and Aura Effects are back to working together seamlessly! :)
RedactedQuote:
Originally Posted by bmos
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
In case it helps anyone else struggling with replacing auras in their modules after the recent change, here is a regex replacement that should make old effects work a lot better.
If run on a file last used before v1.20:
It will make auras that previously targeted actors whose faction matches the source again do the same.
It will make auras that previously targeted actors whose faction does not match the source again do the same.
Likely some auras will still need further adjustment and they can be optimized and shortened much better now if rewritten, but it might help someone.
Obviously make sure you have a backup before doing text replacement on any files!
Notepad++
AURA ([0-9.]+) friend; -> AURA \1 ally;
AURA ([0-9.]+) foe; -> AURA \1 !ally;
Standard
AURA ([0-9.]+) friend; -> AURA $& ally;
AURA ([0-9.]+) foe; -> AURA $& !ally;
With everything happening with the new version, should I just wait until it settles down, or I am good to retest?
I'm not clear on the difference between friend and ally. If there are 4 factions (green/PC, red/ hostile, yellow/neutral, and white/"faction"), and I'm green, is there anyone who is friend but not ally, or vice versa? If I'm red, does that change?
If you want it to be exactly like before just change anything that was set to foe to !ally, and anything set to friend to be allyQuote:
Originally Posted by ColoradoGM
Quote:
The same faction types as above are available, along with "notself":
all - does not block processing on any actor
friend - continues if the effect bearer's faction is "friend"
foe - continues if the effect bearer's faction is "foe"
neutral - continues if the effect bearer's faction is "neutral"
faction - continues if the effect bearer's faction is blank
ally - continues if the effect bearer's faction matches the effect source's faction
enemy - continues if the effect bearer's faction is "foe" and the effect source's faction is "friend" (or vice versa)
notself - continues if the effect bearer does not match the effect source's
Also note that if you want everyone other than your enemy, you would do !enemy now, which is useful for some stuff too.
This would include all factions other than the opposing faction from you. So if you were marked as foe, then only green would NOT be included in this.
Let me know if that helps.
Well described. This is exactly it.Quote:
Originally Posted by MrDDT
You're all set to retest. Also, most importantly, have you tested to see if it happens without other extensions loaded? I see in your posted stacktrace that it also involves BCEG which got some updates recently as well and also Requested Rolls.Quote:
Originally Posted by ZelieDad
What's the effect text of the Aura of Protection and the Hex that are being used?
I've retested v1.21-hotfix.1 with only Aura Effects loaded, and the full suite of extensions loaded, and I'm not seeing the error anymore. Looks like it's not a problem anymore.Quote:
Originally Posted by bmos
Yay! You know where to find me if it crops back up!Quote:
Originally Posted by ZelieDad
I'm still working on Aura of Life. This works for the first part
I still can't seem to figure out the hit point maximum can't be reduced part. I don't know if it is possible without the ability track the current HP max before and after an effect would attempt to reduce the HP max like the Wraith's Life Drain attack.Code:Aura of Life; AURA: 30 all; Aura of Life; IF: FACTION(!foe); RESIST: necrotic; IF: DYING; REGEN: 1;
"The target must succeed on a DC 14 Constitution saving throw or its hit point maximum is reduced by an amount equal to the damage taken."
So the Aura of Life coding would now beQuote:
Originally Posted by ZelieDad
I know of no way to stop the MAX HP, also it's not even automated normally so simply just don't do it, you can also put a note in the aura if you want to help you remember.Code:Aura of Life; AURA: 30 !enemy; Aura of Life; RESIST: necrotic; IF: DYING; REGEN: 1 all
Code:Aura of Life; AURA: 30 !enemy; Aura of Life; RESIST: necrotic; IF: DYING; REGEN: 1 all; NOTE maximum HP can not be reduced
BCEG has things like SAVEA which are triggered when something enters the range of that aura. When something is executed the SAVEA in the from AURA effect is removed. This has the result that it won't happen again unless they reenter the aura as it knows not to replace the FROMAURA. All works fine. But when I open a window - all that goes out the door and its almost like the FROMAURA is recreated (again with the SAVEA) and executed across the board if anything was left currently in range of one of those.
This seems like a bug given that it knew when moving around that it was not to replace the FROMAURA (where SAVEA had been removed after execution) but when you open a map - it replaces the FROMAURA (if still in range which it was when the map/app was closed) and executes it no matter what.
Yep. I was trying to find a way to block the SAVEA function with a IFT:CUSTOM tag (for a similar problem, moving back and forth keeps reapplying the SAVEA). That way it only applies it 1/round. But, I cannot find a way to make that work.
Unfortunately at this time there is nothing implemented to determine what aura a FROMAURA effect is related to if the aura effect string doesn't match.
I do hope to add this soon, but have only just started laying the groundwork for it.
Originally this was supported, as aura names were used to identify them. Users didn't like the requirement of an aura title, so I removed that check and a better implementation has been planned for some time. The same benefit would apply to any effects that only apply for a single roll or whatever.
Regarding the recurring SAVEA roll, that could be desired behavior for some auras. If you want to make someone immune to an aura, you can just turn the FROMAURA effect "off" which will keep it from being removed and re-added as they leave and re-enter the aura.
That would be very cool and handle supported FGU effect manipulation (only first roll etc.)Quote:
Originally Posted by bmos
I think you misunderstand - if you fix this as you suggested your working on (solving first roll etc issue of identifying a FROMAURA as matching even though something has been removed - first roll - IMMUNE - SAVEA - etc.) then this problem would go away. Its actually caused by the fact you can't recognize a non exact match.Quote:
Originally Posted by bmos
Thanks for this.
Quote:
Originally Posted by ZelieDad
Isn't that covered by Constitutional Amendments?Quote:
Originally Posted by MrDDT
https://forge.fantasygrounds.com/shop/items/42/view
You can adjust MAXHP, with that, but you can't prevent things from using it.Quote:
Originally Posted by bmos
So what I understood is that they had coding effect for the NPC using the MAXHP drain effect. However, with this spell/skill/feature, it would stop that from happening yet, I don't know any coding that would stop it automatically using a coding effect like IMMUNE: MAXHP or something.
So I think the only way to stop MAXHP changes, would simply remove the effect after they were done, or not do them if someone was under that spell effect that prevented it.
Also the automation people normally use for the drain would be on damage end, so they can simply not do the damage from the ghost or whatever was doing it. Instead have the damage rolled and applied in manual way. I know it sucks but likely the best options for some of the edge cases like this.
My official WISH list for Auras (don't make me wait too long or I'll make them self fullfilled!!!!):
1) Have a global distance that holds the max distance of any aura effect currently defined in the CT where the entry is ON the map. This is reset anytime a CT window is opened. Any time CT entry is removed from map or added to map there effects will be scanned for max aura (plus 1 grid unit or something) and the global value can be raised if higher. ALL CombatManager.getCombatantNodes() calls will be replaced with getTokensWithinDistance(tokenBEINGMOVEDORCHANGED, distanceGLOBALMAX) calls. This will improve the performance phenomenally - especially when you consider most ranges don't usually exceed 20 ft.
2) Have FROMAURA matched even when some portion of it has been removed by IMMUNE, SAVEA, etc.
I WANT. Don't make me wait to long!!!!
Regarding the second request, check the test channel.Quote:
Originally Posted by SilentRuin
Is the current github .ext that version?Quote:
Originally Posted by bmos
No, but the main branch is.Quote:
Originally Posted by SilentRuin
We came across a bit of a bug trying to use this during our game on Tuesday, I was playing a Paladin and when I was adding an effect to an enemy NPC it was expiring my aura on the other PCs, the effect would expire off the enemy straight away and it would cause an error to appear in the DM's console log. I've spent some time poking around in a test campaign (with only this extension loaded) and have come up with the following replication steps:
- Add Two PCs (paladin and monk) and an enemy NPC (a xvart) to the Combat Tracker and add all three to a map with the paladin in the middle and the other two right next to him.
- Add an aura to the Paladin (e.g. "AURA: 10 ally; Aura of Protection; SAVE: 5")
- The monk gets the aura, the xvart does not (so far so good).
- Paladin applies an effect to the xvart (tried a couple of them, all seem to behave the same. I ended up using "Divine Health; Immune to disease" during my testing because it was handy).
This results in the following:
- The "FROMAURA" effect is expired from the monk.
- Four messages are added to the chat stating that the effect placed on the xvart has expired.
- The effect does not appear on the xvart.
- The DM has the following error appear in their console log (this only appears if the paladin is being controlled by a player, not if they are being controlled by the DM).
Code:[12/28/2022 3:15:02 PM] [ERROR] Handler error: [string "CoreRPG:scripts/manager_effect.lua"]:665: setOwner: Invalid parameter 1
Thanks for reporting that.Quote:
Originally Posted by humby
It appears I had broken the ability to have multiple auras from the same source in some circumstances. Hopefully this new build resolves this issue for you.
Aura Effect v1.22
* Restructured a bunch more code
* Tracking the relationship between FROMAURA effects and AURA effects is now handled differently. FROMAURA effects that are modified should better resist being overwritten or duplicated.
* Resolved problems with having multiple auras on the same source.
* If a FROMAURA effect is marked to expire on ACTION or ROLL, it will instead be set to disabled. This will prevent it from being re-added when a token is moved.
Click here to see raw code changes
Tip for AURA users. The combat tracker effects edit field does not use <delaykeyupdate /> in its definition which means every keystroke (delete char or adding a char) will trigger an update everytime. On large campaigns this makes every effect keystroke take a long time. What I do to avoid this pain on the rare occasion I'm keying in an effect in the CT (rather than dropping one per usual) is I turn OFF the effect before I start working on it. You can correct it all you want till your ready to turn it back ON without lag.
A useful workaround. Alternately, draft effects in the effects window or via the effect builder extension and add them in a completed state.Quote:
Originally Posted by SilentRuin