Second player does not synchronize host player if they join too quickly (Distributed Authority)

[afarchy]

Description

We're using Multiplayer Services and Distributed Authority. Sometimes we hit a race in which Player 2 doesn't get updates from Player 1. Here's the sequence:

• Both players try to quick join a session using MultiplayerService.Instance.MatchmakeSessionAsync
• One player ends up creating the session and the other player joins it.
• The session owner (player 1) can see player 2 just fine
• Player 2 can see player 1, but none of their network variables (e.g. Network Transforms) are updating. They are stuck in the initial spawn position.
• Player 2 can leave and rejoin the session. Then everything works as expected.

Reproduce Steps

We can force this to reproduce every time by adding a delay to ConnectionApprovedMessage.Handle:

        public void Handle(ref NetworkContext context)
        {
            System.Threading.Tasks.Task.Delay(10000).Wait();

Actual Outcome

Player 2 is frozen for Player 1.

Expected Outcome

Player 2 is not frozen for Player 1.

Environment

• OS: Windows Editor, Meta Quest
• Unity Version: 6000.0.41f
• Netcode Version: 2.0.0
• Netcode Commit: f2e776e

[NoelStephensUnity]

Hi @afarchy ,

If you could either describe your project flow in more detail or provide a replication project?

Providing Details

If describing your project/providing more details I need to know:

• How and when the player prefab is being instantiated and spawned.
  • If you are using the NetworkManager auto-spawn then just say that, otherwise if you are handling the instantiation and spawning of players I need to understand that flow.
• Are you loading any scenes upon the 1st (session owner) or 2nd client joining?
  • If so, at what point in the 2 clients connecting to a session is this happening?

The more details the faster I can identify where the issue is occurring.

Providing a Replication Project

The fastest path to identifying the issue would be having access to a project that replicates the issue.
There are two ways you can provide a replication project:

• Submitting the issue via the editor.
  • If you do this, then you should get a response email with an issue/ticket number (post that here so I can get the issue assigned to me faster).
• Providing a zip file.
  • If you do this, then you only need to include the Assets, Packages, and ProjectSettings folders in the zip file.
  • Remember to unlink the Project Settings-->Services information before creating the zip file.

We are aware that there are certain logical flows that can lead to this kind of issue and are still trying to identify the related timing... typically the timing issue happens under the following scenarios (with more details but I am providing the general overview of each):

• Scenario-1:
  • Client-A creates a session from Scene-1 and remains in Scene-1 until another client joins.
  • Upon Client-A being notified that a 2nd client joined (Client-B), Client-A loads a game-play scene (Scene-2).
    • Client-A manually instantiates and spawns its player (prior to scene loading or during scene loading).
    • Client-B instantiates and spawns its player upon receiving the ClientConnected event.
• Sceneario-2:
  • Client-A creates a new session.
    • Upon the session being started, Client-A manually instantiates its player (before the ClientConnected event is triggered).
  • Upon Client-B joining the newly created session, Client-B manually instantiates its player (before the ClientConnected event is triggered).
• Scenario-3:
  • Clients manually instantiate and spawn their player prefab instance setting "destroy with scene" to true.
  • The session owner loads a scene when there are (n) clients connected to the session.

[afarchy]

Thanks @NoelStephensUnity, it might take me some time to come up with a minimal repro, but here's our setup:

• Yes we are using AutoSpawnPlayerPrefabClientSide to spawn the players.
• We have Scene Management enabled, but we're not loading any scenes after creating the session. Only one preloaded scene is synchronized. This is an addressable scene, so we made some MINIMAL changes to support that here: develop-2.0.0...virtual-maker-net:com.unity.netcode.gameobjects:develop-2.0.0

I'm not sure if it's only the player prefab that is not synchronized. We have some grab interactions, and we transfer the ownership of those grabbed objects to the player grabbing them. We noticed that when this bug repros, these objects don't synchronize from Player 1 -> Player 2, but the do sync from Player 2 -> Player 1. These objects are pre-placed in the loaded scene.

So, none of the scenarios you describe seem to match...

[NoelStephensUnity]

Ahhh... I see... you are adding addressable scene information using a modified version of NGO. You should definitely always provide us with that bit of information (i.e. you are using a modified version/fork of the NGO SDK) and should not mark any issues you encounter as a bug but as support unless you specifically know exactly where in the SDK the bug resides. That will help us better understand how to assist you in the future.

With that said... 😺
This kind of modification will definitely cause issues (today/currently) with a distributed authority session because the distributed authority service has no visibility/awareness of those scenes based on the changes you have made in your fork.

This means anything spawned within those scenes will contain scene handles the service is not aware of... which will indeed cause issues and most likely lead to a failure to synchronize a spawned object that is within a scene that was not included within the scenes in build list but was loaded as an addressable.

In order to get things synchronizing properly with a distributed authority session, you will need to not use addressable scenes as it pertains to "netcode" related objects...

So as an example:

• DefaultActiveScene (could be empty but added to the scenes in build list so the handle is synchronized with the service when the session starts).
  • This is where you want to instantiate and spawn objects.

If you have in-scene placed NetworkObjects that you are including in your addressable scenes, then it gets a bit tricky... the idea is that if the service doesn't know about the scene handle then it will not attempt to synchronize anything regarding that object...this is for several reasons that range from preventing bad actors from trying to just "add random things" to the fact that NGO does not officially support addressable scenes (yet) and so there is no way to communicate to the service that the scenes exist.

The scene handle information is sent by the session owner to the service upon the session owner getting the connection approved response from the service...

You could (in your fork) modify the NetworkSceneManager.SynchronizeNetworkObjectScene so that when it generates the list of scene handles for the scenes loaded on the session owner side that it will be included in the synchronization event.

You also need to make sure that the ServerSceneHandleToClientSceneHandle and ClientSceneHandleToServerSceneHandle tables are updated properly (your fork-side scene addressable addition commit does not include that modification and will eventually lead to other issues down the road).

I am marking this as a feature request as opposed to a bug since the issue you are having is pertaining to the modifications you made to the NGO SDK that are causing the synchronization issues and not the NGO SDK itself (as it is).