Hexen: possible desync on multi-level demo (and now single map demo) about chocolate-doom HOT 12 CLOSED

Other demos that desync, non-comprehensive list

https://dsdarchive.com/files/demos/hexen/699/hx4j1617.zip (CHexen)
https://dsdarchive.com/files/demos/hexen/55902/hxf1302.zip (Hexen+ v1.1.5)
https://dsdarchive.com/files/demos/hexen/55856/hxm2140.zip (Hexen+ v1.1.5)
https://dsdarchive.com/files/demos/hexen/55844/hxc2306.zip (Hexen+ v1.1.5)

The last one happens at about 3:20 and so is another good candidate for watching without -timedemo

from chocolate-doom.

Do all of these involve the porkalator? Is this the first use of the porkalator in the demos?
Where did dsda-doom get their Hexen code? Straight from id release or somewhere else?
Did this ever work on chocolate or has it broken recently (can't be that recent if 3.0.1 is broken...)?
Is there some easy hack that can be applied to the source to pause the game shortly before or after the desync so we can attach debugger/add debug code?

from chocolate-doom.

Dsda is based on PrBoom+ and may thus have a more complete emulation of Doom 1.2, upon which Hexen is built.

from chocolate-doom.

Do all of these involve the porkalator?

No, only the first one does. I'll go through the other demos soon to see if I can identify any commonalities.

2.3.0 was the first stable release to have support for extended demos, I can give that a shot.
*edit: They still desync in 2.3.0, so I guess they never worked properly in Chocolate Hexen.

(It shouldn't matter but I used the windows version of 2.3.0 through wine because I was having trouble getting it to compile on Linux.)

While it's possible that multi-level demos have something to do with the desync, it seems also possible to me that they're the only desyncs I've seen because single-level demos just aren't long enough to run into whatever rare condition is causing the desync.

from chocolate-doom.

Going through the demos on dsdarchive, most of the ones that desync do so in multi-level runs. However MAP11 always desyncs in Chocolate, essentially from the beginning, even on single map runs. Clearing the savegame directory doesn't seem to matter.

These three single-map demos desync in Chocolate (latest git, 3.0.1, and 2.3.0) but play fine in vanilla and dsda-doom:
https://dsdarchive.com/files/demos/hexen/748/m11f-031.zip
https://dsdarchive.com/files/demos/hexen/749/m11m-033.zip
https://dsdarchive.com/files/demos/hexen/747/m11c-052.zip

Meanwhile this demo I recorded in Chocolate desyncs in vanilla:
hx11test.zip

MAP11 is the secret map of Hub 2, and is somewhat special in that it has a switch that grants access to the secret map of Hub 4 (MAP25). Though to be able to reach MAP11 normally you have to exit from the secret map of the first hub (MAP06), and that map doesn't usually cause desyncs. MAP11 also has a script which teleports ettins in after a while, can only be beaten by killing all living ettins, and will swarm you with chaos serpents if more than 20 ettins are present -- no idea if that's relevant but since it's fairly uncommon I figure I'd mention it.

edit: making a copy of MAP11 with an empty* BEHAVIOR lump and recording on that level still causes desyncs between Chocolate and Vanilla Hexen. (*Hexen needs a valid BEHAVIOUR lump with at least one compiled script, even if it does nothing.)

from chocolate-doom.

I haven't checked all the attached demos, but this fixes the Zero Master fullgame run desync on my end:

diff --git a/src/hexen/p_enemy.c b/src/hexen/p_enemy.c
index c92604d6..54797b49 100644
--- a/src/hexen/p_enemy.c
+++ b/src/hexen/p_enemy.c
@@ -539,11 +539,11 @@ boolean P_LookForPlayers(mobj_t * actor, boolean allaround)
     // an infinite loop can occur if players 0-3 all quit the game. Although
     // technically this is not what Vanilla does, fixing this is highly
     // desirable, and having the game simply lock up is not acceptable.
-    // stop = (actor->lastlook - 1) & 3;
-    // for (;; actor->lastlook = (actor->lastlook + 1) & 3)
+    stop = (actor->lastlook - 1) & 3;
+    for (;; actor->lastlook = (actor->lastlook + 1) & 3)
 
-    stop = (actor->lastlook + maxplayers - 1) % maxplayers;
-    for (;; actor->lastlook = (actor->lastlook + 1) % maxplayers)
+    // stop = (actor->lastlook + maxplayers - 1) % maxplayers;
+    // for (;; actor->lastlook = (actor->lastlook + 1) % maxplayers)
     {
         if (!playeringame[actor->lastlook])
             continue;

from chocolate-doom.

I think this is the same issue: #822

from chocolate-doom.

I haven't checked all the attached demos, but this fixes the Zero Master fullgame run desync on my end

That looks very promising, the MAP11 demos all work now. I'll check the others when I get a chance.

caldera.wad demo in #822 plays properly as well

from chocolate-doom.

OK that fixes every hexen.wad demo on dsdarchive that desyncs. There is one that causes a segfault but seems likely that that's a different issue. Great spotting @mikeday0

from chocolate-doom.

Go ahead and roll back please. Though I'm confused as to why that commit causes the desync.

from chocolate-doom.

Here's what I think is happening, Upon spawning, each enemy's lastlook is initialized to a random value between 0 and 7 (i.e MAXPLAYERS - 1). There's a chance that the first call of P_LookForPlayers for that monster will return early courtesy of the actor->lastlook == stop condition. Presumably this occurs when (actor->lastlook - 1) & 3 equals 0, or when lastlook equals 1 or 5.

The original fix for the infinite loop has the side effect of altering which enemies are affected by an early actor->lastlook == stop return. Now it happens when (actor->lastlook + MAXPLAYERS - 1) % MAXPLAYERS equals 0, or when lastlook equals 1.

from chocolate-doom.

You could add that analysis as a comment to the fix PR.

from chocolate-doom.