MBF21 DeHackEd thing explode on spawn

[punch you in the face man]

Edit: this should have been posted in Editing Questions, whoops. Consider the question solved as well.

 

Working in MBF21 DeHackEd (specifically DecoHack), I'm trying to make a melee weapon that creates a radius damage (generic explosion) around the player when used. It spawns a custom thing that inflicts a radiusdamage and then disappears. The code below causes this behaviour when the fist punches. As you'll see if you run it, nothing actually happens. Why is this? Does the thing need more attributes defined in order to explode when it spawns? I suspect that the args on the radiusdamage codepointer aren't correct but trying different values manually has had no effect.

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

Doom version = 21
Patch format = 6


Thing 151 (Extra thing 0)
Initial frame = 1100

Frame 6
Args1 = 151

Frame 1100
Next frame = 0
Duration = 0
Args1 = 128
Args2 = 128

[CODEPTR]
FRAME 6 = WeaponProjectile
FRAME 1100 = RadiusDamage

Edited August 4, 2021 by punch you in the face man : wrong board

[Tango]

I haven't actually loaded this up and tested myself, but it looks like frame 1100 is the first and only frame of that Thing, and also the frame that the codepointer/action is on. there's a quirk in the game with actions on the first frame of a Thing - they will be ignored completely. I think the DecoHack documentation mentions this somewhere, but you'll need to give the actor a second frame, where the first frame is 0 duration and otherwise does nothing, and the second frame is where the codepointer is. this is why the Archvile fire has that "flame start" sound effect on its fire that never actually plays, because the codepointer for playing that sound is on the first frame

[punch you in the face man]

Interesting. It is indeed in the DeHackEd hardcodings documentation, although I probably never would have figured out what this meant on my own:

Quote

The [SpawnState] state on every thing is SET instead of updated via Thinker
update, which means that it's action pointer will not be called. The state
will also NOT ADVANCE if the duration of the that frame is 0 or less.

So it seems the first frame also has to have a duration of at least 1. Thanks for the help!

[MTrop]

Apologies for the month-old bump, but more people need to know about this Doom Engine weirdness. I tried to make a patch one time that essentially removed nearly all of the place-able things in Doom, and ran into the engine quirk immediately.

 

Here's what I think is happening: The Spawn State is set every time an object is created, which will not call its action pointer. HOWEVER, something special occurs for objects spawned on map start - Doom has to initialize the spawn state and simulate one frame before the wipe to the map beginning. It will subtract the current duration by 1 on all of those spawned objects, which creates a problem for objects with an initial duration of 0 - it will make the duration negative, which means Doom will not update that actor unless it somehow changes state again from outside itself (being shot, etc.).

 

So, that's why the duration of 1 is needed on the spawning state, most commonly on place-able Things (but not usually on Things spawned during gameplay).