Ghost Optimization

[downfall318]

I am still a bit of a newbie when it comes to ECS and Netcode but based on my understanding:

There is a 128 unique limit on ghosts

Each ghost authoring consumes one of those

There must be some packet usage to specify which of the 128 you are using.

Why cant we use a little more overhead to specify which of the 128 and which prefab it maps to? So that all ghost components that only interact with a transform for instance can use the same one out of the 128 limit?

(I see that it might not be as simple when multiple ghost fields are added bc it will be hard to determine which slice of fields contribute to a new map.)

Is there a better way to do the following now? Have a ghost entity with an int id and a ‘new item tag’, collect these ‘new item tags’ in client world and create prefabs for them from the id and then add ‘second stage tags’ on the prefabs, removing the ‘new item tags’ then assigning the linkedentitygroup from the prefab to the ghost entity from the ‘second stage tags’.

[NikiWalker]

Hey downfall,

@downfall318

There is a 128 unique limit on ghosts … Each ghost authoring consumes one of those

No, it’s specifically a limit on in-use ghost components (denoted by GhostField or GhostComponentVariation), and this limit can be increased to 256 via the NETCODE_COMPONENTS_256 compile time flag.

@downfall318

There must be some packet usage to specify which of the 128 you are using.

I believe each component must only be present in a loaded ghost type to be considered “in use”.

@downfall318

Why cant we use a little more overhead to specify which of the 128 and which prefab it maps to? So that all ghost components that only interact with a transform for instance can use the same one out of the 128 limit?

The limit is relatively technical:

1. The DOTS safety systems must be able to inspect fields on job structs to find RW and RO component types (like ComponentTypeHandle, BufferLookup etc).
2. It also doesn’t currently support containers of type handles (we’d need a NativeList<DynamicComponentTypeHandle> in our case), and does not provide a broad way for us to specify “reads so many ECS types in practice, that we would prefer to just treat this job as special/exclusive”.
3. Therefore, we unroll the DynamicComponentTypeHandle into 128/256 fields (see DynamicTypeList), so that the safety system can find them appropriately.
4. We also have highly generalized snapshot send systems. E.g. The GhostSendSystem (and all related systems) handles snapshots for all connections, for all ghost types, in a few jobs. We therefore compile this unrolled list of type handles via DynamicTypeList on the fly, and pass them into these jobs.

@downfall318

Is there a better way to do the following now? Have a ghost entity with an int id and a ‘new item tag’, collect these ‘new item tags’ in client world and create prefabs for them from the id and then add ‘second stage tags’ on the prefabs, removing the ‘new item tags’ then assigning the linkedentitygroup from the prefab to the ghost entity from the ‘second stage tags’.

Can you more explicitly describe your use-case? It’s hard to make sense of what you’re trying to do here. We do support runtime generation of ghost prefab types (see GhostPrefabCreation.ConvertToGhostPrefab), but to do so, you must call this API identically on the client and server (including in the same order, IIRC), with identical component lists, and identical LinkedEntityGroup and transform hierarchy data.

[downfall318]

Thanks for the detailed response - i am adding items to the world (loot) and i am making a ghost containing the id of the prefab that it correlates to instead of making a ghost per prefab so the client would have to take the ghosts and instantiate the prefabs too based on the id

Claude / gpt told me that the authoring contributed to the limit so thats where that came from

[NikiWalker]

@downfall318

Claude / gpt told me…

Ah, yeah… You can’t trust 'em with anything