@modoki/engine / index / isEntityActiveInHierarchy
Function: isEntityActiveInHierarchy()
isEntityActiveInHierarchy(
index,id,visiting?):boolean
Is id active — itself AND every ancestor (EntityAttributes.isActive)?
The deactivatedEntities twin of this lives in core/ecs/transformPropagationSystem (a sibling since P5; it was under src/three/ before) and is what every RENDERER checks. SIM systems still can't use it for three reasons: it is built by a module whose matrix math is THREE (importing it drags three into a 2D-only/playable bundle), it is produced at TRANSFORM priority (200) so a system running earlier — timelineSystem is at 149 — reads a one-frame-stale set, and the headless harness registers no propagation system at all, so it is permanently empty there and a unit test could not pin any guard built on it.
So: walk the parentId chain over the index the caller already built — no THREE, no frame lag, works headless. visiting guards a parentId CYCLE (A→B→A), mirroring the _deactVisiting guard in the propagation pass; a cycle breaks to "active" rather than recursing forever. An entity missing from the index (destroyed, or no EntityAttributes) counts as active — the same permissive default the renderers take.
Consumers so far: timelineSystem (a deactivated entity FREEZES its Director) and the 2D/3D zone triggers (a deactivated zone/occupant fires exit, as if despawned). What "off" means is per-subsystem on purpose — see docs/architecture.md "isActive — who honours it". PHYSICS is the remaining gap and this is the seam to close it with, once it is decided whether a deactivated body leaves the Rapier world or stays as an inert ghost.
Parameters
index
id
number
visiting?
Set<number>
Returns
boolean