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 public

3. Initialization: Use 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:

  • OnSpawned

  • OnOwnerChanged

  • OnDespawned

You can use these for custom logic inside your modules.

Last updated