Isn't that covered by Constitutional Amendments?
https://forge.fantasygrounds.com/shop/items/42/view
Printable View
Isn't that covered by Constitutional Amendments?
https://forge.fantasygrounds.com/shop/items/42/view
You can adjust MAXHP, with that, but you can't prevent things from using it.
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!!!!
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.
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.