Closed dxinteractive closed 1 year ago
Just experimenting, it seems likely that the more accurate check is to look if the specific entity is entity.alive
before removing.
Correct, checking entity.alive
is the right thing to do in this case. It checks the same flag that causes entity.delete()
to throw, and it's documented to return the same value where accessRecentlyDeletedData
is true or not.
Makes sense, thanks!
If not, I think this could be useful.
Reason: Sometimes I have a function (
foo()
) that does useful things to entities, in situations whereaccessRecentlyDeletedData(false)
and also whenaccessRecentlyDeletedData(true)
. While accessing recently deleted data mode is on, I want to avoid callingentity.remove()
on a recently deleted entity, because it's deleted already and an error is thrown in dev mode if I were to try. But I can't see a Becsy-API way of asking if accessRecentlyDeletedData is true or not, to make that check possible.Alternatives:
accessRecentlyDeletedData()
in my own function that also sets a variable of my own to track this, but this leaves open the ability for people to still callaccessRecentlyDeletedData()
directly and making my new variable incorrect.this.__dispatcher.registry.includeRecentlyDeleted
from any system, but obviously not ideal because that's internal, undocumented and might change in future versions of becsy.foo()
itself at the location where it is called e.g.foo({includeRecentlyDeleted: true})
, to then conditionally callentity.remove()
insidefoo
, but this feels like double-handling a piece of state that I know exists already inside of becsy.Open to any thoughts!