Double raising stairs in Boom

Copied from a ZDoom bug report.

TimeOfDeath said:

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

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+ 2.5.0.6.

EDIT:
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:

• 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
  

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.

Xtroose said:

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+ 2.5.0.6.

EDIT:
It also works in regular PrBoom 2.5.0.

I did some additional research. Could this be related to this:

Ugh. I don't know why they ever had to screw around with this stuff.

I'm still not certain if this should even be changed. How many Boom compatible maps are there which rely on this behavior?

Isn't vanilla compatibility more important in this case?

And of course:

I don't know why they ever had to screw around with this stuff.

To my knowledge, the only Boom compatible map relying on this behavior is TimeOfDeath's example map, which is MAP05 from his released project Time Of Maps - Part 1. There could be others, but I have not played that many wads.

The funny thing is, Eternity has the fix in the stairbuilding code. Now why doesn't it work then?


Here's the relevant code:

                 /* jff 6/19/98 prevent double stepsize
                  * killough 10/98: intentionally left this way [MBF comment]
                  * cph 2001/02/06: stair bug fix should be controlled by comp_stairs,
                  *  except if we're emulating MBF which perversly reverted the fix
                  */
               if(comp[comp_stairs] || demo_version == 203)
                  height += stairsize; // jff 6/28/98 change demo compatibility

               // if sector's floor already moving, look for another
               if(P_SectorActive(floor_special,tsec)) //jff 2/22/98
                  continue;

               /* cph - see comment above - do this iff we didn't do so above */
               if(!comp[comp_stairs] && demo_version != 203)
                  height += stairsize;

And the comment also explains why this does not work in MBF.


EDIT: Just checking with the compatibility option switched off and the stairs are built Boom's way. Seems for the original test the option was on.

Well now see I knew about having applied that fix. I thought this issue was a *new* problem with stairs so I didn't make the connection ._.

Quasar said:

Ugh. I don't know why they ever had to screw around with this stuff.

They saw a bug and fixed it. I don't think in 1998 there was the same level of consciousness of compatibility issues as there is today, plus everybody is a lot wiser now so judging something done over a decade ago is a bit rich.

Boom's code:

       if (compatibility) // jff 6/19/98 prevent double stepsize
          height += stairsize; // jff 6/28/98 change demo compatibility

        // if sector's floor already moving, look for another
        if (P_SectorActive(floor_special,tsec)) //jff 2/22/98
          continue;
                                  
        if (!compatibility) // jff 6/19/98 increase height AFTER continue
          height += stairsize; // jff 6/28/98 change demo compatibility

They were definitely aware of the compatibility issues involved here.