Bug Tracker – Bug 287

Incorrect E1M4 door+lift behavior

Last modified: 2010-08-22 21:50:47 UTC
Bug 287 - Incorrect E1M4 door+lift behavior
Summary: Incorrect E1M4 door+lift behavior
Alias: None
Product: Odamex
Classification: Unclassified
Component: Client (show other bugs)
Version: (old) 0.x Alpha
Hardware: All All
: P2 minor
Assignee: Denis Lukianov
Depends on:
Blocks: 424 567
  Show dependency tree
Reported: 2007-01-20 13:10 UTC by Ryan Barreras
Modified: 2010-08-22 21:50 UTC (History)
3 users (show)

See Also:


proposed patch (1.16 KB, patch)
2009-12-31 03:01 UTC, Brandon Del Bel
Details | Diff
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan Barreras 2007-01-20 13:10:29 UTC
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.
Comment 1 Denis Lukianov 2007-04-30 07:25:21 UTC
Can anyone confirm please?
Comment 2 Denis Lukianov 2008-05-12 12:17:45 UTC
confirming, this does happen
Comment 3 Brandon Del Bel 2009-12-30 22:09:14 UTC
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.
Comment 4 Brandon Del Bel 2009-12-31 03:01:05 UTC
Created attachment 157 [details]
proposed patch

I made a patch that emulates the behavior I observed in vanilla and chocolate doom. I ran the regression tests, and everything looks fine.
Comment 5 Denis Lukianov 2010-01-03 09:30:22 UTC
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?
Comment 6 Brandon Del Bel 2010-01-03 09:44:06 UTC
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.
Comment 7 Simon Howard 2010-01-04 07:33:31 UTC
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:

Comment 8 Mike Lightner 2010-08-07 18:30:29 UTC
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.
Comment 9 Mike Lightner 2010-08-22 21:50:47 UTC
This is fixed, especially after r1741.