How do I make a boom map GZDoom incompatible?

[RataUnderground]

Hello everybody. This is a fun question.

Do any of you know a way to make a perfectly fine boom wad that runs in PrBoom, Woof, etc... but not at all in GzDoom? I need this information for scientific research. I saw that the early iterations of kdikndidz were not compatible with GzDoom due to Mikoportals, but maybe there is more vanilla or boom niche things that break compatibility.

[SMG_Man]

You've probably learned that it's possible to make a simple invisible barrier that blocks projectiles and bullets by making a thin sector, raising its floor to just below the ceiling, and leaving its lower sides untextured. It has a lot of uses in vanilla doom, where you can't simply set a line to "block everything".

 

However, this can be taken further - if the barrier is made into a self-referencing sector, then while it will still block projectiles, it will no longer block line-of-sight checks or hitscan attacks... in less advanced engines. blocking_walls.zip In this WAD, there are three different types of blocking walls. In Chocolate Doom, Crispy Doom, and DSDA-Doom, the middle wall is a self-referencing sector and works as described above. If opened in GZDoom, it will still block hitscan attacks.

 

 

My apologies, I was unaware this behavior had a compatibility flag in GZDoom.

Edited November 21, 2022 by SMG_Man

[Doomy__Doom]

20 minutes ago, SMG_Man said:

In Chocolate Doom, Crispy Doom, and DSDA-Doom, the middle wall is a self-referencing sector and works as described above. If opened in GZDoom, it will still block hitscan attacks. 

GZDoom has a compatibility setting - compat_trace - which is enabled on Boom/Boom(strict) compat. Incorrect choice of compatibility is a player issue.

 

As to OP, Generalized Crushers are broken in Boom and, by extension, compatibility-oriented source ports but are fixed in GZDoom, afaik with no option to change that behavior.

gen_crusher.zip should kill the player in GZDoom +compat_mode 3/6 and do nothing in -cl9 in DSDA/Woof/Pr+.

[SMG_Man]

31 minutes ago, Doomy__Doom said:

GZDoom has a compatibility setting - compat_trace - which is enabled on Boom/Boom(strict) compat. Incorrect choice of compatibility is a player issue.

 

wow, I stand corrected then; my bad

[Pegleg]

47 minutes ago, Doomy__Doom said:

GZDoom has a compatibility setting - compat_trace - which is enabled on Boom/Boom(strict) compat. Incorrect choice of compatibility is a player issue.

 

As to OP, Generalized Crushers are broken in Boom and, by extension, compatibility-oriented source ports but are fixed in GZDoom, afaik with no option to change that behavior.

gen_crusher.zip should kill the player in GZDoom +compat_mode 3/6 and do nothing in -cl9 in DSDA/Woof/Pr+.

 

That would be an interesting way to troll GZDoom users. Make the ceiling of the entrance room a generalized crushing ceiling, and include a customer texture on the walls that says "If you weren't using GZDoom, you'd be alive now."

 

Why you would want to do this is a different question, but it would be interesting to see what sort of vitriol would be directed your way for trying it.

[MFG38]

With a 6-digit linedef count.

[Ar_e_en]

I know that Eviternity has Zscript code that generates specific particles in certain maps (portal particles, snow, etc.). This code is only executed on ZDoom based ports, while other ports just ignore it. I wouldn't be surprised if you could code up a script in Zscript that just kicks you out into the menu screen upon map load (or it just kills you 1 second after the map is loaded).

[JadingTsunami]

This may not be exactly what you're looking for, but you can easily make a Vanilla or Boom compatible map practically unplayable in stock GZDoom by exploiting the fact that GZDoom uses more accurate floating point comparisons than the other ports (edit: by default, that is; there are compatibility settings for this).

 

Take the example of the attached WAD.

 

Play in GZDoom and the player is quickly killed.

 

Play in Boom/Vanilla and the player is safe.

teleport.zip

Edited November 21, 2022 by JadingTsunami

[Ravendesk]

It's much harder to make a Boom map that works properly in GZ than make a map that breaks it.

 

[Graf Zahl]

 

4 hours ago, Doomy__Doom said:

As to OP, Generalized Crushers are broken in Boom and, by extension, compatibility-oriented source ports but are fixed in GZDoom, afaik with no option to change that behavior.

 

 

There is no option because no actual map outside of test cases needs it.

Needless to say, once a map pops up that depends on Boom's broken crusher implementation that option will be added.

 

But there's really no point adding new options for things that have no practical use.

 

[Nikku4211]

7 hours ago, Doomy__Doom said:

As to OP, Generalized Crushers are broken in Boom and, by extension, compatibility-oriented source ports but are fixed in GZDoom, afaik with no option to change that behavior.

Fun fact: Older versions of Boom like Boom 2.01 actually have working generalised crushers.

 

[ChopBlock223]

7 hours ago, Ravendesk said:

It's much harder to make a Boom map that works properly in GZ than make a map that breaks it.

Never had a problem with that.

 

2 hours ago, Nikku4211 said:

Fun fact: Older versions of Boom like Boom 2.01 actually have working generalised crushers.

 

And then they were left broken for years and years, for whatever reason.

[RataUnderground]

13 hours ago, Ravendesk said:

It's much harder to make a Boom map that works properly in GZ than make a map that breaks it.

 

C'mon , thats a myth. GzDoom does a good work being compatible with pretty much anything. The only downside its that the user have a lot of agency about how to play the map despite the original intentions of the designer.

 

Thanks for all the responses!

[Nine Inch Heels]

6 minutes ago, RataUnderground said:

C'mon , thats a myth. GzDoom does a good work being compatible with pretty much anything. The only downside its that the user have a lot of agency about how to play the map despite the original intentions of the designer.

 

Thanks for all the responses!

It's not a myth per se... It used to be really hard to get identical behaviour out of for example scrolling floors across different ports. If your map ended up depending on very particular scrolling speeds, or unusual angles for your scrollers, then the discrepancies between PrB+/DSDA-doom and the ZDoom family of ports could result in problems including but not limited to softlocks.

[Graf Zahl]

The reason for that is, however, that Boom's scroller implementation is pretty poor, apparently conceived by trial and error until it worked. Try to refine your math and it will show off some problems.

There is one compatibility option for the most obvious difference, i.e. Boom's scrollers are additive when an item is on the boundary, while ZDoom's are averaging. For this one a compatibility option exists.

 

But you are clearly exaggerating. Most Boom maps never run into these edge cases - you have to try really hard to do odd things to encounter compatibility problems.

 

 

 

[Dexiaz]

@RataUnderground, Boom doesn't support ACS scripting as far as I know. But GZDoom does (of course it does, this is the one of the main features of the sourceport).

 

You can create an easy ACS script which doesn't allow player to play this map on GZDoom (even show the message about this).

 

Or, at least, ask for help to create this script if you're not into coding.

[Gez]

52 minutes ago, Dexiaz said:

You can create an easy ACS script which doesn't allow player to play this map on GZDoom (even show the message about this).

Sure, if you want to passive-aggressively use GZDoom features to break the map when playing it on a GZDoom-compatible port, it's quite easy. You could provide a ZMAPINFO file that unsets the player 1 start, for example. Then you can't play any map at all because you'll get the error message about no player 1 start...

DoomEdNums
{
    1 = None
}

Alternatively, for a different definition of "unplayable", you could replace this way every thing except the player starts with arch-viles -- including weapons, keys, teleport destinations...

 

But the OP was about using Boom features only, I think. Breaking compatibility is about changing the way the game works, and so using GZDoom-specific features to change the way the game works in GZDoom is cheating.

[Ravendesk]

4 hours ago, RataUnderground said:

C'mon , thats a myth. GzDoom does a good work being compatible with pretty much anything. The only downside its that the user have a lot of agency about how to play the map despite the original intentions of the designer.

 

Thanks for all the responses!

Well, I mean, every boom/mbf wad that I made and even some unfinished ones required me to write (or to copypaste, lol, because someone already had these issues) a custom decorate or custom zscript just to make maps playable in gz as well. Gz just doesn't work properly once you start doing more gimmicky or niche stuff.

 

Refer here for an incomplete list of what's not working as intended: 

 

 

The more your map relies on the exact behavior, the more likely it is to require a gz specific workaround.

Edited November 22, 2022 by Ravendesk

[CatWithAComputer]

2 hours ago, Gez said:

Sure, if you want to passive-aggressively use GZDoom features to break the map when playing it on a GZDoom-compatible port, it's quite easy. You could provide a ZMAPINFO file that unsets the player 1 start, for example. Then you can't play any map at all because you'll get the error message about no player 1 start...

DoomEdNums
{
    1 = None
}

Alternatively, for a different definition of "unplayable", you could replace this way every thing except the player starts with arch-viles -- including weapons, keys, teleport destinations...

 

But the OP was about using Boom features only, I think. Breaking compatibility is about changing the way the game works, and so using GZDoom-specific features to change the way the game works in GZDoom is cheating.

I was going to suggest that.

[Kinsie]

The easiest way is to just not release it. That way its precious fluids will never be tainted by the unjust.

[ViolentBeetle]

On the subject of map-breaking compatibility issues you didn't see it coming, here's one. Put a decoration on a scroller with low ceiling (16 units tall sector) and make it open critical door.

In Boom all decorations are 16 units tall, but in GZDoom they are as tall as their sprites suggests. It's hardly ever relevant, except here.

Probably fixed by fiddling with compatibility, but good luck figuring it out.

Edited November 22, 2022 by ViolentBeetle

[RataUnderground]

28 minutes ago, ViolentBeetle said:

On the subject of map-breaking compatibility issues you didn't see it coming, here's one. Put a decoration on a scroller with low ceiling (16 units tall sector) and make it open critical door.

In Boom all decorations are 16 units tall, but in GZDoom they are as tall as their sprites suggests. It's hardly ever relevant, except here.

Probably fixed by fiddling with compatibility, but good luck figuring it out.

 

Uh? How do you make a decoration to open a door? 

Edited November 22, 2022 by RataUnderground

[CFWMagic]

You could try and do the HDoom approach. HDoom will scan the game for specific classes (BrutalDoomer in this case) and if it finds them, it will summon legions of revenants while making the player near blind. How can we implement this? Have a DECORATE file that creates a new player class while inheriting from the original one. Then have a script which will scan for the name of the class that you've just created and will torment the player in your chosen way.

Since the likes of DSDA-Doom or PrBoom+ obviously don't support decorate, the new player class won't exist there, nor will the tormentor script fire. But in GZDoom ...

This'll have a side effect of also excluding Skulltag, which probably is not going to be much of a bother considering the task you presented.

EDIT: Though I suppose, this will be cheating as well since you'll be using GZDoom specific features to punish GZDoom in the first place.

The only other idea I have is have your map rely on some kind of glitch that is by default fixed in GZDoom. Such as have the start of your map rely on a keygrab through a fence or something. But then again, GZDoom might have compat-settings which'll render that moot (Don't know, didn't dig into GZDoom's compat settings as I don't use it if I actually need compat).

Edited November 22, 2022 by CFWMagic

[Kain D.]

I tend to break sourceports, so I know a few.

1. High scrolling and wind/current speed

Basically from what I understand Boom has limitation how fast a player will be pushed from these effects.
In my experience everything above 700 map units will break compability. This is much more visible with wind/current, than scrolling.
Strangely enabling wall run as compatibility setting restores original behavior, but unlike other compat setting, it cannot be set in mapinfo.

2. Already mentioned generalized crushers

I only add, that it only applies to walkover ones. So there is still a way of using them.

3. White colormap in Fake sectors (hardware renderer only)

It doesn't work at all.

4. Self-referencing sector

On 11/21/2022 at 5:19 PM, SMG_Man said:

You've probably learned that it's possible to make a simple invisible barrier that blocks projectiles and bullets by making a thin sector, raising its floor to just below the ceiling, and leaving its lower sides untextured. It has a lot of uses in vanilla doom, where you can't simply set a line to "block everything".

 

However, this can be taken further - if the barrier is made into a self-referencing sector, then while it will still block projectiles, it will no longer block line-of-sight checks or hitscan attacks... in less advanced engines. blocking_walls.zip In this WAD, there are three different types of blocking walls. In Chocolate Doom, Crispy Doom, and DSDA-Doom, the middle wall is a self-referencing sector and works as described above. If opened in GZDoom, it will still block hitscan attacks.

 

 

My apologies, I was unaware this behavior had a compatibility flag in GZDoom.

 

The compat flag does not take BFG (or more precisely BFG tracers) into consideration. It means Gzdoom will block BFG completly, unlike other sourceports.

 

5. Activating generalized walkover floor/ceiling with monster projectile

 

Certain monsters can activate (like Revenant missile) numeric type (without texture change) generalized walkover floor/ceiling linedefs.

 

40 minutes ago, RataUnderground said:

Uh? How do you make a decoration to open a door? 

 

The same way I mentioned above(by putting decoration on a scroller).

 

[RataUnderground]

3 minutes ago, Kain D. said:

5. Activating generalized walkover floor/ceiling with monster projectile

 

Certain monsters can activate (like Revenant missile) numeric type (without texture change) generalized walkover floor/ceiling linedefs.

 

 

The same way I mentioned above(by putting decoration on a scroller).

 

Yeah? and then? If you put a decoration on a scroller, how did that open a door? The walk line actions only take account for the player.

[ViolentBeetle]

3 minutes ago, RataUnderground said:

Yeah? and then? If you put a decoration on a scroller, how did that open a door? The walk line actions only take account for the player. 

Generalized door actions can be set to be usable by monsters. Decorations are part of it.

[TheHambourgeois]

I guess make some zscript that spawns a bunch of revenants everywhere:

https://www.youtube.com/watch?v=nCF5f0hSfKg

 

[Bauul]

4 hours ago, Ravendesk said:

Well, I mean, every boom/mbf wad that I made and even some unfinished ones required me to write (or to copypaste, lol, because someone already had these issues) a custom decorate or custom zscript just to make maps playable in gz as well.

 

Arguably that's within the standard scope of GZDoom.  Even GZDoom-targted maps require additional coding to reliably work the same way for everyone because of the sheer variety of different user-settings available (set your MAPINFO compat-settings people!)

[Ravendesk]

3 minutes ago, Bauul said:

 

Arguably that's within the standard scope of GZDoom.  Even GZDoom-targted maps require additional coding to reliably work the same way for everyone because of the sheer variety of different user-settings available (set your MAPINFO compat-settings people!)

True in case of settings, but let me show you a zscript from Thirty Monsters Challenge wad just to demonstrate my point:

Spoiler

// Patch script (v2) for 30mc MAP60

class CustomLevelProcessor : LevelPostProcessor
{
    protected void Apply(Name checksum, String mapname)
    {
		// Check mapchecksum for '30mc beta 04.wad' MAP60 by antares031
        if(checksum == '426EAB47480B6F402E59515DD7395B2D')
        {
			CVar enable_patch = CVar.FindCVar('patch_30mc_map60');
			if (!enable_patch) return;
			if (enable_patch.GetBool() == false) return;
			
			// Uncomment only for testing
			//SetThingXY(98, 4192.0, -8768.0); //Test 1st track
			//SetThingXY(98, 6912.0, -8832.0); //Test 2nd track
			//SetThingXY(98, 9088.0, -8672.0); //Test 3rd track
			
			
			// Starting arena
			
			// Add custom sector actions that slow down projectiles.
			AddThing(12310, (-6240.0, -1440.0, 0.0), 0, SKILLS_ALL, MODES_ALL); //Sector 35
			AddThing(12310, (-6240.0,   512.0, 0.0), 0, SKILLS_ALL, MODES_ALL); //Sector 37
			
			AddThing(12310, (-4960.0, -1440.0, 0.0), 0, SKILLS_ALL, MODES_ALL); //Sector 30
			AddThing(12310, (-4960.0,   512.0, 0.0), 0, SKILLS_ALL, MODES_ALL); //Sector 33
			
			//Adjust scrolling direction of tag 203
			SetVertex(768, -4928.0, -3648.0);
			
			//Adjust scrolling direction of tag 103
			SetVertex(781, -4928.0, -4864.0);
			
			//Disable these line specials, so rockets don't get stuck in a loop.
			SetLineSpecial(1035, 0);
			SetLineSpecial(1038, 0);
			
			
			// 1st Track
			
			// Move vertex to decrease linedef 13694 to a length of 1152.
			SetVertex(12073, 3584.0, -10368.0); 
			// Scroll instead of Wind, as fast wind doesn't quite work the same in GZDoom.
			SetLineSpecial(13694, Scroll_Floor, 31, 4, 1);
			// Reduce wind speed on the ramp.
			SetLineSpecial(14789, Sector_SetWind, 33, 512, 64);
			
			// Make the ramp lower by removing steps from the end.
			//OffsetSectorPlane(302, Sector.floor, -112);
			//OffsetSectorPlane(303, Sector.floor, -136);
			OffsetSectorPlane(304, Sector.floor, -160);
			OffsetSectorPlane(305, Sector.floor, -184);
			OffsetSectorPlane(301, Sector.floor, -200);
			
			
			// 2nd Track
			// Move vertex to decrease linedef 15000 to a length of 1088.
			SetVertex(13282, 5824.0, -10304.0); 
			SetLineSpecial(15000, Scroll_Floor, 34, 4, 1); 
			
			
			// 3rd Track
			// Move vertex to increase linedef 17296 to a length of 1344.
			SetVertex(15318, 8448.0, -10560.0);
			SetLineSpecial(17296, Scroll_Floor, 48, 4, 1);
			
			
			// Replace decorations with +NOGRAVITY variants, so that they
			// don't get moved by the floors that were changed to scrollers.
			for(int i = 0; i < GetThingCount(); i++)
			{
				int ednum = GetThingEdNum(i);
				switch(ednum)
				{
					case 34: SetThingEdNum(i, 12301); break; //Candlestick
					case 44: SetThingEdNum(i, 12302); break; //BlueTorch
					case 55: SetThingEdNum(i, 12303); break; //ShortBlueTorch
					case 57: SetThingEdNum(i, 12304); break; //ShortRedTorch
					case 2028: SetThingEdNum(i, 12305); break; //Column
				}
			}
			
			Console.Printf("Patch loaded for 30mc MAP60.");
        }
    }
}

class SecActHalfVelocity : SectorAction
{
	override bool TriggerAction (Actor triggerer, int activationType)
	{
		if (activationType & SECSPAC_Enter)
		{
			triggerer.A_ScaleVelocity(0.5);
		}
		return false;
	}
}

 

 

That's what was needed to do just to make a certain mbf21 map to work properly in GZ :)

[Nine Inch Heels]

6 hours ago, Graf Zahl said:

Most Boom maps never run into these edge cases - you have to try really hard to do odd things to encounter compatibility problems.

If it does indeed happen, then it's not an exaggeration but a statement of fact.

 

One such "edge case" that caused a fair bit of frustration for an entire team of mappers and playtesters was eviternity with its looping scrollers, and it's safe to say that nobody on that team tried real hard to make their maps incompatible with either source port, on the contrary: They went to great lengths to ensure their maps were 100% completable on both GZDoom and PrB+ despite the obviously different port-behaviour. People don't have to try real hard to produce discrepancies, they just happen, and, in eviternity's case, people had to pour hours of their spare time into that project in order to find a solution for a problem that you claim happens only on the eleventyfirst of nevervember...

 

You are plain and simple out of touch. These issues are way more common than you think. Most of the time, especially when it's an ambitious project, people take care of those problems behind closed doors, before a build is made public. And if it wasn't for stuff like this, you could probably count the number of people who know how to map around those aforementioned discrepancies reliably on one hand. The fact that GZDoom is perceived as reliable as it seems to be is owed first and foremost to the efforts of mappers and playtesters, who are going the extra mile to ensure compatibility across different ports when they can.