ZDoom works incorrectly with attached DEH

[entryway]

Test level with DEHACKED lump inside the wad:
http://prboom-plus.sourceforge.net/zdoom_deh.zip

You can see correct behavior with any compatible port. With PrBoom-Plus for example. Monsters should not be spawned there.

Thing 29 (Demon Spawn Cube)
Death frame = 791
Exploding frame = 791
Bits = NOBLOCKMAP + NOGRAVITY + DROPOFF + MISSILE
# Originally:
# Death frame = 0
# Exploding frame = 0
# Bits = NOBLOCKMAP + NOGRAVITY + DROPOFF + NOCLIP + MISSILE

[CODEPTR]
Frame 788 = NULL
Frame 789 = NULL
Frame 790 = NULL
# Originally:
# Frame 788 = SpawnFly
# Frame 789 = SpawnFly
# Frame 790 = SpawnFly

[Graf Zahl]

If you create patches that depend on timing glitches proper function is not guaranteed. You didn't clear the A_SpawnSound call which in turn also calls A_SpawnFly and it just so happens that ZDoom reaches this and spawns the monster.

A_SpawnFly depends on very special setup to work (e.g. all frames having the same duration) and some of this had to be changed to allow custom cubes. In particular this means that ZDoom does no longer count A_SpawnFly calls but actual gametics to determine the cube's location.

Sorry, but this can't be changed unless a compatibility option was added. I'll do that if some real world WAD proves that this is essential. But to me all this seems to do is create useless cubes.

[entryway]

Graf Zahl said:

If you create patches that depend on timing glitches proper function is not guaranteed. You didn't clear the A_SpawnSound call which in turn also calls A_SpawnFly and it just so happens that ZDoom reaches this and spawns the monster

Oh, thanks! I removed A_SpawnSound for 32innail, but forgot for new one. Yeah, it also calls A_SpawnFly.

[entryway]

Graf Zahl said:

If you create patches that depend on timing glitches proper function is not guaranteed. You didn't clear the A_SpawnSound call which in turn also calls A_SpawnFly and it just so happens that ZDoom reaches this and spawns the monster.

A_SpawnFly depends on very special setup to work (e.g. all frames having the same duration) and some of this had to be changed to allow custom cubes. In particular this means that ZDoom does no longer count A_SpawnFly calls but actual gametics to determine the cube's location.

Sorry, but this can't be changed unless a compatibility option was added. I'll do that if some real world WAD proves that this is essential. But to me all this seems to do is create useless cubes.

http://prboom-plus.sf.net/zdoom_deh_test2.zip

The only difference between two wads is Z coordinate of spawner ("spawned on ceiling" flag)

Why these wads work differently if zdoom is precise?

ADDED:
To avoid crashes you probably want to add check for NULL after
spit = P_SpawnMissile (self, targ, spawntype);
See map30 with DEH from the first post.

[Graf Zahl]

entryway said:

Why these wads work differently if zdoom is precise?

I'll have to check in a debugger. This is certainly not right.

[entryway]

Graf Zahl said:

I'll have to check in a debugger. This is certainly not right.

And please, fix speed of cubes or add compatibility option (i think it's possible to force them from mapinfo), because some upcoming (sure very nice) pwad works differently in glboom-plus and gzdoom. In compatible ports speed depends from pitch angle. Check zdoom_deh_0.wad with glboom-plus.

[Graf Zahl]

entryway said:

Why these wads work differently if zdoom is precise?

These don't work because you took the NOCLIP flag off the cube. As a result of this change the cube behaves just like a normal projectile and explodes when it hits an obstacle. And precisely that happens before it has a chance to spawn something.