Description
Tested versions
- reproducible in v4.3.stable.mono.official [77dcf97]
- untested otherwise
System information
Godot v4.3.stable.mono - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4070 Ti (NVIDIA; 32.0.15.6614) - 13th Gen Intel(R) Core(TM) i9-13900K (32 Threads)
Issue description
I have discovered a senario where some Multiplayer Synchronizer nodes will quietly fail and stop recieving updates after a seperate synchronizer has been despawned. The expectation is that spawning or despawning multiplayer synchronizers should never effect others. Steps the reproduce and seeing the MRP paints a more complete picture as to what the bug entails. Attached is a gif demonstrating this 
I will also describe my use case for this feature.
I'm working on a game where each peer has a player node spawned for them. The player has a weapon which spawns bullets.
I want the bullets to be spawned and owned by the player that created them so that there is no lag between firing your gun and seeing the effect.
The bullet needs a synchromized to sync position.
Because of the bug, when the bullets despawn, the host player synchronizer breaks and the host appears to freeze for clients.
Steps to reproduce
This bug will arise with the following steps
-> Host creates the server
-> Host spawns n objects where n >= 2 which have multiplayer synchronizers
-> Client joins the server
-> Client is given authority over a multiplayer spawner
-> Client spawns n object which have multiplayer synchronizers
-> Client despawns the n previous objects
-> You will now see the n-1 object which the host spawns first no longer is successfully synchronizing to the client
If another client joins at this point they will still recieve updates until they also delete n objects
If the host spawns the objects after the clients have already joined the issue won't arise
Minimal reproduction project (MRP)
My apologies that this requires a .NET setup, due to being unfamiliar with GDscript I'm not able to recreate the issue using it in a timely manner.
To see this issue demonstrated in the MRP, first enable multiple run instances.
To do this go to Debug->Customize Run Instances... and then check Enable Multiple isntances and increase this to 2 (or more).
Running the project (initial scene should be app root) will start two instances of the game.
In one window, press Start Host and then press the + button twice to spawn two Dynamic Elements (nodes the briefly demonstrate a value that is continuously changing and being synchronized)
In the other window press Start Client. This will automatically use your local ip to join the server and you will see the two Dynamic Elements spawn.
Use the + button (its critically not to mix these) to spawn two more Dynamic Elements.
Now in the client, use the cross buttons to delete the elements you spawned.
You should see the first dynamic element has frozen and is no longer updating.
I will also briefly go over the project structure.
The AppRoot node is the main scene which serves to start the network session.
When the session is started by the host, they spawn an Experiment node in the ExperimentSpawner.
The purpose of this node is to provide a top most node for functionality related to this test.
Experiement has a control node and a PeerSpawner node.
The control node contains UI for observing values being changed by synchronizers and to spawn and despawn these objects.
When a peer joins and node is spawned to represent them and the authority of this node is assigned to the peer which joined.
The peer node contains a DynamicElementSpawner which is used to spawn and despawn dyanmic element nodes.
Dynamic element nodes are set up so that only their own runs their process, which changes a value between -1 and 1.
When a dynamic element is spawned, on each peer that it is spawned on it adds a dynamic value display to a container which is a child of the experiement's control node.
this dynamic value display is bound to it to show the value updating, as well as a label clarifying who owns the underlying dynamic element.
On the peer that owns the element, a button will be enabled which frees the dynamic element (this relies on the spawner to automatically despawn it), which in turn frees the display.
MRP.zip