Incorrect E1M4 door+lift behavior
In E1M4, a lift (starting room, through the middle passage) and the yellow key door share the same tag. Because of this, in doom.exe, the door cannot be opened if the lift is lowered, and vice versa. In Odamex, both function properly regardless of the other's state.
Can anyone confirm please?
confirming, this does happen
The description is a bit incorrect. In vanilla (and chocolate) doom, the door won't open while the plat is down until right before it comes back up, but the plat will lower while the door is open.
Created attachment 157 [details]
I made a patch that emulates the behavior I observed in vanilla and chocolate doom. I ran the regression tests, and everything looks fine.
ideally, we need to add a multiplayer vanilla demo of this to the regression tests, so we know if it breaks again
also, should this apply to moving ceilings, etc?
I agree that this needs to be tested more. I would like to make a test map at some point to explore all of the possibilities.
This looks a lot like the ep1-0500.lmp bug that caused desyncs on this level in Chocolate Doom on 64 bit. This was the fix:
r1714 applies a fix for this based on chocolate doom r1710 and a bit of Nes's appropriate variables. Not sure if we need to check the state/count or not, why can't we just return false? We can't set the wait to -1 since it's protected for plats.
This is fixed, especially after r1741.