DEHACKED frame 772 misbehavior in ZDoom

DEHACKED frame 772 is NULL. However, in ZDoom based ports, it seems to call Fall aka NoBlocking codepointer. It happens even if you alter other properties of the frame. This is unpleasant when you are making DEHACKED replacements and reuse frames from wherever possible to change behaviour of monsters or weapons etc.

Here is an example wad: http://www.filedropper.com/bug772

The Zombieman's reviving animation has been altered to go through frames 769-772. The Archvile has been altered not to attack, purely for convenience so that he doesn't distract you. Kill the zombieman and let the archvile revive him. If you use a non-ZDoom based port, everything will be normal. But if you use a ZDoom-based port, the Zombieman will drop a clip, which is what happens in ZDoom when Fall aka NoBlocking codepointer is called. More importantly, he will also become nonsolid, so that you can walk through him (and the Archvile too). You can still shoot him, though. When killed and revived again, he will become non-solid again. Now let's repeat it one more time, and try to run into his body while he's being revived. You can see how he's actually solid - until he reaches the last frame of the animation, which is 772. By trial and error, I have confirmed that it's really a fault of this frame alone.

By the way, I have used this weird demonstration with reviving frames just because I've accidentally run into this problem while defining reviving frames for a custom DEHACKED monster.

Here is the text of the DEHACKED patch:

I think this can be considered a bug. Can anybody explain it? Or even justify it?

Why don't you file a bug report in the ZDoom forum?

What happens if you change the code pointer to something innocuous? As a workaround/test?

EDIT: Holy shit, I just learned that you can't add code pointers to frames that don't already have them. I changed it to BEX and changed frame 772 to the code pointer Lower.

I understand that the bug still stands and that you may want this to work with Chocolate Doom, which doesn't support boom extensions, right?

What is frame 772 originally? I currently have nothing at hand to look this up.

One of the Keen death states.

Originally it looks like this: (I highlighted frame 772 in an image editor, it's not yellow in Whacked)



Although there is a KeenDie codepointer on frame 774 nearby, I have confirmed that the "invisible" codepointer on 772 is not KeenDie, because the Keen special didn't trigger when I tested it on another map with a Keen door.

Well adding
[CODEPTR]
FRAME 772 = Lower

fixes it in ZDoom. Then I extracted the DECORATE lump to a deh file and tested it in Choco Doom and it works there, too. Maybe it's a Whacked bug? Maybe it should have the Fall code pointer so you can change it.

It is not a Whacked bug, because frame 772 is supposed to be NULL (see here, search for 772 in square brackets), and it behaves as NULL in non-ZDoom ports. Also yes, I want to edit vanilla compatible DEHACKED, not bex.

EDIT:

VGA said:

Well adding
[CODEPTR]
FRAME 772 = Lower

fixes it in ZDoom. Then I extracted the DECORATE lump to a deh file and tested it in Choco Doom and it works there, too.

Show me the exact DEHACKED patch that worked in Chocolate Doom, as a text.

scifista42 said:

It is not a Whacked bug, because frame 772 is supposed to be NULL (see here, search for 772 in square brackets), and it behaves as NULL in non-ZDoom ports. Also yes, I want to edit vanilla compatible DEHACKED, not bex.

EDIT:
Show me the exact DEHACKED patch that worked in Chocolate Doom, as a text.

This saved as DEHACKED.deh
http://pastebin.com/QynKMT4g

with your wad with the DECORATE lump deleted. It results in no ammo clip thrown when the trooper is raised.

You are not corrent, the custom codepointer didn't work in Chocolate Doom. I took your example but I replaced "Lower" with "Explode", to make the effect noticeable. In ZDoom, the Zombieman indeed exploded, but in Chocolate Doom (launched via "chocolate-doom -file bug772ch.wad -deh bug772ch.deh") the explosion didn't happen at all. Obviously - vanilla doesn't allow you to add codepointers to frames with NULL codepointers, and so does not Chocolate Doom.

Frame 772 seems to behave like having NULL codepointer in Chocolate Doom, which is correct and which I already knew.

However, at least you showed me that the DEHACKED otherwise worked (Archvile didn't attack) even though an "illegal" command was there.

By the way, Fall codepointer doesn't actually cause enemies to drop ammo in other ports than ZDoom - ZDoom modified this codepointer's behaviour deliberately, I believe. The original (non-ZDoom) ammo-dropping behaviour is triggered immediately upon death of the enemy if he's one of the types that drop ammo, not when Fall is called.

Ah, you are correct, you have demonstrated that there is something that seems hardcoded or buggy in ZDoom. The only thing I achieved is a workaround that works in both ZDoom and Choco. I mean it doesn't break anything in Choco.

I guess Graf will get to the bottom of this.

scifista42 said:

By the way, Fall codepointer doesn't actually cause enemies to drop ammo in other ports than ZDoom - ZDoom modified this codepointer's behaviour deliberately, I believe. The original (non-ZDoom) ammo-dropping behaviour is triggered immediately upon death of the enemy if he's one of the types that drop ammo, not when Fall is called.

That was done for Heretic and Hexen support. It certainly wasn't required to be done that way though - EE allows either timing for item drops, for compatibility purposes, through the EDF item drop definitions.

VGA said:

The only thing I achieved is a workaround that works in both ZDoom and Choco. I mean it doesn't break anything in Choco.

OK. I'm only not sure if it's an ideal errorproof solution. I have applied your patch to vanilla executable using "DEHACKED.exe -load bug772ch.deh". This was the log generated on DEHACKED's output:

THING name file cannot be opened!

Welcome to DeHackEd v3.1 

Written by Greg Lewis, email at gregl@umich.edu.
Vital Doom exe specs written by Matt Fell.
Special thanks to iD for creating such a wonderful game!

Checking for c:\Doom\exe\Doom.exe...   found!Checking for c:\Doom\exe\Doom2.wad...   found!Checking for c:\Doom\exe\doomhack.exe...   found!
Loading patch file:  bug772ch.deh
Line 9: Unknown line.
Line 10: Unknown line.
Line 43: Invalid single word line.
Line 44: Unknown line.
Patch file read, one or more errors detected.

However, the new executable was created, and the Archvile didn't attack me, not even when I warped to other stock D2 maps with an Archvile. So, it worked. But I don't know how much can "errors" like this influence DEHACKED's / Chocolate Doom's ability to apply the patch properly if the patch contained numerous elaborate changes.

Or can this be considered OK?

Oh you are actually targetting DOS, too? :-D

Why don't you just develop your deh normally and then have a second file called zdoom-fix.bex. In that you change the 772 code pointer to NULL.

[CODEPTR]
FRAME 772 = NULL

That should work.

I have already worked around the bug in my wad by not using frame 772. :)

The point of this thread was, and still is, to make the bug a known issue + to find out if somebody could explain it.


EDIT: I have found out the source of the bug - ZDoom's DECORATE definition of Commander Keen's death looks like this:

  Death:
    KEEN AB 6
    KEEN C 6 A_Scream
    KEEN DEFGH	6
    KEEN I 6 A_NoBlocking
    KEEN J 6
    KEEN K 6 A_KeenDie
    KEEN L -1
    Stop

There is a NoBlocking (=Fall) action for whatever (?) reason, right on the frame that corresponds to frame 772 in DEHACKED.

Sigh...

When this got converted to DECORATE in 2006 I must have accidentally used a bad source which had this unnecessary call in there. No idea why...

Strange that for 9 years nobody noticed.

It also sounds like it could potentially be the same case as that error with the spider mastermind, where it was perfectly fine until all actors definitions went from internal to DECORATE in zdoom.pk3 long ago and there was a mistake in the conversion, yet nobody noticed until now.

You are correct, both errors originate from the same commit in November 2006. And these were not the only problems with this particular commit. Over the years there were a few others, too.

I can remember that I took the DECORATE code from some test project I made, but it looks like that contained a few changes I completely forgot about...

And also the Mancubus's attack states. ZDoom's DECORATE looks like this:

  Missile:
    FATT G 20 A_FatRaise
    FATT H 10 Bright A_FatAttack1
    FATT IG 5
    FATT H 10 Bright A_FatAttack2
    FATT IG 5
    FATT H 10 Bright A_FatAttack3
    FATT IG 5
    Goto See

But in DEHACKED, there are additional FaceTarget codepointers on all the frames after FatAttack*:




I have noticed DEHACKED misbehaviour too - the FaceTarget function won't be called in ZDoom, even if I reuse these frames for a custom DEHACKED thing that is supposed to call FaceTarget.

Ugh...

And guess what: Again from the same date November 4th, 2006.
I think all the Doom monsters in ZDoom require some verification as on that day I converted nearly all of them.

More minor DECORATE differences.

Revenant's melee:

  Melee:
    SKEL G 1 A_FaceTarget
    SKEL G 6 A_SkelWhoosh
    SKEL H 6 A_FaceTarget
    SKEL I 6 A_SkelFist
    Goto See

In DEHACKED, the first frame has duration 0, not 1.

...

Pain Elemental's missile:

  Missile:
    PAIN D 5 A_FaceTarget
    PAIN E 5 A_FaceTarget
    PAIN F 4 Bright A_FaceTarget
    PAIN F 1 Bright A_PainAttack
    Goto See

In DEHACKED, the durations are "5, 5, 5, 0", not "5, 5, 4, 1".