Maps that need compatibility settings.

Is there something that doesn't work right in the latest GZDoom? Post about it here.

Moderator: GZDoom Developers

Forum rules
Please construct and post a simple demo whenever possible for all bug reports. Please provide links to everything.

If you can include a wad demonstrating the problem, please do so. Bug reports that include fully-constructed demos have a much better chance of being investigated in a timely manner than those that don't.

Please make a new topic for every bug. Don't combine multiple bugs into a single topic. Thanks!

Re: Maps that need compatibility settings.

Postby Graf Zahl » Wed Dec 12, 2018 11:12 am

No, you cannot just raise the floor in those sectors. The setup is supposed to fake a different light level. This is going to require more work: Raise those sectors to the floor and add a floor light transfer to them. You also have to make sure that this doesn't alter monster movement possibilities too much som some may also require block monster line flags.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Maps that need compatibility settings.

Postby drfrag » Wed Dec 12, 2018 11:50 am

This has happened to me many times, falling into a pit with a monster. I think it cannot happen with infinitely tall monsters, have you tried that map with a different engine?
User avatar
drfrag
I.R developer, I.R smart
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain

Re: Maps that need compatibility settings.

Postby Graf Zahl » Wed Dec 12, 2018 11:51 am

Correct, but some of those pits do not have any monster in them!
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Maps that need compatibility settings.

Postby XxMiltenXx » Wed Dec 12, 2018 11:56 am

So I get some code like this:

Code: Select allExpand view
            OffsetSectorPlane(148, Sector.floor, 1136);
            SetLineFlags(827, Line.ML_BLOCKMONSTERS);
            SetLineFlags(828, Line.ML_BLOCKMONSTERS);
            SetLineFlags(829, Line.ML_BLOCKMONSTERS);
            SetLineFlags(842, Line.ML_BLOCKMONSTERS);
            level.sectors[148].SetPlaneLight(Sector.floor, level.sectors[122].GetLightLevel() - level.sectors[148].GetLightLevel());


This way the sector floor will be raised, then the lines around it will block all the monsters. However, shouldn't flying monsters be excluded somehow?
And then the floor plane of that sector will be darkened to match the surrounding sector.
XxMiltenXx
 
Joined: 08 Jan 2014
Location: Germany
Operating System: Windows 10/8.1/8 64-bit
Graphics Processor: nVidia with Vulkan support

Re: Maps that need compatibility settings.

Postby Graf Zahl » Wed Dec 12, 2018 12:06 pm

I think the sectors I mentioned can be done without the blocking. You only need to do that in areas where it can actually affect monster mobility.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Maps that need compatibility settings.

Postby Player701 » Wed Dec 12, 2018 12:25 pm

XxMiltenXx wrote:"Out of bound nodes"
Out of sector boundaries nodes"

Wow, that looks even worse than Plutonia 2 MAP25. I wonder how bad those node errors can get...
User avatar
Player701
 
Joined: 13 May 2009
Location: Russian Federation
Discord: Player701#8214
Operating System: Windows 10/8.1/8 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Maps that need compatibility settings.

Postby XxMiltenXx » Wed Dec 12, 2018 12:42 pm

So, here's the full code for the compatibility file for darken map 12. I ignored small sectors (line length 16). Concerning blocking some lines I left all unblocked. There are only 2 instances where it changes gameplay.
The hell knight in the bottom left wouldn't be able to walk out of this corner there without the fix:
Stuck Hell Knight.jpg

and these 4 pinkies would be stuck without the fix:
Stuck Pinkies.jpg


Should I add blocking for the corresponding lines or are those changes negeglible?

Code: Select allExpand view
         case '01592ACF001C534076556D9E1B5D85E7': // Darken2.wad map12
         {
            OffsetSectorPlane(126, Sector.floor, 1088);
            level.sectors[126].SetPlaneLight(Sector.floor, level.sectors[125].GetLightLevel() - level.sectors[126].GetLightLevel());
            OffsetSectorPlane(148, Sector.floor, 1136);
            level.sectors[148].SetPlaneLight(Sector.floor, level.sectors[122].GetLightLevel() - level.sectors[148].GetLightLevel());
            OffsetSectorPlane(149, Sector.floor, 1136);
            level.sectors[149].SetPlaneLight(Sector.floor, level.sectors[122].GetLightLevel() - level.sectors[149].GetLightLevel());
            OffsetSectorPlane(265, Sector.floor, 992);
            level.sectors[265].SetPlaneLight(Sector.floor, level.sectors[264].GetLightLevel() - level.sectors[265].GetLightLevel());
            OffsetSectorPlane(279, Sector.floor, 1072);
            level.sectors[279].SetPlaneLight(Sector.floor, level.sectors[267].GetLightLevel() - level.sectors[279].GetLightLevel());
            SetSectorTexture(279, Sector.floor, "OMETL13");
            OffsetSectorPlane(280, Sector.floor, 1072);
            level.sectors[280].SetPlaneLight(Sector.floor, level.sectors[267].GetLightLevel() - level.sectors[280].GetLightLevel());
            SetSectorTexture(280, Sector.floor, "OMETL13");
            OffsetSectorPlane(281, Sector.floor, 1072);
            level.sectors[281].SetPlaneLight(Sector.floor, level.sectors[267].GetLightLevel() - level.sectors[281].GetLightLevel());
            SetSectorTexture(281, Sector.floor, "OMETL13");
            OffsetSectorPlane(292, Sector.floor, 1056);
            level.sectors[292].SetPlaneLight(Sector.floor, level.sectors[291].GetLightLevel() - level.sectors[292].GetLightLevel());
            OffsetSectorPlane(472, Sector.floor, 1136);
            level.sectors[472].SetPlaneLight(Sector.floor, level.sectors[216].GetLightLevel() - level.sectors[472].GetLightLevel());
            OffsetSectorPlane(473, Sector.floor, 1136);
            level.sectors[473].SetPlaneLight(Sector.floor, level.sectors[216].GetLightLevel() - level.sectors[473].GetLightLevel());
            OffsetSectorPlane(526, Sector.floor, 1024);
            level.sectors[526].SetPlaneLight(Sector.floor, level.sectors[525].GetLightLevel() - level.sectors[526].GetLightLevel());
            OffsetSectorPlane(527, Sector.floor, 1024);
            level.sectors[527].SetPlaneLight(Sector.floor, level.sectors[500].GetLightLevel() - level.sectors[527].GetLightLevel());
            OffsetSectorPlane(528, Sector.floor, 1024);
            level.sectors[528].SetPlaneLight(Sector.floor, level.sectors[525].GetLightLevel() - level.sectors[528].GetLightLevel());
            OffsetSectorPlane(554, Sector.floor, 1024);
            level.sectors[554].SetPlaneLight(Sector.floor, level.sectors[500].GetLightLevel() - level.sectors[554].GetLightLevel());
            OffsetSectorPlane(588, Sector.floor, 928);
            level.sectors[588].SetPlaneLight(Sector.floor, level.sectors[587].GetLightLevel() - level.sectors[588].GetLightLevel());
            OffsetSectorPlane(604, Sector.floor, 1056);
            level.sectors[604].SetPlaneLight(Sector.floor, level.sectors[298].GetLightLevel() - level.sectors[604].GetLightLevel());
            OffsetSectorPlane(697, Sector.floor, 1136);
            level.sectors[697].SetPlaneLight(Sector.floor, level.sectors[696].GetLightLevel() - level.sectors[697].GetLightLevel());
            OffsetSectorPlane(698, Sector.floor, 1136);
            level.sectors[698].SetPlaneLight(Sector.floor, level.sectors[696].GetLightLevel() - level.sectors[698].GetLightLevel());
            OffsetSectorPlane(699, Sector.floor, 1136);
            level.sectors[699].SetPlaneLight(Sector.floor, level.sectors[696].GetLightLevel() - level.sectors[699].GetLightLevel());
            OffsetSectorPlane(700, Sector.floor, 1136);
            level.sectors[700].SetPlaneLight(Sector.floor, level.sectors[696].GetLightLevel() - level.sectors[700].GetLightLevel());
         }


Player701 wrote:Wow, that looks even worse than Plutonia 2 MAP25. I wonder how bad those node errors can get...


This is just how I named it, but from the pictures provided you can guess why I named it like that. Dunno if those bad nodes actually affect gameplay or not.
XxMiltenXx
 
Joined: 08 Jan 2014
Location: Germany
Operating System: Windows 10/8.1/8 64-bit
Graphics Processor: nVidia with Vulkan support

Re: Maps that need compatibility settings.

Postby Player701 » Thu Dec 13, 2018 12:48 pm

Another BSP glitch in Plutonia 2, this time in MAP29:

Code: Select allExpand view
gzdoom.exe -iwad plutonia -file pl2.wad -warp 29 -nomonsters +"warp -3906 -1628"

The player ends up slightly below the floor level, which prevents them from getting to the teleporter without jumping. This is again due to a subsector errouneously referencing the wrong sector (749 instead of 783), and is probably caused by sector 749 having overlapping lines. Rebuilding nodes does seem to fix the issue, however, so I'm providing another PR to fix this.
User avatar
Player701
 
Joined: 13 May 2009
Location: Russian Federation
Discord: Player701#8214
Operating System: Windows 10/8.1/8 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Maps that need compatibility settings.

Postby Player701 » Thu Dec 20, 2018 11:45 am

So I was playing Alien Vendetta MAP28, and by the end of the map I was 1 item short of getting 100% items. It turned out to be a soulsphere in a secret area that can't be reached by normal means, at least in GZDoom. While doing some research on this, I stumbled upon this thread, and it turns out the cause of the problem is that the soulsphere's center is located directly on a line between two sectors with different heights. So I thought, why not just move the soulsphere slightly to get rid of this problem? This PR moves the soulsphere's position to the center of the "window" sector in that secret area and makes it reachable again.

Test with the following command-line parameters (Get Alien Vendetta here):

Code: Select allExpand view
gzdoom -file av.wad -nomonsters -warp 28 +"warp -884 48"

and turn 90 degrees left as soon as the level starts.

Maybe I should also fix this for the old release? It looks like this map was changed in the second release, and, AFAIK, the first release is still around somewhere, so if you think I should fix it for the old version too, I will change the PR.

Also, that thread I linked above mentions MAP10 of the same WAD as well, but I'm not sure if there's anything wrong with that map (played through it myself a few days ago and everything was fine). If anyone knows of any problems with MAP10, please post more info abut it. Thanks :)
User avatar
Player701
 
Joined: 13 May 2009
Location: Russian Federation
Discord: Player701#8214
Operating System: Windows 10/8.1/8 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Maps that need compatibility settings.

Postby Graf Zahl » Thu Dec 20, 2018 12:02 pm

Good find. Back then the compatibility system wasn't sufficiently refined to handle this case.
This is another of those WADs that was made in the source port area by die-hard vanilla users and shows several issues with ports as a result.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Maps that need compatibility settings.

Postby Player701 » Wed Mar 20, 2019 1:58 pm

MAP17 of Unholy Realms might need some kind of compatibility setting to fix a glitch with a pseudo-3D bridge. Here are the command-line parameters to experience the glitch:

Code: Select allExpand view
gzdoom.exe -iwad doom2 -file ur_final.wad -nomonsters -warp 17 +"warp 8780 -155"

Walk towards the bridge to activate it, and you'll see this:


This glitch is not OpenGL-exclusive. The bridge doesn't look right in software as well; however, the glitch manifests differently:


Same area in PrBoom+:
User avatar
Player701
 
Joined: 13 May 2009
Location: Russian Federation
Discord: Player701#8214
Operating System: Windows 10/8.1/8 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Maps that need compatibility settings.

Postby Graf Zahl » Wed Mar 20, 2019 2:26 pm

I'm a bit confused how PrBoom manages not to mess this one up. The setup for this bridge shouldn't really work at all...
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Maps that need compatibility settings.

Postby Killer5 » Thu Mar 21, 2019 4:21 am

gzdoom version: 3.7.2 Windows modern, 64-bit
wad: miasma map01
bug location: immediately after picking up the soulsphere and starting the green key fight in the secret western area
bug location screenshot: https://www.dropbox.com/s/pqc6qgbhy7d0r ... n.png?dl=0 (see yellow square in left side of screenshot)

bug description:
In the far west green key fight area in the wad green midtextures? appear to be around normally exposed monsters. This happens on both the boom and boom (strict) compatibility presets. This does not happen using the default or the zdoom 2.0.63 presets.

bug screenshot: https://www.dropbox.com/s/69mz4atgu093z ... g.png?dl=0
Killer5
 
Joined: 02 Dec 2018
Twitch ID: mrzzul

Re: Maps that need compatibility settings.

Postby Killer5 » Fri Mar 22, 2019 10:00 am

gzdoom version: 3.7.2 Windows modern, 64-bit
wad:sunlust map30
bug location: immediately after starting the map and heading towards the first accessible area with the rocket launcher
bug location screenshot: https://www.dropbox.com/s/6zy0xxkm2a7vh ... n.png?dl=0

bug description:
During the start of the map many monsters are killed in monster closets and then teleported into playable space in order to be resurrected later. The monsters in the area in the yellow square should all be dead at the start of the map. These monsters should be dead until acquiring the rocket launcher however the monsters are alive upon initial arrival to the area in the yellow square when using the Boom (strict) compatibility preset.

This bug does not appear to happen when using the Boom compatibility preset.
Killer5
 
Joined: 02 Dec 2018
Twitch ID: mrzzul

Re: Maps that need compatibility settings.

Postby Killer5 » Sat Mar 23, 2019 4:42 am

gzdoom version: 3.7.2 Windows modern, 64-bit
wad: sunlust map25
bug location: rev hallway just after finishing the east fight
bug location screenshot: https://www.dropbox.com/s/e89udr798ggyx ... n.png?dl=0

bug description:
There appears to be an issue with the fake 3d effects used in this map. The bug appears in boom and boom (strict) compatibility presets but does not appear in the default or zdoom 2.0.63 presets.

bug screenshot: https://www.dropbox.com/s/blmn040cbzktg ... g.png?dl=0
Killer5
 
Joined: 02 Dec 2018
Twitch ID: mrzzul

PreviousNext

Return to Bugs

Who is online

Users browsing this forum: No registered users and 28 guests