public static class WorldDigestA hash of everything in a world, computed in an order that does not depend on how the world got that way.
No guide page documents this yet — the page shows what the code says about itself.
Remarks
Two worlds fed the same input must end up the same, and "the same" has to mean something checkable. Entity rows move between chunks on every structural change and archetypes are created in first-use order, so a naive walk hashes the history as much as the state. This walks archetypes ordered by their component type names and rows ordered by entity id, both of which are properties of the state alone.
Names, not ComponentTypeIds: ids are handed out in first-touch order, so a world that reached the same state by a different route would order its archetypes differently and hash differently. That is the same reason a serialised world names its component types by alias.
Managed components are not hashed, and the count of them is. Their bytes are a handle into a per-world store, so hashing those would say two identical worlds differ; hashing the values needs a serialiser per type, which is [08](../../../docs/plan/08-asset-pipeline-and-addressables.md)'s problem. Including how many there are keeps a difference in structure visible even when the contents are not.
Methods (2)
Used by (1)
- DeterminismTestsVixen.Ecs.Tests