Common Pitfalls
Common Pitfalls
1. Modules Must Be Fields or Properties
Network modules must be declared as a field or property on a NetworkIdentity.
Do not create them dynamically or store them in collections.
public class MyNetworkObject : NetworkIdentity
{
public SyncVar<int> health; // ✅ Correct
private SyncList<string> names; // ✅ Correct
// ❌ Incorrect: Do not use lists of modules
public List<SyncVar<int>> invalidList;
}2. Editor Serialization
Modules can be serialized and shown in the Unity Editor.
Just mark them with [SerializeField] or make them public.
[SerializeField]
private SyncVar<int> health; // Will show up in the Inspector
public SyncList<string> names; // Also visible if public3. Initialization: Use OnInitializeModules()
OnInitializeModules()You can create, override, or initialize modules in the
protected virtual void OnInitializeModules() callback.
This runs before networking sends data or assigns IDs.
4. Do Not Replace Modules After Spawn
Once spawned, never assign a new module instance to a field/property. Doing so will break networking or cause undefined behavior. Modules are meant to be constant after spawn.
5. Nesting Modules
You can nest modules—meaning a network module can use other modules like SyncVar as fields or properties.
Do not create circular dependencies. If Module A uses Module B, and Module B uses Module A, it will break. Nesting must form a tree, not a loop.
6. No Lists of Modules
You cannot create a list or array of modules. Modules must be declared as fields or properties at compile time.
7. Module Events
Modules have similar events to NetworkIdentity, such as:
OnSpawnedOnOwnerChangedOnDespawned
You can use these for custom logic inside your modules.
Last updated