GZDoom incompatibility?

[saturian1]

GZDoom is said to be far from vanilla, but does it ever matter in practice? I'm curious, are there any specific known WADs that work well in prboom/dsda-doom but break in GZDoom?

[Async Unicorn]

22 minutes ago, saturian1 said:

GZDoom is said to be far from vanilla, but does it ever matter in practice? I'm curious, are there any specific known WADs that work well in prboom/dsda-doom but break in GZDoom?

You can look at Abscission MAP32, due to it using intercept overflow trick it would not be played as intended.

There's also a lot of maps in which visual would not look as intended by author, like some of Dron12261 maps, I believe.

Yeah, as Gez mentioned, WADs for incompatible ports or some that use rare vanilla exploits.

Edited December 13, 2023 by Vanilla+Unicorn

[Gez]

There are two types of WADs that will not work in GZDoom:

1. Those that are created for a different, incompatible port, like Eternity or K8vavoom
2. Those that use some rare vanilla exploits that GZDoom cannot replicate, this is mostly limited to mikoportals and maps that require wallrunning.

[saturian1]

I remember playing Hell 2 Pay, there were 2 maps with intentional ghost monster bug, there was an army of imps walking through walls I think, and there was also a revenant. This wouldn't also work?

[Async Unicorn]

24 minutes ago, saturian1 said:

I remember playing Hell 2 Pay, there were 2 maps with intentional ghost monster bug, there was an army of imps walking through walls I think, and there was also a revenant. This wouldn't also work?

It should work if it's a popular wad, because of special integrated fixes for these specific maps if hashes matches.

Example: Doomsday of UAC (Tag 666 softlock in Ultimate Doom), Waterfront (Ghost monsters)

[fabian]

Most maps will be playable, but some probably play different than intended:

 

https://youtu.be/7SE7BIPe3Qs?si=GPLty8K8kqSna0T2

[CacoKnight]

2 hours ago, fabian said:

Most maps will be playable, but some probably play different than intended:

 

https://youtu.be/7SE7BIPe3Qs?si=GPLty8K8kqSna0T2

Which one is the normal Doom behavior? Should I disable "No vertical trust from explosions" = compatflags2=256 or enable "Use original DOOM explosion behavior" = compatflags2=512 or use both = compatflags2=768?

Edited December 13, 2023 by CacoKnight

[plums]

1 hour ago, CacoKnight said:

Which one is the normal Doom behavior? Should I disable "No vertical trust from explosions = compatflags2=256" or enable "Use original DOOM explosion behavior = compatflags2=512" or use both = compatflags2=768?

From a quick test it seems like "Use original Doom explosion behavior" is enough. "No vertical thrust" isn't set when you choose "Doom (strict)" compatibility, and I assume it exists either as an earlier compatibility flag, or for players playing ZDoom maps that need original explosion behaviour off but still want to disable vertical thrust. Probably having both on doesn't cause any problems, though.

See this post on the ZDoom forums: https://forum.zdoom.org/viewtopic.php?f=7&t=69085

[CacoKnight]

Thanks @plums ..I'm thinking something else now, what about on wads like Lullaby made specifically for GZDoom? Is this flag going to make the cacodemons behave in a weird way since they are probably programmed to move in a certain way there?

 

edit:

Using 512, let's see.

Edited December 13, 2023 by CacoKnight

[Shepardus]

4 hours ago, CacoKnight said:

I'm thinking something else now, what about on wads like Lullaby made specifically for GZDoom? Is this flag going to make the cacodemons behave in a weird way since they are probably programmed to move in a certain way there?

If a map made for GZDoom really needs certain compatibility flags, they can enforce those settings in their MAPINFO. Having played Lullaby recently, I would say it doesn't particularly matter for that map what blast damage settings you use. (I played with default compatibility except for "Use Doom heights for missile clipping" and "Monsters see invisible players," which is what I do for most GZDoom stuff, compatflags = 589824 and compatflags2 = 0.)

 

8 hours ago, saturian1 said:

I remember playing Hell 2 Pay, there were 2 maps with intentional ghost monster bug, there was an army of imps walking through walls I think, and there was also a revenant. This wouldn't also work?

Ghost monsters should work with the right compatibility flags. GZDoom is also able to recognize certain maps and automatically apply compatibility fixes required for those maps, and Hell 2 Pay is well-known enough that I think it would recognize the maps (I didn't check the list). Note that the "all-ghosts" bug is different and not supported in GZDoom (not many source ports do support that).

 

Most "normal" maps should work just fine in GZDoom, whether because they're not doing anything too unusual or because mappers often test their maps in GZDoom knowing that people will use it. Some things that are more likely to break:

• Advanced mapping tricks like mikoportals, as has been mentioned. Mappers can work around that by providing alternate ways to activate triggers that do work in GZDoom but don't work in vanilla. IIRC Remnant has a setup using conveyor belts, and KDiKDiZD uses either that or something with ZScript. Another example not involving mikoportals is the voodoo doll sequences in Doom 64 For Doom II, which I think use crushed barrels to push voodoo dolls and can be broken by changes in the explosion physics; the creators provided a workaround for GZDoom in the form of alternate versions of the maps that use conveyor belts, and used MAPINFO to route to those maps if you're using GZDoom instead of a vanilla port.
• Esoteric movement/physics techniques (glides, thingrunning, scrollers, janky diagonal walls, negative friction, etc.) - you'll most often see these in maps made by speedrunners, and to put it one way, you'll probably know when you see it. Examples include various maps in Poogers, D5DA MAP12 (GZDoom smooths out the collisions in this map, neutering its main gimmick, but I think also makes it impossible to get through a gap you're supposed to be able to get through), and 1x1 MAP04 (at the start of the map you're supposed to get catapulted through a narrow gap, but in GZDoom you just get stuck).
• Complex conveyor belt stuff - I'm not familiar with the details, but I know that mappers have to pay attention to the differences in Boom scroller physics between GZDoom and demo-compatible ports, either sticking to setups where they do behave the same or tolerating the differences. Sometimes it gets complicated enough that it's not worth the effort to maintain compatibility, for example YOUDOVOODOO.

[CacoKnight]

Oh nice thank you, so those custom wads settings can ALWAYS bypass normal source ports settings? Good to know, I'll keep it 512 by default.

[Arsinikk]

1 hour ago, Shepardus said:

Ghost monsters should work with the right compatibility flags.

Currently, while you can turn on the "compat_corpsegibs" in the compatibility menu and/or define it in ZMAPINFO, in GZDoom it will not do anything.

 

It requires the compatibility setting "compat_vileghosts" to also be turned on, which is can only be accessed via the console or via a script (ZScript and possibly ACS). Note that "compat_vileghosts" requires "compat_corpsegibs" to also be turned on to work. You can see in the source code, that vileghosts is typically only added for specific WADS (just search for "vileghosts"). Worst and I figured this out the hard way when developing a pseudo ghost monster script.

 

...

 

One minor thing to mention about GZDoom at the current moment, is that for GZDoom 4.11.0-4.11.3, if you turn on the "compat_floormove" compatibility setting in the menu or a map has it in the ZMAPINFO lump, those maps will completely break as the compatibility setting is currently broken and makes certain sectors just never move when they should.

 

It has since been fixed in Github, but until a new stable release is put out, those maps will stay broken in GZDoom. (like in many maps of Hell Revealations at the moment).

 

...

 

I'd say for the most part the compatibility settings of GZDoom do a good job of emulating Vanilla behaviour. Some minor things it does not do correctly like Shepardus laid out. I'll add/comment on some stuff:

• Mikoportals used as infinite scrolling walls don't work in GZDoom. Although this is pretty easy to "fake" in GZDoom, but just adding action 424 to the walls and it will scrolling them similarly in GZDoom.
• Barrel explosions can be tweaked via compatibility settings to get conveyors and the like to work pretty similarly to Vanilla. By default, yes, GZDoom physics are off, but in voodoo conveyor maps you can get them working correctly if you don't use mikoportals and you enable the right compatibility settings.
• The only physics based things that cannot be emulated are speedrunner tricks Shepardus listed above and running against decorations not building momentum. Technically you can still glide in GZDoom, it's just way harder than in other ports.
• Certain actions like a donut raising the inside sector instantly don't work in GZDoom on default. That's when you should use something like "compat_floormove" to allow for the buggy Doom floor movement code to work it's magic.
• It's also worth mentioning that Vanilla does things differently than Boom/modern ports, when it comes to executing actions. This is where stuff like "compat_light" or "compat_floormove" become useful. Vanilla only looks at the first tagged sector when it makes mapping changes, so when using "compat_light" it'll look for the first tagged sector lightlevel and use that for all the other tagged sectors. Boom does mapping changes per each tagged sector, which can result in different lightlevels based on what adjacent sectors are near. The same logic applies to "compat_floormove", but for moving floors instead of lightlevels.

Just for fun, I'll just show what vanilla settings I set in ZMAPINFO for vanilla doom projects:

defaultmap
{
	sucktime = 1
	nojump
	nocrouch
	compat_useblocking = 1
	compat_nopassover = 1
	compat_sectorsounds = 1
	compat_missileclip = 1
	compat_explode1 = 1
	compat_explode2 = 1
	compat_invisibility = 1
	compat_crossdropoff = 1
	compat_limitpain = 1
	compat_light = 1
	compat_pointonline = 1
	compat_floormove = 1
	compat_stairs = 1
	compat_trace = 1
	compat_soundtarget = 1
	compat_corpsegibs = 1
}

 

Edited December 14, 2023 by Arsinikk

[Shepardus]

58 minutes ago, Arsinikk said:

Currently, while you can turn on the "compat_corpsegibs" in the compatibility menu and/or define it in ZMAPINFO, in GZDoom it will not do anything.

 

It requires the compatibility setting "compat_vileghosts" to also be turned on, which is can only be accessed via the console or via a script (ZScript and possibly ACS). Note that "compat_vileghosts" requires "compat_corpsegibs" to also be turned on to work. You can see in the source code, that vileghosts is typically only added for specific WADS (just search for "vileghosts"). Worst and I figured this out the hard way when developing a pseudo ghost monster script.

There's a menu entry now for compat_vileghosts, in the "actor behavior" section of the compatibility options it's called "Crushed monsters get resurrected as ghosts." I think it's a fairly recent addition, for a long time it was only enabled for specific WADs as you said.

[Arsinikk]

6 hours ago, Shepardus said:

There's a menu entry now for compat_vileghosts, in the "actor behavior" section of the compatibility options it's called "Crushed monsters get resurrected as ghosts." I think it's a fairly recent addition, for a long time it was only enabled for specific WADs as you said.

So technically, yes, this works only if you turn it on in the GZDoom compatibility options or change it in the console... However as a mapper this option is not useful for me because it is impossible to set "compat_vileghosts" via ZMAPINFO, so it's fully on the user to turn it on via the compatibility options instead.

 

The only way I could force it in a map is not through ZMAPINFO (like it should be imo), but only via an ACS script / ZScript changing "compat_vileghosts" to true... Which is kinda lame imo.

[Shepardus]

8 minutes ago, Arsinikk said:

So technically, yes, this works only if you turn it on in the GZDoom compatibility options or change it in the console... However as a mapper this option is not useful for me because it is impossible to set "compat_vileghosts" via ZMAPINFO, so it's fully on the user to turn it on via the compatibility options instead.

 

The only way I could force it in a map is not through ZMAPINFO (like it should be imo), but only via an ACS script / ZScript changing "compat_vileghosts" to true... Which is kinda lame imo. 

I just tried putting compat_vileghosts in a ZMAPINFO and it worked. Seems to have been added to the MAPINFO parser (replacing compat_corpsegibs) last year.

[Arsinikk]

33 minutes ago, Shepardus said:

I just tried putting compat_vileghosts in a ZMAPINFO and it worked. Seems to have been added to the MAPINFO parser (replacing compat_corpsegibs) last year.

I stand corrected, as it does seem to work now. I'm not exactly sure why I thought that it didn't. Maybe I mistook "compat_corpsegibs" not working as "compat_vileghosts", but after some more tests it does in fact work.

 

Sorry about that.

I do think this wiki page should be updated with "compat_vileghosts".

 

Although I will say that I personally probably won't use it, as I look for ways to get ghosts to work in Zandronum and ZDaemon as well. Although it's cool to see that it's now easier to get ghosts working in GZDoom.