edit-owned-item-effect

I've made an abomination. This hacks its way past the limitations surrounding editing effects on owned items as elegantly as I know how to, it even calls the _pre and post methods for the AE document along the way.

@ghost this might interest you if nothing else as a proof of concept tangential to what you're thinking about

The hooks seem to have been lost in the cracks

the transferred effect is not changed, not messing with that but the path to it is pretty clear IF you have a sourceId flag on your Actor's effect

since that isn't there by default, you'd be guessing which effects to update (or wholesale deleting and remaking the effects every time, which is less bueno)

incidentally, 👍 this bad boy for me:
https://gitlab.com/foundrynet/foundryvtt/-/issues/6399

none of this is patched, it's all shennanegins with item sheet hooks and a DIY activeEffect extension

Yeah, I've been doing that with my modules but I'm afraid it's a long road forward and not a stable assumption

I use that for ensuring there's no duplicates created if someone hits "transfer effect" repeatedly

Perhaps it would be a nice idea to add a button somewhere to reapply the effect to the actor? This way you could delete the old effect and effectively 'update' it

that's what the little hand is on the item sheet effects list

Two steps ahead I see :)

This is kind of three steps away from being able to fully derive transferred effects on the actor...

Which is interesting, but a little too far for my taste with a module, I might try it for the fun of it, but it makes me nervous without more system control

hang on let me push

Is this going on a separate module or dnd5e itself?

separate module for sure, i doubt i could get this into the system

I've a feeling this is almost system agnostic actually

not really sure how much AE stuff 5e actually does vs just using core's

https://github.com/ElfFriend-DnD/foundryvtt-edit-owned-item-effects/blob/main/scripts/classes/owned-item-effect.js

This class 'extends' ActiveEffect and overwrites create delete and update to make them work.

Opening an item's effect is basically instanciating one of these with the effect's data and then the rest kinda... just... works.

The document lifecycle is a rats nest but I suspect it wouldn't be terribly difficult to get the hooks working as well

Yeah I think to get really bulletproof API-wise, some deeper method overwriting is a good idea.

I'm just happy to be able to open a spell on a player, make a quick and dirty effect on it to mark that "This creature is affected by that spell" finally