ZDoom

JPL wrote:Would this be obsoleted by a shift to full client/server multi? I realize that's a ton more work and that branch hasn't seen much action lately...

Yes, because that would be essentially what it does on player connect, anyway.

Would this be obsoleted by a shift to full client/server multi? I realize that's a ton more work and that branch hasn't seen much action lately...

Matt wrote: Is there any hope of possibly revisiting this idea?

No. Unless you find someone willing to invest a lot of time here.

It would still be good for:

- trying to isolate the source of the problem without replaying everything up to the point where the desync happened

- when you know what caused it and it's actually something fairly easy to avoid, and you'd rather just keep playing and try to fix it later

- when you know what actions trigger it and it's actually something fairly easy to avoid, but you have no idea what exactly in the code cause it, and you'd rather just keep playing than wait for however long it would take for the modder to figure out what to do with your bug report

The final word is up to the developer team, of course, but I also wanted to share my own opinion on this. According to my observations, GZDoom's network code has improved significantly since 2010. Every desync that I've recently encountered happened due to broken mod code that did not take multiplayer support into account. (Some of that code was mine )

It can be difficult to debug, but almost every time it happens, it is usually not an engine issue but a mod issue. Failing the latter, it could also be the result of a certain player (or players) running different versions of PWADs than that of other players. A "resync" would definitely not help in this case, since it cannot fix differences in mod files.

So this kinda indirectly came up during some discussion on the HD Discord.

Is there any hope of possibly revisiting this idea?

Chris wrote:IIRC, even though it's not a true client-server model, ZDoom still marks a certain player as the server.

"Arbitrator" is the term you're looking for, or at least that's what it's called in-game. The arbitrator gets server privileges (setting of dmflags, sv_ cvars, etc.), but they act no different from any other player from the networking side of things.

[SEMI-EDIT] Kate hinted to it, but that's what.

Yeah, in this case I think it should be limited to net arbitrators, and the arbitrator that issued the command should sync the other clients to their gamestate.

To the player tagged as the server. IIRC, even though it's not a true client-server model, ZDoom still marks a certain player as the server. If different players disagree on the gamestate, then what the server says goes.

Still, to WHAT should they sync? You can be sure that both sides are most likely no longer in a coherent state for both players.

Gez wrote:

Graf Zahl wrote:Thinking about it, how are the computers supposed to recognize that they have desynced?

Since it was about a console command, the computers were supposed to be told that they have desynced by the players.

Exactly. Sync "detection" is entirely up to the players, thus Resync has to be triggered manually through the console.

Graf Zahl wrote:Thinking about it, how are the computers supposed to recognize that they have desynced?

Since it was about a console command, the computers were supposed to be told that they have desynced by the players.

By deferring to who's set as the "server". When a game detects it's been desynced, it would alert the server, which would then make a save of its game(state) and send it out to other players to automatically load.. to get everyone back on the same page, so to speak.

Yes, but then it's mostly too late. The game has desynced long before that message normally so how would you sync a game where both sides disagree about the player states?

Doesn't the game display something on-screen when it desyncs? I don't really play multiplayer, but the few times i have, I could've sworn it displayed a "desync" message when it does.