Copied from a ZDoom bug report.
I can confirm this bug in Eternity R984. The map works in Boom 2.02, but it is broken in MBF 2.03. Interestingly, it works in PrBoom+ 18.104.22.168.
Apparently, double-raising stairs (like in eternall map25) behave differently between vanilla and boom. For example, if you use the "stairs raise by 8" action in vanilla, most steps will raise by 8 going in one direction, but most steps will raise by 16 when going the other direction. In boom, all stairs will raise by 8 when going in either direction. In ZDoom, double-raising stairs always seem to behave like they do in vanilla, even if the map is in boom format and regardless of what "stair building" compatibility option ZDoom uses. So, if you make a map for boom with those kind of stairs, the map won't behave properly in ZDoom.
Here's an example: stairsthing.zip
It also works in regular PrBoom 2.5.0.
I did some additional research. Could this be related to this:
Compatibility bug in EV_BuildStairs:
Affects: Boom, MBF
Description: There are three different ways this function has, during its history, stepped through all the stairs to be triggered by a single switch:
Fixing MBF's comp_stairs requires an elaborate fix, and remaining compatible with the buggy behavior of old MBF demos is tricky too. See PrBoom's p_floor.c:EV_BuildStairs for my fix.
- original Doom used a linear P_FindSectorFromLineTag, but failed to preserve the index of the previous sector found, so instead it would restart its linear search from the last sector of the previous staircase
- MBF/PrBoom with comp_stairs fail to emulate this, because their P_FindSectorFromLineTag is a chained hash table implementation. Instead they start following the hash chain from the last sector of the previous staircase, which will (probably) have the wrong tag, so they miss any further stairs
- Boom fixed the bug, and MBF/PrBoom without comp_stairs work right
Last edited by Xtroose on Feb 12 2010 at 18:45