There is a well estabilished relationship between them so that we can say that any encounter owns exclusively its own triggers, spawners and waypoints so we need to esplicit this relationship in the scene graph so that mechanics based on this relationship can be scripted without further manual setup.
Actually the entities are simply placed in some kind of entity category and so the relationship is manually set in the script by coupling entities in an error prone process involving proper naming.
while a more efficiently packed setup scales better in any possible way, the actual one just seems to suffer at the current complexity level and requires overally more precision in naming things correctly to make things work.
Use scene graph to group by category is indeed totally wrong as it doesn’t communicate any spatial relationship.(an edit time tag system could be more appropriate for this kind of grouping)
When a trigger is activated it now calls any active AiSpawner entity as they listen all on the same Id so that they needs to further check for the group you are willing to activate, but why this selection is not done before so that the entire concept of group can be inferred by the hierarchy?
The proposed change simply leverages the possibility to handle request on a group specific entityId as the main channel to listen on events that occurs at the group scope.In a hierarchycal setup that id is just the group parent entityId.The group can listen for trigger events and post events at it’s own address where its children are listening all automated without further setup.
This concept is indeed even applicable in few other spots of the sample to make simpler and leaner setups.