DEHACKED/Zdoom problem (works in prboom+,Eternity)

I have a really, really simple DEH (really BEX) file, based on one of the MBF examples. It just remaps the code pointer for an exploding barrel to the mushroom code pointer:

Pointer 0 (x 811)
Codep frame = 1075

The above works as a separate file or as an embedded DEHACKED lump in Prboom+ and Eternity, but not at all in GZDoom or KZDoom. Can anyone explain to me why? Thanks!

Try this instead:

[CODEPTR]
Frame 811 = Mushroom

"Codep frame" is a holdover from the way DOS Dehacked used to have to work around Watcom C's handling of function pointers. Not sure of exact details. Boom added a way to set state functions much more directly and by their source name. I expect ZDoom decided to drop the old way because it doesn't make much sense or is too hard to emulate when the fixed array of actor states is replaced with a hierarchy.

[5 minutes later] That said your mushroom effect seems to work in ZDoom 2.8.1...

Weird. But your fix works. Thanks!

In what version of ZDoom did this not work?

25 minutes ago, RjY said:

"Codep frame" is a holdover from the way DOS Dehacked used to have to work around Watcom C's handling of function pointers. Not sure of exact details. Boom added a way to set state functions much more directly and by their source name. I expect ZDoom decided to drop the old way because it doesn't make much sense or is too hard to emulate when the fixed array of actor states is replaced with a hierarchy.

That syntax in the original post is neither Dehacked nor BEX but possibly cooked up by something else that later found its way into PrBoom and Eternity.

ZDoom supports original DEH and BEX extensions and this particular thing has never come up.

47 minutes ago, Graf Zahl said:

That syntax in the original post is neither Dehacked nor BEX but possibly cooked up by something else that later found its way into PrBoom and Eternity.

ZDoom supports original DEH and BEX extensions and this particular thing has never come up.

I fear you may be mistaken -- I looked into it a bit more to confirm the syntax is part of original dehacked. It is documented in dhe30a.zip/SAMPLE.DEH:

# These are the new code pointers.  The value after "Pointer" can range
# anywhere from 0 through 447.  There is no easy way to tell which Frame
# corresponds to which pointer, however, so it isn't a good idea to play
# around with these manually.  The "Frame 2" in parenthesis is just for
# reference purposes, and is not used.  And the value given on the next
# line is the number of the Frame whose code pointer should be placed in
# the code pointer we are editing (1 in this case).  This roundabout way
# of storing things is necessary due to the complexities of code pointers
# between every version of Doom.

Pointer 1 (Frame 2)
Codep Frame = 243

If there's been some extension, I can only think of the addition of lots of frames for Doom beta actors and the A_Mushroom in MBF. Many years ago I recall having to add a large number of dummy frames into PrBoom's state table to make A_Mushroom's frame correspond to 1075 in order to get MBFEDIT!.wad to work properly; PrBoom didn't have the Doom beta stuff at the time (entryway has since added it into PrBoom+)

That said I also checked Jon's use of A_Mushroom in rc2 of his wad, and its use in MBFEDIT!.wad, worked as I expected in ZDoom 2.8.1. I haven't checked any *zdoom version more recent.

I tested it in recent-ish builds of GZDoom and QZDoom (for Mac); the syntax is straight out of one of Lee Killough's example files in the MBF source.

I saw x instead of Frame in the OP. Maybe that is what Graf is referring to?

Here's the code for handling the "Pointer" keyword in ZDoom's dehacked support code.

static int PatchPointer (int ptrNum)
{
    int result;

    // Hack for some Boom dehacked patches that are of the form Pointer 0 (x statenumber)
    char * key;
    int indexnum;
    key=strchr(Line2, '(');
    if (key++) key=strchr(key, ' '); else key=NULL;
    if ((ptrNum == 0) && key++)
    {
        *strchr(key, ')') = '\0';
        indexnum = atoi(key);
        for (ptrNum = 0; (unsigned int) ptrNum < CodePConv.Size(); ++ptrNum)
        {
            if (CodePConv[ptrNum] == indexnum) break;
        }
        DPrintf(DMSG_SPAMMY, "Final ptrNum: %i\n", ptrNum);
    }
    // End of hack.

    // 448 Doom states with codepointers + 74 extra MBF states with codepointers = 522 total
    // Better to just use the size of the array rather than a hardcoded value.
    if (ptrNum >= 0 && (unsigned int) ptrNum < CodePConv.Size())
    {
        DPrintf (DMSG_SPAMMY, "Pointer %d\n", ptrNum);
    }
    else
    {
        Printf ("Pointer %d out of range.\n", ptrNum);
        ptrNum = -1;
    }

    while ((result = GetLine ()) == 1)
    {
        if ((unsigned)ptrNum < CodePConv.Size() && (!stricmp (Line1, "Codep Frame")))
        {
            FState *state = FindState (CodePConv[ptrNum]);
            if (state)
            {
                int index = atoi(Line2);
                if ((unsigned)(index) >= Actions.Size())
                {
                    SetPointer(state, NULL);
                }
                else
                {
                    SetPointer(state, Actions[index], CodePConv[ptrNum]);
                }
                DPrintf(DMSG_SPAMMY, "%s has a hacked state for pointer num %i with index %i\nLine1=%s, Line2=%s\n",
                    state->StaticFindStateOwner(state)->TypeName.GetChars(), ptrNum, index, Line1, Line2);
            }
            else
            {
                Printf ("Bad code pointer %d\n", ptrNum);
            }
        }
        else Printf (unknown_str, Line1, "Pointer", ptrNum);
    }
    return result;
}

As you can see, Pointer 0 (x whatevs) is considered a hack. There is an attempt at supporting them, and you can blame me for it. :p The problem being that you don't replace the pointer 0, it's a weird syntax. If it doesn't work anymore, well, I don't know what to tell you, it definitely worked with whatever it was I tested way back then. There's been over seven years of code changes since.

Thanks for the analysis. I'm happy to just switch syntaxes. It's kinda weird how the MBF examples use this older format, since MBF introduced the newer syntax. If I understand correctly. But perhaps the examples were developed first. No matter! Thanks all.