LOEFD
Join Serverdamage application hooks
New 5e Hook ideas, gimme yer thoughts:
args:
Goal: Allow modules to intercept damage being applied to an actor and change it. Mutating
---
args:
Goal: Allow modules to react to damage being taken from an actor. E.g. concentration checks, saying "ow"
Problems:
- Running these on/pre actor update is feasible, but tricky because of temphp. It would be simpler to rely on
- Unlinked Tokens and all that mess (not really sure this is a problem, just something to be wary of).
- Currently the system's damage rolls strip out
Hooks.call('Actor5e.preDamageApplied')
args:
damageAmount
, actor
, damageType
(if available)Goal: Allow modules to intercept damage being applied to an actor and change it. Mutating
damageAmount
would affect the amount the actor takes. E.g. automating something like Heavy Armor Master, immunities, etc.---
Hooks.callAll('Actor5e.damageApplied')
args:
damageAmount
, actor
, damageType
(if available)Goal: Allow modules to react to damage being taken from an actor. E.g. concentration checks, saying "ow"
Problems:
- Running these on/pre actor update is feasible, but tricky because of temphp. It would be simpler to rely on
Actor5e#applyDamage
, but that doesn't cover the HP on a sheet being updated manually.- Unlinked Tokens and all that mess (not really sure this is a problem, just something to be wary of).
- Currently the system's damage rolls strip out
damageType
a long time before Actor5e#applyDamage
enters the picture.How bulletproof should a hook like this be?
Is it "fine" that it relies on a specific API path (i.e. Actor.applyDamage) instead of being essentially an alias for the existing Actor update hooks?
That kind of feels like making something 'worse' just to avoid a little complexity.
Is it "fine" that it relies on a specific API path (i.e. Actor.applyDamage) instead of being essentially an alias for the existing Actor update hooks?
That kind of feels like making something 'worse' just to avoid a little complexity.
Calling it on every change to hp.value seems like it would produce a lot of false positives (e.g. changing HP when levelling up, or just editing an actor), and I'm not really sure how you'd distinguish those. In particular, a GM adjusting monster HP due to something else going wrong (e.g. "this goblin has 10 hp but should have 5") shouldn't trigger this hook if it's then going to allow modules to mutate the "damage" - could resolve this by requiring a damage type, but then it makes it potentially less useful for the "roll dice -> right click -> apply damage" workflow.
Roughly, I think Actor#ApplyDamage is a reasonable flag for "is this actually damage rather than an HP update", but maybe with an explicit ask for other modules to call this hook as needed.
Unlinked tokens aren't actually a mess in the updateActor hook, since that passes token.actor for an unlinked token, so the same behaviour here would be fine.
Roughly, I think Actor#ApplyDamage is a reasonable flag for "is this actually damage rather than an HP update", but maybe with an explicit ask for other modules to call this hook as needed.
Unlinked tokens aren't actually a mess in the updateActor hook, since that passes token.actor for an unlinked token, so the same behaviour here would be fine.
We'd be putting this into the Actor#applyDamage method, so as long as modules call that when things damage creatures (which they are incentivized to do anyways because it handles temphp correctly), the hooks would fire.
also that's good to hear about unlinked tokens, that's one of the last bastions of things that still scare me because I haven't looked too closely yet
I agree that having a distinction between "yes I definitely meant to change the actor" and "this is the actor taking damage" is a good one to have. I think an additional UI way to trigger this method would be helpful to really drive home the difference.
E.g. a "manage HP" button on the sheet or something like that
E.g. a "manage HP" button on the sheet or something like that
Yeah, I expected to run into that minefield when doing Memento Mori, and then it just worked.
Message Not Public
Sign In & Join Server To View