Bug 1245

Summary:	Regression: vanilla demo lmps desync in 0.8.0, depending on client config
Product:	Odamex	Reporter:	Ant P. <ant+odamex.bugs>
Component:	Client	Assignee:	Odamex Bug Reporter <odamex-bug-reporter>
Status:	NEW ---
Severity:	minor	CC:	Ch0wW, odamex-bug-reporter
Priority:	P5
Version:	0.7.x (Old)
Hardware:	x86 (Windows, Linux, etc)
OS:	Linux
Attachments:	Door-desync demo bug

Description Ant P. 2019-01-24 19:53:42 UTC

I've noticed a bunch of stuff that seems like it ought to work no longer does in 0.8 - every demo in old iwads looks normal, but outside that it's hit-or-miss. However, I've noticed the desync vanishes *sometimes* if I run odamex with a completely default config file - i.e. `odamex -config /dev/null -iwad doom2 -pwad $etc`.

Works 100%:
- doom.wad (md5sum c4fe9fd920207691a9f493668e0a2083)
- doom2.wad (25e1459ca71d321525f84628f45ca8cd)
- plutonia.wad (75c8cf89566741fa9d22447604053bd7)
- tnt.wad (4e158d9953c79ccf97bd0663244cc6b6)

Broken:
- freedoom1.wad v0.11.2 (6d00c49520be26f08a6bd001814a32ab)
  * demo 1 (E1M6) is a 4-player co-op that goes out to lunch almost instantly. Empty config *doesn't* help.
  * demo 3 (E4M3) is singleplayer, but spends its time staggering around the starting room inspecting walls
- freedoom2.wad v0.11.2 (90832a872b5bb0aca4ca0b20419aad5d)
  * demo 2 (map20) dies trying to escape the starting room. Might just be because mike's playing it though.
  * demo 3 (map22) is similarly confused, but this one's co-op
- freedm.wad v0.11.2 (9352b09ae878dc52c6c18aa38acda6eb) -- all demos are DM, and completely desynced

Tests on the demo1 of a few pwads:
- av.wad only works with empty config
- brit11.wad works with empty config
- btsx_e1.wad is OK
- mm.wad's 2-player co-op starts out fine, but desyncs once the players interact toward the end, and null config doesn't help
- mm2.wad is OK
- scythe.wad is OK

All of my old .odd demo files from 2012-2014 are broken too, but I guess those were never expected to work indefinitely…

Comment 1 Maëllig Desmottes 2019-01-25 18:36:05 UTC

.odd files are normal. Since there's some protocol changes, you'll need Odamex 0.7.0 to make these run.

About vanilla .lmp ones, good catch. Demo compatibility is sadly still not 100% perfect and are prone to desync since we have to replicate to the perfection the vanilla demos.

However, you said those demos were perfectly working since 0.7.0 ?

Comment 2 Ant P. 2019-01-25 21:14:14 UTC

Oh. I just installed 0.7.0 to check and it seems to break in exactly the same places.
I've definitely seen these working correctly in it though... maybe I had less wonky config settings at some point.

Would it even be worth spending effort to fix this then? I know it'd be nice to have from a preservation angle, but if I'd known it was previously broken I probably wouldn't have bothered reporting the bug…

Comment 3 Maëllig Desmottes 2019-01-26 06:58:48 UTC

Could you check them in 0.6.X if you have some time, to see from what version the desyncs happened ?

Also, I take care of .lmp playback very carefully, because it shows how close to vanilla we can be. And ZDoom making some physic changes to Doom, we need to find them, and fix them back.

Comment 4 Ant P. 2019-01-26 15:15:05 UTC

(In reply to Maëllig Desmottes from comment #3)
The oldest revision that successfully builds on my current system is dead164dc6fdc (0.6.4) - and it breaks in the same way.

So I tried bisecting the config file instead. That gave me answers, but they're bizarre:

- removing "set cl_weaponpref1 1" makes brit11.wad sync
- removing "set cl_showspawns 1" makes av.wad sync.

I've noticed that in the desync case, the player spawns are actually different positions. Something consuming RNG values when it shouldn't be?

Comment 5 Maëllig Desmottes 2019-02-23 15:03:05 UTC

I made a pull request force-disabling "visible spawnpoints" , since it actually adds spawns (and thus, new entities) to the demo, making it desync.

I didn't see the desyncs for the AV demos though, so I'll need confirmation from your end.

Comment 6 Ant P. 2019-06-09 19:48:33 UTC

(In reply to Maëllig Desmottes from comment #5)

First of all, sorry for the really late response. I've retested all of these with version 0.8.0-64-gf916c4ab (current github development branch). Results:

freedoom1:
  - demo1 (4-player co-op) improved slightly, but still visibly derails (to varying degrees per player - green makes it the furthest) as soon as it gets through the first corridor
  - demo3 is, to my surprise, now playing a deathmatch demo instead of singleplayer. And it runs fine now!
freedoom2:
  - demo2 (singleplayer) starts normal but goes obviously wrong upon opening the door with a sergeant on the other side
  - demo3 is working in the same way as freedoom1's demo3. Suddenly DM mode, and plays fine to completion
mm.wad:
  - demo1 (2-player co-op) no improvement, still desyncs near the end

Tested and found to work perfectly:
  - av.wad (DM, singleplayer, 2-player co-op)
  - brit10.wad (DM)
  - brit11.wad (DM)
  - deca.wad (DM)
  - dwango12.wad (DM)
  - icarus.wad (singleplayer)
  - u_dtag.wad (dwangotag :D)

Notably, the ones that still break all have monsters (and AI/object interaction?) in common. Most are co-op also, the exception is freedoom2 demo2. But, given that they don't build their singleplayer iwads for vanilla any more, I wonder if whatever they recorded in is also buggy.

Comment 7 Maëllig Desmottes 2019-06-19 11:12:17 UTC

Created attachment 575 [details]
Door-desync demo bug

One major cause of desyncs that has been recently spotted since Odamex 0.6.0 and onwards is about the doors : There's a frame that seem to freeze the ability to open doors, making it immediately desync. For instance, the latest World Record UVSPeed of Doom 2 desyncs on MAP26 because of that bug. Maybe some of the desyncs spotted are related to that ?

So, for developers being curious about this error, I uploaded a demo with the bug on map27. Compare it with Chocolate-Doom to see it better. If I go through the door and turn around, it works.

Additionnal infos : this bug isn't triggered on 0.5.6, and has been started when there was a change related to the doors.