GZDoom breaks Plutonia maps?

[quakezero]

I've been playing through The Plutonia Experiment in GZDoom, and so far I've had two maps break; Map09 and Map32. Both of them involve the blue keycards in their respective maps. More specifically, the floors holding the keycard don't lower when they should. In Map09 I've hit the button to lower the pillar holding the blue keycard, and it doesn't work. Curiously, the pillar lowers as it should if I collect the keycard itself using IDCLIP, which I had to resort to to beat the level in the first place.

 

Spoiler

In Map32, I've collected the yellow and red keycards, which should lower the third wall containing the blue card and a bunch of enemies, but it doesn't work for (what I think is) the same reason.

 

Spoiler

 

I don't have any mods loaded that would interfere with the game in this way, and I'm playing with the Doom (strict) compatibility, if that matters.

I am using Wadsmoosh, but I've tried playing the game with only Plutonia loaded, and they were broken there as well.

 

What's going on? Is there a fix for this?

[bofu]

I was able to reproduce this. I suspect this is an improper handling when the "Use Doom's floor motion behavior" compatibility setting is set to yes, as setting it to no will fix it.

 

Normally in vanilla, when a solid Thing is stuck on a sector that isn't tall enough to contain it, it will prevent the floor from moving, even downward. That's not an issue because in these two cases, the things on those maps are pickup items and aren't solid. But it looks like that's not being handled correctly in this case.

Edited February 16 by bofu

[Shepardus]

Took a look at MAP32. Surprisingly, as of v4.11.3, it's broken when using Doom (strict) compatibility but not when using default compatibility. Seems to be tied to the "Use Doom's floor motion behavior" compatibility flag (in map/action behavior). I would recommend filing a bug on the ZDoom forums or GitHub if you haven't already (but first check a dev build to see if it's already been fixed, I haven't checked myself).

[bofu]

I just tested this in the Dev build from February 10 and wasn't able to reproduce, so hopefully, that means it'll be fixed in the official release as well.

Edited February 16 by bofu

[Shepardus]

Ah, it was fixed here: https://github.com/ZDoom/gzdoom/commit/61c2f5f8c022220c3e728d9a8eca8dc6737e9cd8

So to OP, you could either switch to a development build or just flip that flag off for now.

[No-Man Baugh]

Not related to your issues at all, but shoutouts to how GZDoom handles teleporters screwing up how the Archvile in Caughtyard is supposed to work in Vanilla Doom:

 

 

 

 

I ain't saying how it works vanilla is any more fair or better, but I think seeing it in action makes it way more understandable what Dario was going for
 

[quakezero]

Ah, switching to a dev build fixed it. Thanks!

[Arsinikk]

This floor compat issue has been an issue for a majority of my megawads and has been an issue since GZDoom v4.11.0.

 

It has to do with a broken implementation of Compat_floormove 1.

 

I brought it up here on Github and it has been fixed in the dev version:
https://github.com/ZDoom/gzdoom/issues/2236

 

But there has not been a stable GZDoom release since that has been fixed (back in October 2023).

 

This has been increasingly annoying for me personally since my own WADs like Hell Revealations and 100/200 Line Massacre break and have softlocks in GZDoom because of this.

[bofu]

1 hour ago, Arsinikk said:

This floor compat issue has been an issue for a majority of my megawads and has been an issue since GZDoom v4.11.0.

 

It has to do with a broken implementation of Compat_floormove 1.

 

I brought it up here on Github and it has been fixed in the dev version:
https://github.com/ZDoom/gzdoom/issues/2236

 

But there has not been a stable GZDoom release since that has been fixed (back in October 2023).

 

This has been increasingly annoying for me personally since my own WADs like Hell Revealations and 100/200 Line Massacre break and have softlocks in GZDoom because of this.

The good news is you can include an OPTIONS lump in the wad or side load it on a different WAD to disable that setting, and only GZDoom will parse it.

[Individualised]

1 hour ago, Arsinikk said:

This floor compat issue has been an issue for a majority of my megawads and has been an issue since GZDoom v4.11.0.

 

It has to do with a broken implementation of Compat_floormove 1.

 

I brought it up here on Github and it has been fixed in the dev version:
https://github.com/ZDoom/gzdoom/issues/2236

 

But there has not been a stable GZDoom release since that has been fixed (back in October 2023).

 

This has been increasingly annoying for me personally since my own WADs like Hell Revealations and 100/200 Line Massacre break and have softlocks in GZDoom because of this.

Does this issue occur by default with GZDoom on these .WADs or does it only happen when vanilla compatibility is enabled?

[Arsinikk]

1 hour ago, Individualised said:

Does this issue occur by default with GZDoom on these .WADs or does it only happen when vanilla compatibility is enabled?

For those WADs, it happens because "compat_floormove 1" is set in ZMAPINFO.

The reason it is set that way is because when "compat_floormove" works like it's supposed to (as a compatibility setting), some of my maps require it in ZDoom ports to work correctly. 

Use Doom's floor motion behavior (Yes/No)
compat_floormove (CVAR and MAPINFO)
This option undoes a Boom fix to floor movement logic. If this option is on, a floor may rise through the ceiling, or a ceiling may lower through a floor.

Since my WADs are made for Vanilla, there are maps that specifically rely on behaviour that can possibly break in Boom or higher.

That compatibility option is there for a reason and does things. I can't simply turn it off, as it could also cause problems in certain maps.

 

What I do know is that if you have "compat_floormove 1" in the ZMAPINFO lump config (which I'm sure mapsets do besides mine do), it will force the setting to be on for a map or all maps if in the "defaultmap" section. It can also be triggered in the compatibility menu via the "Use Doom's floor motion behavior" option or by turning on the "Doom (strict)" compatibility. This will also cause the same issues.

 

I also know that GZDoom has some mapsets / maps where it automatically applies certain compatibility patches to, which if that compatibility setting is enabled has the potential to cause problems.

 

 

2 hours ago, bofu said:

The good news is you can include an OPTIONS lump in the wad or side load it on a different WAD to disable that setting, and only GZDoom will parse it.

To be honest, I'm less concerned about fixing it myself and more about others who play my wads.  I can't just remove it or else it can cause other unintended issues in maps. The compatibility option is there for a reason. I've already had some bug reports for some of my WADs having softlocks or not working correctly because of this.

 

Honestly the best solution at the moment is to just tell people to use GZDoom's Dev Build. However, I kinda hate doing that because it's a Dev Build. Using Dev Builds, by design, invites many other things to potentially go wrong, because they are testing builds.

 

 

*Edit / Addendum : The ZDoom Wiki entry on this compatibility option is severely simplified and doesn't explain everything that it does.

 

The way Boom does floor movement is quite different than the original Doom, especially with adjacent sectors with the same tag. Say you have an action to move a tagged sector to highest floor, and that sector is adjacent to a bunch of other same tagged sectors. In Boom it looks at each sector with a certain tag and does the action for each sector. This means, depending on the height of the sectors touching each of tagged sectors, the tagged sectors can end up at different heights. In Doom, however, it instead looks for the first lowest indexed tagged sector in a group of adjacent sectors, and then applies that action to all sectors which it is adjacent to. Which means in Doom, all those sectors would end up at the exact same height of the first lowest indexed tagged sector (in the exact same setup where in Boom the tagged sectors would end up with different heights).

Edited February 17 by Arsinikk

[andrewj]

4 hours ago, bofu said:

The good news is you can include an OPTIONS lump in the wad or side load it on a different WAD to disable that setting, and only GZDoom will parse it.

Other source ports support an OPTIONS lump, e.g. anything based on MBF.

[NiGHTMARE]

2 hours ago, Arsinikk said:

Honestly the best solution at the moment is to just tell people to use GZDoom's Dev Build. However, I kinda hate doing that because it's a Dev Build. Using Dev Builds, by design, invites many other things to potentially go wrong, because they are testing builds.

 

I think this bug is just the latest of example of how, when it comes to GZDoom, the only differences between an official release and a dev build is the name and where to download it. There have been numerous times over the years where dev builds are more stable than the latest official release.

Edited February 17 by NiGHTMARE

[Individualised]

On 2/17/2024 at 2:47 AM, Arsinikk said:

This floor compat issue has been an issue for a majority of my megawads and has been an issue since GZDoom v4.11.0.

 

It has to do with a broken implementation of Compat_floormove 1.

 

I brought it up here on Github and it has been fixed in the dev version:
https://github.com/ZDoom/gzdoom/issues/2236

 

But there has not been a stable GZDoom release since that has been fixed (back in October 2023).

 

This has been increasingly annoying for me personally since my own WADs like Hell Revealations and 100/200 Line Massacre break and have softlocks in GZDoom because of this.

So I'm not sure when, but I must have updated, because I've been routinely getting softlocks in both Doom Zero and Doom 64 CE due to sectors not lowering properly that I know didn't happen before.

 

Given that this breaks many mapsets that aren't doing anything too out of the ordinary I'm surprised that an emergency fix wasn't pushed as a stable release.

[Arsinikk]

1 hour ago, Individualised said:

So I'm not sure when, but I must have updated, because I've been routinely getting softlocks in both Doom Zero and Doom 64 CE due to sectors not lowering properly that I know didn't happen before.

Hmmmm regarding Doom Zero, it doesn't even have any MAPINFO lumps (so no forced compatibility options). So my guess for those softlocks is manually setting the compatibility options to "Doom" or "Doom (Strict)". Specifically the "Use Doom's floor motion behavior" option.

 

Whenever the specific option "Use Doom's floor motion behavior" is set to on, no matter the mapset, softlocks can happen. I think the biggest trigger I've noticed for this is when a zero height sector has an item on it, it will not lower down and get stuck for some reason because of that item. (obviously an item has no collision, so it shouldn't stop the sector from lowering, but it does for some reason).

Edited March 4 by Arsinikk

[JoeyKelastiof]

On another note, since we're talking about plutonia and gzdoom; in map 27, if you want to have 100% kills, make sure you switch to doom (strict) to kill the hidden archvile with rockets. ( or activate vertical explosions for this moment ).  (saw this on a github, did not come up with it myself but it helped me finish plutonia with 100 % )

Edited March 4 by JoeyKelastiof

[Individualised]

I hate to bump this topic again but I found yet another example; this time on a non-Doom IWAD (Snap the Sentinel). I've never even intentionally enabled strict Doom floors on that game (separate config from Doom) - are strict vanilla floors enabled by default on GZDoom? This is starting to trip me up over and over and I'm surprised more people aren't reporting this issue if this is a default setting.

Edited March 27 by Individualised

[ObserverOfTime]

I just want to add that since we are talking Plutonia, even on the proper complevel, some maps in Plutonia's sequel (in the later half IIRC) are bugged regardless of port. I distinctly recall being unable to get 100% kills on some maps in the 20-something range because some monster closets lack the proper tags for activation, making it impossible to clear out the map without cheats. There were one or two maps like this but it's been a hot minute since I played through the sequel. I remember being utterly confused and doing some inspecting with UDB, only to find that there are unfortunately some mapping errors present preventing one or two closets from triggering. This should be mentioned on the maps respective wiki page as well I recall.

 

The maps can all be completed, but if you are someone who needs every monster dead, be aware that there are some issues in Plutonia 2. It did not detract from my enjoyment, just a minor gripe in the grand scheme of things really.

[Xaser]

6 hours ago, Individualised said:

I hate to bump this topic again but I found yet another example; this time on a non-Doom IWAD (Snap the Sentinel). I've never even intentionally enabled strict Doom floors on that game (separate config from Doom) - are strict vanilla floors enabled by default on GZDoom? This is starting to trip me up over and over and I'm surprised more people aren't reporting this issue if this is a default setting.

 

If you suspect something is broken in GZDoom, it's better to post a bug report than post in here -- there's no guarantee any of the devs will see this post in a random Doomworld thread.

[OniriA]

3 minutes ago, Xaser said:

there's no guarantee any of the devs will see this post in a random Doomworld thread.

 

Isn't Graf active around here aswell?

[bofu]

The issue is known and fixed in dev builds. We're just all waiting on a release build with the fix.

[ReaperAA]

6 hours ago, ObserverOfTime said:

I distinctly recall being unable to get 100% kills on some maps in the 20-something range because some monster closets lack the proper tags for activation, making it impossible to clear out the map without cheats. There were one or two maps like this but it's been a hot minute since I played through the sequel. I remember being utterly confused and doing some inspecting with UDB, only to find that there are unfortunately some mapping errors present preventing one or two closets from triggering. This should be mentioned on the maps respective wiki page as well I recall.

 

The maps can all be completed, but if you are someone who needs every monster dead, be aware that there are some issues in Plutonia 2. It did not detract from my enjoyment, just a minor gripe in the grand scheme of things really.

 

I know one of those is Map27: Red Hot. In that map, there are 17 enemies which never teleport, irrespective of the port.

Edited March 28 by ReaperAA

[Professor Hastig]

7 hours ago, OniriA said:

 

Isn't Graf active around here aswell?

 

That doesn't guarantee that he may see and read this thread. The GZDoom team has said multiple times that bugs are to be reported through the proper channels to ensure that they don't get lost.

What do you think will happen with this thread if nobody replies for a day or so? The activity here is high enough that the topic will drop off to the second or third page quickly, and if the person you want this to see happens to be inactive in that time period it may never reach them.

[ObserverOfTime]

16 hours ago, ReaperAA said:

 

I know one of those is Map27: Red Hot. In that map, there are 17 enemies which never teleport, irrespective of the port.

Bingo, that is one of them, good call. The teleporter closets with sector tag 10 don't have any activating linedefs as far as I can tell, meaning the closet never triggers. Also there's no sectors tagged with tag 42, rendering another closet inoperative. It's just a bunch of shotgunners, but it is still a little annoying when trying to clean out the map:

Spoiler

 

There's another one in Map23 Aztecorum, this time it's not a missing tag but things are stuck inside each other in a closet, meaning they can't move around and ambush you properly. I'm starting to remember it now, haha. Although with this one you can kill the monsters without cheating since the closet actually opens up:  

Spoiler