public readonly record struct NetworkPrefabIdWhich template an instance was stamped from.
No guide page documents this yet — the page shows what the code says about itself.
Remarks
Derived from the addressable's address, not from a list somebody maintains. [08](../../../docs/plan/08-asset-pipeline-and-addressables.md) already gives every piece of content a stable address and a deterministic build, so the id is a pure function of the address and both ends compute the same one without ever exchanging it. The alternative — the "network prefab list" every engine that lacks a content pipeline ends up with — is an ordered array whose indices are the wire format, which desynchronises the moment two people add a prefab in different orders on different branches.
The address, not the content hash. The catalog has both: a CatalogEntry.Address that a human authored and an ObjectId of the bytes. The content hash is the tempting one because it proves the two ends hold the same asset — and it is wrong here, because it changes with every edit to the prefab, so every content patch would renumber the wire. Whether the two ends hold the same content is a question to settle once, in the handshake, rather than smear across every spawn.
Fields and properties (3)
public uint ValueThe hash. Zero is None.
public static NetworkPrefabId NoneNot a prefab.
public bool IsValidWhether this names one.
Methods (3)
public NetworkPrefabId(uint Value)Which template an instance was stamped from.
public static NetworkPrefabId From(string address)The id an address hashes to.
public override string ToString()Returns the fully qualified type name of this instance.
Used by (6)
- BitExactnessTestsVixen.Net.Tests
- NetworkPrefabVixen.Net.Engine
- NetworkPrefabRegistryVixen.Net.Engine
- NetworkSpawnSystemVixen.Net.Engine
- NetworkSpawnTestsVixen.Net.Engine.Tests
- NetworkSpawnerVixen.Net.Engine