Bad sync problems ...

[anonone]

I was playing co-op over the 'net, using 2.0.60, and TeamTNT's Icarus. Around map 06, we kept losing sync; this was after playing through the first five maps with no problem. After some eight tries, we skipped the map using < changemap > and went to map07. Problem solved. For a while, anyway -- it de-synced a few minutes into the map.

So, I've got two questions:

1) What usually causes de-sync, anyway? I saw mention of Pain Elementals and whatnot, but from what I remember there weren't any pain elementals on either of the maps.

2) Is anybody else having consistent sync problems like this?

Both of us are on cable modems and the pings are around a steady 24 ms. Strangely, yesterday he was having network troubles and the lag was a little high (framerate was noticeably stuttering), but there was no sync problem.

Out of curiosity, would capping the framerate help?



... In retrospect, I probably should've posted this in Networking ...

[HotWax]

If we knew for sure what caused consistancy failures, they'd have been fixed by now.

[anonone]

Hah, good point. ^_^;;

[randi]

Consistancy failures are caused by not maintaining a perfectly consistant state on each machine, which is almost always caused by programming error rather than network error.

[Chris]

I just had an interesting thought.. What if, when a game goes out of sync, ZDoom throws up a message that it's trying to resync, and what it does to resync is have the player designated as the server make a memory-only save that gets sent out to all the players, and upon receiving it all the players simultaniously load up from that save game, which would cause everything to restart synced again as the server saw things. Actually, it doesn't have to be the server.. ZDoom could do some tests between the machines and determine which player most likely has the "proper" game state and have him/her save and send.

[Jim]

What if, when a game goes out of sync, ZDoom throws up a message that it's trying to resync, and what it does to resync is have the player designated as the server make a memory-only save that gets sent out to all the players, and upon receiving it all the players simultaniously load up from that save game, which would cause everything to restart synced again as the server saw things.

The problem with this is that sending a whole save game would be quite a lot of data. I suppose everyone could wait while SYNCING was shown on their screens. This would become quite old after it happens repeatedly, possibly even every single tic.

The more fundamental problem, come to think of it, is that desyncing would have to be detected somehow in the first place.

[Chris]

I suppose everyone could wait while SYNCING was shown on their screens. This would become quite old after it happens repeatedly, possibly even every single tic.

If it keeps having to resync every frame then the game won't play anyway, whether it tries to resync or not. I'd just think trying to resync through save games could attempt to get the game back together. Though looking at the save game file sizes, I guess I can see resync speed issues when there's dialup users involved, but it could also provide help in figuring out what's wrong if you can dump a save game right before it desyncs.

desyncing would have to be detected somehow in the first place.

It already does this to some degree, doesn't it? How else can ZDoom report consistency failures?

[Kuroshi]

It already does this to some degree, doesn't it? How else can ZDoom report consistency failures?

I would agree with that since it does report the errors. In fact, savegames were my solution to coop desync before version xx fixed most of the problems (forgot which version it was). I (as the server) would save the game immediately after a desync, everyone would quit, then the other players would copy the savegame off of my computer. Upon loading, the game would still say consistency failure, but the number was the same on all machines and they were in reality in sync again. Not sure how well this would work in real time, but it's definately faster than having to quit and reload.

That being said, to the original author of this post, make sure all game settings and loaded files are the same. Not sure if ZDoom sets the compatability flags of all the machines to match the server or not so especially check those (I.E. Pain Elemental Lost Soul limit.)

[Jim]

If it keeps having to resync every frame then the game won't play anyway, whether it tries to resync or not.

I thought that was the point I was making. I guess I wasn't clear enough (never actually explicitly connected the dots for you). I was siting this as a reason that ZDoom couldn't blindly repeat the saving and restoring over and over again.

[Chris]

Oh. Well, it could add a check if there's 'x' amount of resyncs within 35 game tics, which could be provided through a per-player cvar (and if that amount is reached, the player just quits).

[Chris]

Also I just remember that zdoom savegames are really just saved as PNGs with extra info fields. If this save game was sent for resyncing purposes only, it wouldn't need the image data which is where the bulk of the size probably comes from.

[plausiblesarge]

These kinds of errors are what made me and my friends ditch zdoom altogether for multiplayer and move to skulltag.

[wildweasel]

Terribly sorry, plausiblesarge, but this entire subforum has not been used for years, and the thread you've posted in dates back to 2003. Please pay closer attention to how old the thread is!