Maps that need compatibility settings.

[Graf Zahl]

(btw: Why?).

Why what? It's a non-repeatable action so it can only be triggered once. The setup is broken. I currently have no idea how to properly fix it without breaking the intent of this design.

[Player701]

E4M7 of 007: Licence to Spell DooM is impossible to complete because the walkover exit trigger (linedef #6842) is marked as impassable. I have no idea if this setup ever worked, but I guess it could have been the case with ancient ZDoom versions (I've run into problems trying to run them on my system so can't check right now). I'm a bit tired to make a PR today, will probably submit one tomorrow unless someone else does it before then.

Upd: PR submitted

[JPL]

Was playing the Master Levels semi-recently and encountered an issue in BLACKTWR.WAD (7CE7BCC9D6EB983416A21B2300229111) that trapped an imp in a tiny sliver-shaped sector after the big spiral stairs rise up in the interior of the tower - thus making 100% kills impossible. I tried adding the "block monsters" flag to line 597 to prevent the imp from ever even touching this tiny sector, and couldn't repro it after that, but it's a tricky one to repro anyways. I can't think of any reason why that change would break anything, but I leave it up to yall.

[brick]

I have a couple of them from Heretic pwads.

HUMP E2M2.

HUMP.jpg

This is a zoom-in from the eastern side of the map. Linedef #4425 highlighted with the red circle is a switch that's supposed to build stairs on tag 54 (not sure why it displays special 127 as unknown, I could've sworn SLADE was recognizing it last time I checked). Sector #673 highlighted near the top right is the target, and when the switch is pressed sectors 673 to 679 al raise to make the artifact in sector #680 accessible. This will ONLY work if "use buggier stair building" is set to OFF. Once I saw this bug I kept the compat flag on off for the rest of the wad so I'm not sure if other maps are also affected.

Heretic Treasure Chest E3M8.

HTC.jpg

The switch at linedef #8156 lowers the highlighted sectors, which does 2 things: it opens up access to D'Sparil in the central square, and traps you in that lower arena when you drop down. Killing D'Sparil is supposed to raise the sectors in such a way to allow you to get back up and to the exit that also opens up when you kill him. This works in Doomsday (the other port targeted by HTC) but not in GZDoom 4.7.1. I have no idea how to fix it, none of the compat flags I tried helped. I'm not even sure this is how it works in vanilla, since Heretic IWAD's E3M8 doesn't have a similar situation, but it does work in Doomsday and as far as I can tell nothing in DD changes the code for D'Sparil's death.

[Graf Zahl]

That HUMP map works fine for me with default compatibility.

The problem with HTC looks like it does not use the correct death action for D'Sparil.
Heretic uses specialaction_lowerfloortohighest, but HTC uses specialaction_lowerfloor. Apparently this is enough to break this map.

[brick]

That HUMP map works fine for me with default compatibility.

Yeah, Default compatibility has "use buggier stair building" off so it'll work fine there. Is it still worth forcing it off since the wrong setting can break the action, or is this kind of fix beyond the scope of level_compatibility?

The problem with HTC looks like it does not use the correct death action for D'Sparil.
Heretic uses specialaction_lowerfloortohighest, but HTC uses specialaction_lowerfloor. Apparently this is enough to break this map.

You're absolutely right, I changed the specialction in HTC's MAPINFO and it works like a charm. Thanks!
Can Zscript even apply changes to a MAPINFO specialaction or would this not be possible to fix without a more involved hack?

[Graf Zahl]

The general rule of compatibility settings is to assume everything being off. Otherwise we'd have to add tons of settings for specific maps.

For the second case, this one would require a new handler - but it still makes me wonder how this went undetected when the mod was tested.

[brick]

The general rule of compatibility settings is to assume everything being off. Otherwise we'd have to add tons of settings for specific maps.

Thanks for the clarification, that makes sense. I'll keep this in mind for future compatibility reports.

[Player701]

A little follow-up to the recently closed PR with various fixes for Congestion 1024: are we ruling out nodebuilder glitches now too? As far as I remember, there were never any complaints about submitting fixes to those. I'm asking because the PR included such a fix for MAP02, and it wasn't added. The glitch in question is easily found during normal play, since it is located near the exit area and manifests in the form of an invisible obstacle. IMO, it should be fixed to provide a smoother gameplay experience without having the user to enable node rebuilding manually (most of them don't even know that the engine has such a feature in the first place).

[Gez]

You can force a node rebuild for a level in the automatic compatibility files, yes.

[Player701]

You can force a node rebuild for a level in the automatic compatibility files, yes.

I'm aware of that... the question was whether such fixes are accepted anymore or not. Graf added the MAP05 fix from my PR (which fixes a duplicate player start thing) but not the MAP02 fix.

[Graf Zahl]

Looks I missed that in the wall of code. Everything that results in buggy behavior or obvious deviation of other ports should be addressed, but if some item does not count in other ports, there's really no reason to address that. Things like these can quickly bloat the file to unwieldy proportions.

[Player701]

OK, here you go then.

[brick]

A couple of maps from NJ Doom have nodebuilding problems, I'm listing them here. Many maps are recycled in njdoom.wad and njdoom2.wad, when the problem appears in one it appears in the other. There may more maps but these are the ones I've noticed and where it's very conspicuous:

D04E38921EC29D8665EA4F019F9921E5 // njdoom1.wad e1m6
A139B45A843E26EAAFBE88093723D795 // njdoom2.wad map13
Can be seen in the long E to W corridor (noclip and go north from the start to get there quickly)

EB61E33DDB0BABA174DF2D4C06E5536E // njdoom1.wad e3m4
718D80A751F33558EDB0315668FDCD7F // njdoom2.wad map23
Very obvious with the cacos in the starting room flickering in and out of existence.

[Rachael]

Since the author of those maps is very much active to this day on the forum I'm gonna let him look at this and respond first to see if he plans any updates, before I add these hashes.