com.unity.netcode.gameobjects: NetworkObject binding failed on Host and Client
Describe the bug Main error : Cannot find pending soft sync object. Is the projects the same? When starting an host that switch scene, the binding between any new client for any networkedobjects is not working. That result with different network id for scene objects (one that have networkedobject on).
To Reproduce Steps to reproduce the behavior: Go to this github repository : https://github.com/Pourfex/IssueSceneHostMlapi Make 2 projects with this repository. One should start playmode and press space to be the host. One should start playmode and press b to be a client.
An error on client occured, you can check on the interaction scene the network id that are not the same.
The workaround for now is on the same repository on the branch “workaround”
https://github.com/Pourfex/IssueSceneHostMlapi/tree/workaround which is using Unity Scene loader before starting the host.
Expected behavior The networked behaviour should have the same networking id and no error should be displayed
Screenshots
Error on client :

Environment (please complete the following information):
- OS: Windows 10
- Unity Version: 2019.3.3f1
- MLAPI Version: 6.0.1
Additional context Use in another context, find the bug and discuss it with NFMynster on discord. The workaround is to use the Unity Scene loader before starting the host like this :
SceneManager.LoadScene("InteractionScene");
SceneManager.sceneLoaded += (arg0, arg1) => {
NetworkingManager.Singleton.StartHost();
};
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 1
- Comments: 39 (18 by maintainers)
Ok, I am an idiot, I had the problematic code commented out in the NetworkController in master, that is why it was working for you. If you pull you should have the exact same project as I have now with the same problem.
I am sorry for the confusion, that was a bad mistake.
I have invited you to the project on GitHub.
Hi MrCandle,
Typically a “soft synchronization” issue happens with in-scene defined GameObjects that have a NetworkObject component (i.e. you create an empty GameObject in a scene and add the NetworkObject component). The “soft synchronization” aspect is due to the fact that when that scene is loaded the GameObject along with the NetworkObject component will be instantiated without having been registered with the NetworkSpawnManager system (i.e. with MLAPI). So, when a server sends a SCENE_SWITCH command or a client is joining the server will send the current scene that is loaded along with the NetworkObjects (with their prefab hash and associated NetworkObjectId). The client uses each NetworkObject’s prefab hash value sent to uniquely identify the in-scene placed NetworkObjects (client side) and upon finding it will assign the associated NetworkObjectId and register it locally to the client as being a “spawned NetworkObject”. The issue, for v0.1.1 and earlier, that occurred more often than not was NetworkObjects that had the same “Prefab Hash Generator” name would generate the same prefab hash value, and as such the first time that prefab hash value was found it would register the associated NetworkObjectId and then remove that prefab hash value from a list being tracked within the NetworkSceneManager. When the next NetworkObject was being processed, with the same prefab hash value, it would cause a soft synchronization error because that prefab hash value had already been processed.
The difference with Player NetworkObject instances is that they are moved into a “Do not destroy on load” temporary scene during a scene transition, and then moved back into the newly loaded scene once it was done loading. So, our solution in v1.0.0 is the GlobalObjectId which is a “project wide” universal identifier for all NetworkObject instances which avoids the issue with multiple NetworkObjects that have the same “Prefab Hash Generator” value.
So, I don’t think any issues you might be having with soft synchronization errors is pertaining to your Players as they aren’t part of the list of NetworkObjects taken into consideration.
My problems were fixed moving to the develop branch.