MBF: A_LineEffect with teleport action always telefrags

[boris]

So I've been toying around with DECOHack and MBF(21), and noticed something quite peculiar. When using the A_LineEffect action pointer with a teleport action (like 210, which is one of the few teleport actions that actually work with A_LineEffect) the teleported actor will always telefrag whatever is at the destination. Even if the teleported thing should never ever be able to telefrag anything. This behavior happens in WinMBF, DSDA Doom, Woof (and most likely others). Doesn't happen in GZDoom (no surprise there).

 

Example WAD: telefrag.zip

 

This WAD contains a DeHackEd patch that uses A_LineEffect to teleport a stimpack to the teleport destination at the player's starting position, instantly telefragging the player.

 

Looking at the code I assume that happens because the actor is set to be a player for executing the action. Is there any way to get rid of this behavior? If not, maybe there could be some compatibility option in the future (MBF22 or whatever), since letting actors teleport themselves opens up quite interesting options that (to my knowledge) haven't really been explored, but this telefragging behavior dampens its usefulness quite a bit.

[printz]

The mock-up "player" is there for the monster to be able to activate all those specials which aren't allowed for monsters. It's otherwise a troublesome piece of code which was causing crashes in advanced ports like Eternity, so I removed it and replaced the activation type with something proper. I would guess this also caused some regressions, so I'll investigate… Under MBF, this fake "player" causes undefined behaviour if you use locked door specials. Most of the time, these doors will open! but it's not a rule. Obviously I had to somehow simulate this behaviour in Eternity by assuming it true (just like how the crushing 16-tall stairs are undefined behaviour in DOOM!)

 

Warning: PrBoom+ implements LineEffect differently from MBF, especially regarding one-use specials! They're supposed to forever block the actor from triggering subsequent LineEffects, but in PrBoom+ they only block the one state (frame) from doing so!

 

Solution? Try and see the UMAPINFO bossaction property. That one has code similar to LineEffect, but instead of a troublesome mock-up player, it forwards a boolean called "bossaction" to the activation specials, which all-in-all allows the monster to trigger most specials, except manual doors, teleporters and locked specials -- specifically these ones which cause problems and inconsistent behaviour with LineEffect. This of course won't help here, but the way is set: a "bossaction" boolean parameter for P_Use/Cross/ShootSpecialLine which allows the activator, regardless of player status, to run most specials.

Edited November 13, 2021 by printz

[jeff-d]

6 hours ago, boris said:

Looking at the code I assume ....

 

Looking at the code, did you intend to leave mo->player pointing to &player if the special is zero?

Edited November 13, 2021 by jeff-d

[boris]

1 hour ago, printz said:

Solution? Try and see the UMAPINFO bossaction property.

 

That's not really a substitute, since A_LineEffect can do so much more while the actor is alive.

 

1 hour ago, jeff-d said:

Looking at the code, did you intend to leave mo->player pointing to &player if the special is zero?

 

I'm not the author of that port. The issue is that players will telefrag, and if the thing that's about the execute the special is set to be a player it'll telefrag whatever it teleports into.

[printz]

8 hours ago, boris said:

That's not really a substitute, since A_LineEffect can do so much more while the actor is alive.

I was talking about development solutions, not user. Like if you're going to make a new MBF22 port family, you can make a new clean A_LineEffect variant that reuses logic from the UMAPINFO bossaction.

[boris]

12 minutes ago, printz said:

I was talking about development solutions, not user. Like if you're going to make a new MBF22 port family, you can make a new clean A_LineEffect variant that reuses logic from the UMAPINFO bossaction.

 

Yes, that's probably the best solution.

 

Reading my OP again I realize that it might be interpreted as such that I wanted to change the code to be more robust. That's not the case, I was merely asking if I as the user can influence this behavior (through compat settings or whatever).

After 20+ years of existance it'd obviously be very risky to meddle with the current behavior (although I'm not even sure if that action pointer has been used in the wild), so my suggestion is that whenever @kraflab or someone else comes up with a successor of MBF21 the situation could be remedied.

[printz]

18 hours ago, boris said:

(like 210, which is one of the few teleport actions that actually work with A_LineEffect)

Holy shit! That's because WR and W1 classic and extended specials do not work in A_LineEffect! That includes everything that isn't generalized. The reason is that P_UseSpecialLine is dumb at the end and just returns true, even if the line type is none from the SR and S1 set. It can return false if checks fail in the beginning, such as detecting walkover generalized types (in which case it will try the walkover specials).

 

Eternity inadvertently fixed this, yeah, due to the massive refactoring needed when @Quasar added support for parameterized specials (he did great work with that refactoring, the code was ugly in vanilla and BOOM). If the author is messy and uses WR and W1 conventional specials in LineEffect, which won't work in MBF or PrBoom, they will trigger in Eternity and cause unexpected behaviour!

Edited November 14, 2021 by printz

[boris]

49 minutes ago, printz said:

Holy shit! That's because WR and W1 classic and extended specials do not work in A_LineEffect!

 

Huh, that indeed seems to be the case, even in Woof, so I assume the original MBF wasn't compliant to its own specs in that regard? So if one wants to use that action pointer is has to be thoroughly tested in a plethora of ports.

[printz]

I've updated Eternity to emulate and be compatible with all the LineEffect quirks mentioned here. I hope it was the last one.

 

Beware anyway of the PrBoom/MBF difference.

 

EDIT:

 

14 hours ago, jeff-d said:

 

Looking at the code, did you intend to leave mo->player pointing to &player if the special is zero?

Most likely not originally intended! That's PrBoom's altered behaviour, it's different from MBF and -complevel 11 won't change it! See how it is in WinMBF (the original code): 

https://github.com/team-eternity/WinMBF/blob/3af60d718b1fe272769ee9eeb768b88e29a6cd7e/Source/p_enemy.c#L2546-L2564 . In there it doesn't risk causing unwanted effects if special is zero! Who knows what this will do if a PrBoom monster with LineEffect with special 0 goes on to trigger a generalized special? That special will see the player pointer!

Edited November 14, 2021 by printz

[JadingTsunami]

3 hours ago, printz said:

I've updated Eternity to emulate and be compatible with all the LineEffect quirks mentioned here. I hope it was the last one.

 

Beware anyway of the PrBoom/MBF difference.

 

In case it is helpful, Boss Actions in PrBoom+ are broken in a similar way. See this (fairly old) GitHub issue for details.

 

The problem appears to be a copy/paste of the broken code from A_LineEffect into the BossAction handlers.

 

In UMAPINFO Designer I have taken the crossable linedef types out of the default list available for Boss Actions. If a user supplies a custom linedef type that is crossable, they will see a warning message appear. It's my hope to at least raise awareness of the issue that way.