...yeah, a bit of a corner case, this one.
So this bug came up while I was testing MAYhem 2025. The gist of things is that I changed some of the locked door messages via DeHackEd and then had the player trigger them via Boom's generalized locked door actions: for some reason you have the option of having a locked door be triggered via walkover, so I used that in conjunction with some voodoo doll conveyors to essentially send messages directly to the player as needed.
I've tested it in DSDA-Doom and it works fine there, but when it comes to GZDoom the messages don't appear unless the player themselves crosses the linedef. Xaser speculated that the message print is only applied to the actor that triggers the linedef as opposed to the player that owns them, which sounds as plausible an explanation as any. I'd be keen to get some input on this issue, as I'd very much like this project to play nicely with GZDoom.
(As an aside, it's also worth pointing out that the current 1.0 beta also has the wrong messages being displayed in GZDoom: not sure why it and DSDA-Doom apply different messages to the same action like that, but I just fixed it by adding more message replacements in the (currently unreleased) next beta. It's a lot more minor in comparison to the main bug that I'm reporting here.)
(GZDoom 4.14.2) Voodoo dolls cannot trigger walkover-based locked door messages
Moderator: GZDoom Developers
Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Re: (GZDoom 4.14.2) Voodoo dolls cannot trigger walkover-based locked door messages
Based on Xaser's suggestion, this was easily fixed. However I did it as a pull request because I am not sure if it is a good idea to do this without a compatibility option or not. I don't foresee that this could break anything, but you never know with this engine.
Also, yes, the messages that appear are indeed incorrect; I get the standard "you must have x key to unlock this object" messages.
In case the PR gets accepted, here is a build artifact for the CI run for that PR, you can use it to test your map. Simply extract it on top of a fresh (throw-away) dev build. (You need the dev build's dependencies, like zmusic.dll, because the build artifact will require the new zmusic version)
Also, yes, the messages that appear are indeed incorrect; I get the standard "you must have x key to unlock this object" messages.
In case the PR gets accepted, here is a build artifact for the CI run for that PR, you can use it to test your map. Simply extract it on top of a fresh (throw-away) dev build. (You need the dev build's dependencies, like zmusic.dll, because the build artifact will require the new zmusic version)