Currently, the client spawning of entities is handled by an InterestManagementSystem. For example, BruteForceInterestManagementSystem looks at all entity chunks that have (NetworkObserver,RebuildNetworkObserver,NetworkEntity,Translation). Since NetworkEntities also always have NetworkObserver & RebuildNetworkObserver dynamic buffers, this means it looks at all NetworkEntities.
As far as I can tell, it is currently not possible to spawn entities on clients that are far away, but have components with relevant data. Even if I add an InterestManagementSystem that spawns all entities with a specific tag, these would be deleted in the next BruteForceInterestManagementSystem update cycle, since they are too far away.
An example would be a game that has NPCs running around (BruteForceInterestManagementSystem), but also has entities with components containing data for procedural map generation, which are much farther away, that the client would use to generate a map (AlwaysSynchronizeInterestManagementSystem).
I propose that BruteForceInterestManagementSystem also requires an additional component in its Entities.ForEach (added via authoring), and will ignore a NetworkEntity otherwise.
This would also make it possible to make many different InterestManagementSystems that look at different subsets of entities. In the above example, all NPCs would have a e.g. BruteForceInterestManagementComponent, whereas all entities containing map information have a component of e.g. AlwaysSynchronizeInterestManagementComponent.
Currently, the client spawning of entities is handled by an InterestManagementSystem. For example, BruteForceInterestManagementSystem looks at all entity chunks that have (NetworkObserver,RebuildNetworkObserver,NetworkEntity,Translation). Since NetworkEntities also always have NetworkObserver & RebuildNetworkObserver dynamic buffers, this means it looks at all NetworkEntities.
As far as I can tell, it is currently not possible to spawn entities on clients that are far away, but have components with relevant data. Even if I add an InterestManagementSystem that spawns all entities with a specific tag, these would be deleted in the next BruteForceInterestManagementSystem update cycle, since they are too far away.
An example would be a game that has NPCs running around (BruteForceInterestManagementSystem), but also has entities with components containing data for procedural map generation, which are much farther away, that the client would use to generate a map (AlwaysSynchronizeInterestManagementSystem).
I propose that BruteForceInterestManagementSystem also requires an additional component in its Entities.ForEach (added via authoring), and will ignore a NetworkEntity otherwise.
This would also make it possible to make many different InterestManagementSystems that look at different subsets of entities. In the above example, all NPCs would have a e.g. BruteForceInterestManagementComponent, whereas all entities containing map information have a component of e.g. AlwaysSynchronizeInterestManagementComponent.