#Active Effect architecture

1 messages · Page 1 of 1 (latest)

subtle moat
#

If there's any AE related gitlabs with these sorts of conversations that someone knows about, I'm down to trawl old convos for treasure.

pearl rose
#

Good questions:

  1. To be honest, I don't know why we reset transfer: false when the AE is transferred to the Actor. It doesn't seem like it would be harmful to keep that field, and it might even be valuable for providing context as to why the AE exists (or whether it should be removed when the item is). It seems like a strange decision to me also, so I wonder if it's an artifact of an early phase of the AE system design where it initially seemed necessary and then later wasn't

  2. This is more clear to me. There is a pretty rigid system limitation that our backend ODM does not support pathways for "grandchild" embedded documents. The API's for management of embedded documents will choke and fail if the parent is not a primary document.

subtle moat
elfin scarab
#

Regarding 2: it’s also a bit of a weird situation because if you were to edit the effect on the embedded item, you probably also would want to adjust the transferred effect…

elfin scarab
#

I think DAE works around this somehow. They basically do what you suggested and then delete the transferred effect and copy it from the item to the actor again

subtle moat
elfin scarab
#

Personally, I’m not completely sure if I like the approach of transferring effects because it results in the problem of having the data basically duplicated inside the actor, which would exist, even if you were able to update embedded documents inside embedded documents

#

If that was possible, I think it might have been easier to just refer to the effects inside the item, instead of copying it over. It still makes sense to allow active effects inside an actor because you could create them directly or they transfer them explicitly from an item that is not owned by the actor (e.g. from a spell that is activated, or similar)

#

But I’m sure there were good reason for choosing the current design. And with updating embedded items in embedded items not being possible, that’s all hypothetical anyways 😄

subtle moat
#

One of the random thoughts prompting this line of questioning is the idea of inferring transferred effects instead of actually transferring them.

But not being able to edit those inferred effects is a bummer.

elfin scarab
pearl rose
#

If transferred effects were immutable, inferring them from the item would make a lot of sense

#

but given the need to edit them, I'm not sure it's a good solution

#

feels like veering into "unlinked synthetic token" territory which has been a PITA for lots of reasons

elfin scarab
#

But isn’t the situation quite bit different, considering that the effects are basically already inside the actor? You could just access the effect instances that are inside the embedded item. No need to „fake“ anything…?

#

I might try to implement this as a poc in my system

#

I mean, yeah, if you want to edit the effects on the actor, it becomes a bit more difficult. But that wouldn’t be a problem if you could just edit the effects in the embedded item

vague shuttle
#

Was the performance overhead of never transferring AEs and just applying them directly from embedded items as part of data preparation going to be too much?

marble raptor
#

I suspect recursively searching for any potentially applicable AEs in all embedded documents might be prohibitively time-consuming, especially depending on how often that check needs to run

vague shuttle
#

recursively?

marble raptor
#

You need to recurse into the embedded Document (Item) to get the effects from it. And because it wouldn't know what items have effects, it would need to run on every item any time data was prepared for an actor, if I'm reading your comment correctly