RPC and NetworkBehaviour methods execution order

Hi folks,

I need to get information about RPC and NetworkBehaviour’s spawn methods execution order.
I build a game with NGO and Dedicated Server.
When late join client or reconnected client join the game, I need to know execution order of RPC methods and OnNetworkPreSpawn, OnNetworkSpawn,OnNetworkPostSpawn and OnInSceneObjectsSpawned methods in a NetworkBehavior class.I know each NetworkBehaviour class RPC order are different but I need only one object’s method order.
I searched on Discussions and Documentation but I couldn’t find it.

Thanks for helps.

What exactly about the order do you need to know?

For spawning, this is easy: PreSpawn, Spawn, PostSpawn
Whether OnInSceneObjectsSpawned is called before or after they spawned (I assume after) you can find out by adding a log.

Call order between individual RPCs is not something you should rely on in principle, and it cannot be relied upon due to latency, thus it doesn’t and mustn’t matter. The time when RPCs execute is when a network tick occurs, and I think they get called before Update.

You can inspect the PlayerLoopSystem to find out exactly where the Netcode hooks run respectively which methods these are, and then look at the code.

You could also tell us about the problem you’re trying to solve. :wink:

For example, there is a NetworkBehavior class and this class has ClientRPC. When late joiner or reconnected player join the game/scene the the client can received the ClientRPC.
And somehow the ClientRPC message can receive before any other object initialization time and this makes an exception.
I can prevent this exception but I wonder the execution order.

I’m not asking order of these method: “PreSpawn, Spawn, PostSpawn”

I’m asking where RPC order? Ex:
ClientRPC => PreSpawn => Spawn => PostSpawn
or
PreSpawn => Spawn => ClientRPC => PostSpawn
or any other combination.

I tried to add log but each time RPC receive different time.
ClientRPC received after OnInSceneObjectsSpawned
or
ClientRPC received after OnNetworkSpawn

But I want to know NetworkBehavior and RPC order of operations.

Well, this could be solvable through architecting the code correspondingly. For instance, if the RPC tells the client to fire a weapon when that player isn’t already spawned, you could just ignore that command. Some commands in late-joining games should be ignorable, especially if the next update is just milliseconds away.

Or just delay the execution of whatever is inside the RPC until after the client-side setup is done.

You should also use NetworkVariable for anything that late-joining clients need to have synchronized in case you are doing this with RPCs.

Like I said, this is not possible to tell. There are at least two kinds of latencies involved: the time it takes for the scene to load and initialize, and the time it takes for an RPC to be received over the network. You need to work with this ambiguity, you cannot fight it.

In addition to @CodeSmile 's response, you most likely want to focus more on:

  • When the RPC is being invoked (which then sends the message to the reconnecting client).
  • If anything within the RPC method is trying to access other NetworkBehaviour components.

If your server is sending one or more RPC(s) to a reconnecting client, then you will want to register (on the server side) for NetworkManager.SceneManager.OnSynchronizeComplete and invoke the Rpc(s) at that point in time as that notification means that the client has fully synchronized (i.e. all scenes required are loaded and all NetworkObjects spawned on the newly connected client side).

You can view the documentation for more information about SynchronizeComplete here.

1 Like

Thanks for your answers.

@NoelStephens_Unity So, we can’t be sure if the RPC is triggered before or after OnNetworkPreSpawn, OnNetworkSpawn or OnNetworkPostSpawn.

I was thinking that NetworkBehavior works like this: if the RPC comes before the OnNetworkSpawn method of its NetworkBehavior object, that object will list the RPC and trigger it after the OnNetworkSpawn method.

Hi @Mj-Kkaya,

If the NetworkObject is not spawned prior to receiving an RPC targeting a NetworkBehaviour component belonging to that NetworkObject instance, then it will be deferred and invoked after that NetworkBehaviour has invoked NetworkSpawn.
(you can see the code that does this here)

So, you can be sure that by the time that component’s NetworkBehvaiour.OnNetworkPostSpawn is invoked the RPC should have been processed.

However, if the NetworkObject is fully spawned, which means the component’s NetworkBehvaiour.OnNetworkPostSpawn will have already been invoked, then the RPC will be immediately processed…but if you have code within NetworkBehvaiour.OnNetworkPostSpawn that is expecting that RPC to have been invoked already it will fail (because the RPC will be invoked most likely a few frames later).

Since an RPC can be impacted by latency, sending an RPC for some kind of client re-synchronization could be problematic. To avoid issues with synchronizing a reconnecting client you can:

  • Send the RPC when NetworkManager.SceneManager.OnSynchronizeComplete is invoked on the server side.
    • This would happen sometime after the NetworkObject is spawned.
  • Send custom serialized data using NetworkBehaviour.OnSynchronize<T>
    • (More information about this here)
    • This would be available when NetworkBehaviour.OnNetworkPreSpawn is invoked.
      • Really, it is available when NetworkBehaviour.OnSynchronize<T> is invoked on the client side when it is deserializing the custom data. You can set some private property of the NetworkBehaviour that will be available on any of the NetworkBehaviour component’s spawn related virtual methods.
  • Use a NetworkVariable that uses an INetworkSerializable implementation that can be set upon the player prefab being spawned for the the reconnecting client.
    • This would be available when NetworkBehaviour.OnNetworkSpawn is invoked.

Let me know if this helps clear things up a bit?

1 Like

@NoelStephens_Unity, Yes it’s very clear. Thanks for your detailed explanation.