Heretic line specials

So, with the recent EV system overhaul, I've looked at the Heretic bindings in Eternity.

7 and 8, the stair builders, are faster than in Doom. Doom uses FLOORSPEED/4, with FLOORSPEED defined as FRACUNIT. Heretic uses FLOORSPEED undivided. (Compare EV_BuildStairs in both Doom's and Heretic's versions of p_floor.c.)

10 and 88 cannot be activated by monsters. Look at the exception lists at the top of P_CrossSpecialLine(). 10 and 88 are included in Doom's version, but in Heretic's they are both commented out.

36 has a difference in behavior between Doom and Heretic. More details in this report.

49 has different behaviors in all three engines (Doom, Heretic, and Strife). See this report for complete explanations.

Thanks; I'll have to create new actions for those. At some point I have to do a complete re-sweep of the Heretic source to look for stuff like this I have missed.

For example I recently found a change which is responsible for terrain splashes not angering monsters in Heretic, which never made it into EE. Hence why monsters in EE are really pissy about getting splashed ;)

Based on your analysis of the line types in Strife I also revisited the disassembly and verified the following:

(In P_UseSpecialLine:)
case49:
   mov     edx, 3         ; verifies it is still crushAndRaise...
   mov     eax, ecx
   call    EV_DoCeiling
   test    eax, eax
   jz      rettrue

(In EV_DoCeiling: - NB: case 5 also points to case 3, as in DOOM)
ceilingcase3: ; CODE XREF: EV_DoCeiling+98j
              ; DATA XREF: cseg01:0001CF5Co ...
   mov     eax, [esi+sector_t.ceilingheight]   ; crush is not set!!!
   mov     [ebx+ceiling_t.topheight], eax

ceilingcase0: ; CODE XREF: EV_DoCeiling+98j
              ; DATA XREF: cseg01:off_1CF50o
   mov     eax, [esi+sector_t.floorheight]
   mov     [ebx+ceiling_t.bottomheight], eax
   test    ebp, ebp
   jz      short loc_1D06F
   add     word ptr [ebx+16h], 8

loc_1D06F:   ; CODE XREF: EV_DoCeiling+100j
   mov     [ebx+ceiling_t.direction], 0FFFFFFFFh
   mov     [ebx+ceiling_t.speed], 65536
   jmp     short loc_1D097

So we can see that neither silentCrushAndRaise nor crushAndRaise do any crushing damage in Strife. I have adjusted Chocolate Strife to do this correctly.

Also I do not know if you're aware or if ZDoom implements it correctly, but lowerAndCrush, which does not crush in DOOM, DOES crush in Strife. Seems they literally moved the crush = true from case 3/5 up to case 2:

ceilingcase2: ; CODE XREF: EV_DoCeiling+98j
              ; DATA XREF: cseg01:0001CF58o
   mov     [edx+ceiling_t.crush], 1
   mov     eax, [esi+sector_t.floorheight]
   mov     [edx+ceiling_t.direction], 0FFFFFFFFh
   mov     [edx+ceiling_t.speed], 65536
   mov     [edx+ceiling_t.bottomheight], eax
   jmp     short loc_1D097

That's interesting, thanks.

I do not and cannot claim any credit for the difference in speed in stair building; it's something I noticed by comparing which line types had an entry in zdoom.pk3:xlat/heretic.txt but weren't listed in Heretic's section of ev_bindings.cpp. (Same for the no monster activation of line types 10 and 88.) They were already there in ZDoom r1 from 2006.


I can only claim the find for line types 36 and 49, and apparently I did a half-assed job there since I missed that line type 36's case also applied to line types 70, 71, and 98. ;)

I'll take a look at the Strife crushers in ZDoom to see if they're correct.

Edit: lowerAndCrush dealing damage was already in; but line types 25, 73, and 141 are treated identically to how they are in Doom.

This might be interesting, too:

http://forum.zdoom.org/viewtopic.php?f=7&t=35462

Before you guys make any changes to Strife line types based on that info, I want to note that T_MovePlane is radically altered as well, to the point I'm not sure if crush damage is *ever* inflicted by surfaces. Kaiser handled the conversion of this function in Choco Strife so I'm a little behind on understanding the changes they made, but they're not trivial.

I'll work on it and make a final report on what I figure out.

EDIT: Yeah, ok. The meaning of crush parameter to T_MovePlane is the same as it ever was. The only changes that were made were to remove some P_ChangeSector calls, for reasons I don't totally understand. Maybe related to problems caused by 3D object clipping?

As a result I fixed another bug in Chocolate Strife, though :)