Bug #921: Blockmap-defined Linedef crossing order - Doomsday Engine - Tracker

Bug #921

Blockmap-defined Linedef crossing order

Added by stavstav2 over 14 years ago. Updated almost 5 years ago.

Status:

Progressed

Priority:

High

Assignee:

Category:

Vanilla emulation

Target version:

Vanilla / Gameplay

Start date:

2010-06-22

% Done:

30%

Tags:

PlaySim, Gameplay

Description

in house of pain which is episode 3 mission 3 in ultimate doom... at the start there are 3 ways to go, if you go straight, you come to a room with 2 crushers in it and 3 switches against the back wall... the first time i attempted to use the switches only the one on the right would work. reloaded and then the middle one and the right one would work but not the left one... reloaded a few more times and it seemed to stay that way... but... just tried playing mission 3 again, from the start, and this time i pushed the left switch first, and it worked, and all switches worked this time...

another thing, the switch on the right controls a door, which you need to open to progress in the level. however this door auto closes unless there are enemies under it. i would have to play the original doom to confirm this but it seems that a door that closes permanently on the player would not be in the game. i could be wrong tho... also the door closes on 2 hallways on the right and on the left of the door and you cannot get out either....

i am using beta 6.9 in ultimate doom on xp.... thank you

Labels: Gameplay

History

#1 Updated by vermil over 14 years ago

A little correction. House of Pain is E3M4, not E3M3.

The former is the intended behaviour. Put simply if the crushers are activated (by you moving very close to them), the switches can't be pulled.

The later is a pair of bugs in Beta6.9 it seems...

Monsters that cross line 1069 are for some reason activating the door trigger on this line even though they shouldn't; monsters don't activate door triggers if they can already fit through, as they can in this case.

They are also seemingly activating it from the back side, when they should only be able to activate it from the front.

#2 Updated by vermil over 14 years ago

To correct myself a little;

The fact that the bad guys seem to activate the back side of the trigger is perhaps related to this bug in the original engine.

http://doom.wikia.com/wiki/Monsters_open_locked_doors

Given Dday's intent on retaining quirks like this, I imagine this behaviour will probably stay (though it's still a mistake in Dday Beta6.9 that the bad guys activate this trigger when they can already fit through.

#3 Updated by danij over 14 years ago

According to the current logic the fact this ceiling will sometimes close due to a monster crossing linedef 1069 is absolutely the correct outcome, algorithmically speaking.

When dealing with linedef crossing there is no test to ensure the mobj's movement direction is from linedef front to back. All the algorithm cares about is if the line was crossed at all.

This algorithm is highly dependent on the order in which linedefs are added to the blockmap. It is quite possible for a move to occur that results in a "spechit" being registered but the move itself fails due to finding a single-sided linedef. In this situation, any spechits registered are not pulled from the stack and are processed anyway, even though the move failed.

It would appear that the only reason this doesn't happen in vanilla DOOM is because the blockmap has the linedefs for this cell ordered such that the single-sidedef linedefs appear before that with the trigger special.

At this point I'm of the opinion that the only way we are going to resolve this (and all similar issues) is to re-implement support for the original in-wad BLOCKMAP lumps and search algorithm(s). Obviously we do not want all supported games to suffer the consequences, so this should be implemented on game-side (in libcommon).

#4 Updated by skyjake almost 14 years ago

Was this addressed by the blockmap changes in 1.9.7?

#5 Updated by danij over 12 years ago

It was partly addressed (I replaced the BOOM algorithm with the original idbsp logic).

However the larger issue here is that the playsim is entirely dependent upon the order of the linedefs in the blockmap when it comes to making decisions such as "raise floor to next highest neighbour". The real solution to this is to implement support for the original BLOCKMAPs (in libcommon) and treated as a compatibility mode,