How does ZDoom determine if it is "out of sync"?

[RaveYard]

This eludes me. How does ZDoom determine when it is "out of sync" with somebody?
I tried to look into the source code but I can't find or comprehend anything in d_net.cpp

What I am looking for is what exactly is checked...

Also, is it possible to hide the "out of sync" message?

[edward850]

Each gametic, a player creates a checksum of themselves which is built out of a selection of PRNG table index positions (pr_spawnmobj, pr_acs, pr_chase (A_Chase) and pr_damagemobj), followed by the player position & health values.
(pr_spawnmobj, which increments for every actor that ever spawns, is the most volatile.)
This checksum is then transmitted to each node to which they compare and store each result. In the HUD, a message buffer goes through each node checking this status. If the checksum stays wrong for the last 36 tics (the size of the input buffer), that node is displayed as out of sync.

You cannot hide this message as it's pointless to do so. The game has already irreversibly failed and it's basically telling you to save and quit, or better yet check what you've launched is consistent in the first place.

[RaveYard]

Thank you very much!

Can you fix this issue by saving the game, quitting and loading the saved game?
I'd imagine, that one of the players would have to send his save to rest of the players... no?

[edward850]

Yes, that exactly works. Loading a game only takes player names into account for identification, so you can copy the same save to other players, or even new players. However do note my previous point; If the game is out of sync, something is inconsistent in the game itself. You do actually want to check what everyone is loading is actually the same. This includes autoloads. At this stage, assuming everyone is running the same build of ZDoom, no playsim synchronization issues should be expected.

It's not a casual error message, something is critically wrong with your game.

[Nash]

You are not supposed to see the game go out of sync, ever... if you see that message at any point in time, even once, everything is horribly and irreversibly damaged and something went wrong, probably wrong/mis-matched load order of WADs, someone probably had autoload turned on and it autoloaded mods that other players don't have... things like that. Don't attempt to "hack" your way around desyncs by saving/reloading, or trying to hide the message... fix the problem at the source.

Ed - you should consider marking saves made after desyncs as devalidated so that they can't be loaded ever again haha.

[edward850]

Ed - you should consider marking saves made after desyncs as devalidated so that they can't be loaded ever again haha.

There is currently one case which would make that rather annoying, actually. If a player disconnects, there is the possibility the message times improperly and the game desyncs from that for all remaining players (an old vanilla bug, it's a core protocol issue that can't be casually fixed). At that point you'd want to be able to save and reload.
Plus there was one case during early DRLA where we had a desync caused by someone having an older version of the mod. Didn't trigger until 7 maps in and still being able to save and reload helped after we fixed the problem player. A specific scenario, but certainly and notable edge case.

In Master/Slave I'd like to be able to do something similar, being able to save the game if the server drops while still having all players intact (acting as a stand-in from P2P's instant arbitrator migration).

[NeuralStunner]

I'm not sure why you would want to invalidate desynced saves. As Ed said, any given peer's "version of events" can be saved, shared, and distributed to the other players once the cause of the desync is cleared up.

I will always consider savegame sharing to be one of the best things about the Doom engine's netcode. (Ever since I used this method to rescue a vanilla Hexen coop run from the infamous Gibbet dead end.) So don't "fix" it.