Network: Despawned Nodes respawn on Clients

[fairhat]

After the latest update (i believe) i noticed a strange bug on my demo project: If a player disconnects, the despawning on the server works perfectly, however on clients the node is despawned, and on the next tick respawned (and it stays there forever).

Is this the only way despawning players on the clients should be done: func on_player_left(pid: int) -> void: network.snapshot_data.despawn_node(NetPlayer, pid)

NetPlayer is my SnapEntity Object and i'm directly assigning the pid of the player to the node (players only have one controllable character)

[fairhat]

Okay apparently this only happens when the player is not moving at all, so i guess the last received server snapshots is the same as the client one

[fairhat]

After digging for a while i found out this is related to delta snapshots and client_check_snapshot in snapshotdata

Clients receive deltas which don't include the node anymore (i assume) and for whatever reason this code is not executed:

snapshotdata.gd (around l550) for uid in local_entity: despawn_node(einfo._resource, uid)

For now just sending full snapshots all the time (eg setting threshhold to 0) works

I guess this shouldn't be a problem when the game is played over the internet or does heavy physics processing, however in my case (a small demo with just X playernodes displayed) the threshhold was rarely/never hit

Maybe a fix could be to determine if a player connected/disconnected and in that case always send a full snapshot once (or until acknowledged)?

Edit: I see that this should not be required since encode_delta checks for objects that were deleted. Maybe that part isn't working?

[Kehom]

I will dig into it. My initial release didn't contain the delta snapshot compression because of lots of problems. Apparently it wasn't ready yet!

[Kehom]

I spent quite some time trying to replicate this issue but it simply didn't happen. Tested on both ENet and WebSocket modes, with multiple clients connected and even using clumsy to hinder the connection state. Do you have any consistent way to replicate this so I could try?

[fairhat]

A quick way to test it could be:

• create a scene where only an object is displayed (which has a state that is being updated but never actually changes)
• set the client threshhold to a crazy high amount

Can try to create a demo for this next week

[Kehom]

Ahhh. You just described one edge case I didn't consider specifically for the delta compression. Yet, it's is the main reason I still didn't implement the entity culling system. That is basically the client state becoming so "outdated" that it will go out of sync. This occurs when the state only changed when it has already left the internal buffer window. This will require quite a bit of extra upkeep but it may provide the necessary data to also implement the entity culling system.