Possible unintended behavior with Dehacked “shootable” flag

[KLNeidecker]

This may be unintended, but when launching with nomonsters active (for map testing), a thing with “shootable” active via dehacked (flag 4 IIRC) seems to be defaults considered a monster and therefor not in the map.

I noticed this when making destructible decorations. Other ports show the decoration flagged shootable, but Retro treats them as monsters.

Doom Retro is by far my favorite port for vanilla-ish work so it’s what I’m using as a base for the mapset’s features.

Obviously, destructible decorations (or whatever similar dehacked things someone might make shootable) not showing up with nomonsters activated is reeeeeallly confusing. Ask me how I know! Yep, I spent an hour trying everything under the sun to see where I went wrong…before going “oh crap…maybe it’s because I’m launching via UDB with nomonsters active…” and yeah.

If I’m simply missing some flag which would tell Retro the thing is indeed not a monster, and this is user error, let me know. Otherwise I think the “things which are shootable” check you may be doing is too broad, though only rears it’s head for the edge-case of shootable non-monster dehacked patch launched with nomonsters active… certainly not something everyone will run into.

Great work, love the port to death, and thank you for all the work you put into it!

Edit:
Yeah, it’s in p_mobj.c

if (!spawnmonsters && (mobjinfo[i].flags & MF_SHOOTABLE) && type != Barrel && (type != OfficeLampBreakable || !legacyofrust) && (type != Cacodemon || !hacx)) return NULL;

Maybe a check for “counts for total” would be better? I’d imagine most dehacked monsters would have that flag, while most decorative objects would not, vs. just checking shootable. Otherwise, a Retro bit “notmonster” or the like would be fine.

[bradharding]

Hi! Thanks for the report, and I'm glad you enjoy Doom Retro!

I made this change here, checking for MF_SHOOTABLE rather than MF_COUNTKILL, due to coming across some maps with dehacked monsters not having that flag set (for lost soul replacements, for instance). I'll have a think on what to do here. I'll probably just revert the change, but also there is the MF2_DECORATION flag which I could check for here (and which you could put "Retro bits = Decoration" in your DEHACKED lump).

[KLNeidecker]

Hi! Thanks for the report, and I'm glad you enjoy Doom Retro!

I made this change here, checking for MF_SHOOTABLE rather than MF_COUNTKILL, due to coming across some maps with dehacked monsters not having that flag set (for lost soul replacements, for instance). I'll have a think on what to do here. I'll probably just revert the change, but also there is the MF2_DECORATION flag which I could check for here (and which you could put "Retro bits = Decoration" in your DEHACKED lump).

Excellent, yeah. I figured you changed the check for some reason to do with some monsters sneaking past the original code due to dehacked patches.

But there is one complication I found due to this issue: as a work-around, I decided "hey, what if I use the MDF code pointer in dehacked A_addflags to add SOLID and SHOOTABLE to a thing during the spawn frames.

Then, jump away to another loop which does the same job the spawn state used to do, namely loop through the animation. Mainly I did this jump to avoid hitting the addflags command every single loop as that's silly.

And here is the oddity: Doom Retro seems to forget those flags when I switch state.

I'm away from the computer but let me give you pseudo code for my Decohack entry.

clear states
Clear flags

States
{
   Spawn:
      (Some spawn frame) A_ADDFLAGS(SOLID+SHOOTABLE)
      Goto main
   Main:
      (Basically the animation that used to live in spawn)
      Loop
}

So what happens is:

• Lamp shows up in the map
• I cannot shoot or bump into the lamp

Other ports like Woof:

• Lamp show up
• I can both shoot and bump the lamp

Now, if I do not jump to main, and instead stay in spawn, and apply the flags every loop, then it works as intended in Doom Retro.

So it seems Retro is forgetting the flag states... when changing states? Or after a time? Or maybe just in this odd edge case use I'm putting it towards? I don't know.

I'll be at the computer soon and I'll upload a dehacked patch which shows the issue.

Edit: here is the dehacked code, followed by the Decohack code which exhibits this issue:

Patch File for DeHackEd v3.0
# Created with DECOHack v0.37.0 by Matt Tropiano
# Note: Use the pound sign ('#') to start comment lines.

Doom version = 2021
Patch format = 6


Thing 81 (Tall lamp 2)
Bits = 0
Initial frame = 1100

Frame 1100
Sprite number = 137
Next frame = 1101
Duration = 0
Args1 = 6

Frame 1101
Sprite number = 137
Sprite subnumber = 32768
Next frame = 1102
Duration = 4

Frame 1102
Sprite number = 137
Sprite subnumber = 32769
Next frame = 1103
Duration = 4

Frame 1103
Sprite number = 137
Sprite subnumber = 32770
Next frame = 1104
Duration = 4

Frame 1104
Sprite number = 137
Sprite subnumber = 32771
Next frame = 1101
Duration = 4

[CODEPTR]
FRAME 1100 = AddFlags

/*****************************************************************************
 * DECOHack Patch File
 * Main
 ****************************************************************************/

#include <dsdhacked>
#include <friendly>




thing TechLamp2 : thing TechLamp2
{
	clear flags
	clear states
	states
	{
		Spawn:	
		    TLP2 A 0 A_AddFlags(flags SOLID+SHOOTABLE)
		    goto Main
		Main:
    		    TLP2 ABCD 4 Bright
    		    loop
    }
}

And this code DOES work fine, though you can see I'm spamming A_ADDFLAGS every 4 tics:

Patch File for DeHackEd v3.0
# Created with DECOHack v0.37.0 by Matt Tropiano
# Note: Use the pound sign ('#') to start comment lines.

Doom version = 2021
Patch format = 6


Thing 81 (Tall lamp 2)
Bits = 0
Initial frame = 1100

Frame 1100
Sprite number = 137
Next frame = 1101
Duration = 4
Args1 = 6

Frame 1101
Sprite number = 137
Sprite subnumber = 1
Next frame = 1102
Duration = 4
Args1 = 6

Frame 1102
Sprite number = 137
Sprite subnumber = 2
Next frame = 1103
Duration = 4
Args1 = 6

Frame 1103
Sprite number = 137
Sprite subnumber = 3
Next frame = 1100
Duration = 4
Args1 = 6

[CODEPTR]
FRAME 1100 = AddFlags
FRAME 1101 = AddFlags
FRAME 1102 = AddFlags
FRAME 1103 = AddFlags

/*****************************************************************************
 * DECOHack Patch File
 * Main
 ****************************************************************************/

#include <dsdhacked>
#include <friendly>




thing TechLamp2 : thing TechLamp2
{
	clear flags
	clear states
	states
	{
		Spawn:	
			TLP2 ABCD 4 A_AddFlags(flags SOLID+SHOOTABLE)
			loop
		
    }
}

[bradharding]

Hmm.. I think this flag issue is a completely separate thing. And after a quick look, I think I know what the cause is (it's in PIT_CheckThing in p_map.c). I'll work on this soon. Thanks again!

EDIT: Nah, that wasn't it...