(Solved) demo desync of a Requiem E3 playthrough

[printz]

The demo by Revved from episode 3 of Requiem plays okay in Doom2+ and PrBoom+, but fails on Eternity and MBF (as tested by me so far). Here's how it fails on Eternity:

- all versions since Simorgh (3.35.90): on second level (MAP22) right before the player wants to berserk punch those arachnotrons.
- versions until and including Phoenix (3.33.50): on third level (MAP23) a bit after the SS Nazi encounter. The player falls into a pit with skulls on wooden walls (or whatever) and starts shooting the walls of the pit.

MBF desyncs even worse, on the first level (MAP21).

Wads set to run: requiem.wad, reqmus.wad, req21_competn.wad

What does PrBoom+ do that ensures this demo will run? Is there a well-known problem in Requiem MAP22 that's well emulated in PrBoom+?

It's very hard to find the breaking Git revision in Eternity, because I'm dealing with 7-10 year old code.

[dew]

Could it be some MBFism that's set on by default? Requiem is a vanilla mapset, so consistent desyncs in MBF-based ports sound suspicious.

[printz]

I hope that's true. I'll test Boom tonight and if it works, I'll hopefully be able to run a code diff between Boom and MBF, unless MBF's code has been scrambled around a lot.

[printz]

Alright, I fixed it. It was caused by a REJECT overflow (by one byte) in Requiem's MAP22. I applied the fix from Chocolate-Doom (which is also in PrBoom+; dunno who added it first) if the demo is from MBF or earlier.

This also got Eternity a new command-line parameter:

-reject_pad_with_ff
If set, it will pad a REJECT lump (beyond whatever controlled garbage was added) with ones instead of zeros. In English, this means that you should use this parameter if the demo you're trying to play still fails, and hope it will work.