ZDoom

From what I can see those seemed to work, so I've gone ahead and pushed it.

5E3FCFDE78310BB89F92B1626A47D0AD // heretic.wad E4M7
{
	// Missing textures
	setwalltexture 1274 front top CSTLRCK
	setwalltexture 1277 back top CSTLRCK
	setwalltexture 1278 front top CSTLRCK
}

Well, so:

[code]
5E3FCFDE78310BB89F92B1626A47D0AD // heretic.wad E4M7
{
// Missing textures
setwalltexture 1274 front top CSTLRCK
setwalltexture 1277 back top CSTLRCK
setwalltexture 1278 front top CSTLRCK
}
[/code]

The two errors were that the lines array had been moved into the LevelInfo struct for better scripting access and that this needs textures.h included.

				case CP_SETWALLTEXTURE:
				{
					if (CompatParams[i + 1] < numlines)
					{
						side_t *side = lines[CompatParams[i + 1]].sidedef[CompatParams[i + 2]];
						if (side != NULL)
						{
							assert(TexNames.Size() > (unsigned int)CompatParams[i + 4]);
							const FTextureID texID = TexMan.GetTexture(TexNames[CompatParams[i + 4]], FTexture::TEX_Any);
							side->SetTexture(CompatParams[i + 3], texID);
						}
					}
					i += 5;
					break;
				}

Well - I failed to take into account the refactoring of the texture and video and level code that occurred after the QZDoom merge took place. As such, this block of code now points effectively to blank space in the source, and fails to compile:
[code] case CP_SETWALLTEXTURE:
{
if (CompatParams[i + 1] < numlines)
{
side_t *side = lines[CompatParams[i + 1]].sidedef[CompatParams[i + 2]];
if (side != NULL)
{
assert(TexNames.Size() > (unsigned int)CompatParams[i + 4]);
const FTextureID texID = TexMan.GetTexture(TexNames[CompatParams[i + 4]], FTexture::TEX_Any);
side->SetTexture(CompatParams[i + 3], texID);
}
}
i += 5;
break;
}[/code]

For the past 30+ minutes, I've been trying in vain to figure out what changed in the code in order to update this, but there's simply too much git history to review and I am a bit lost. Will probably need the person who did this refactoring in the first place in order to refactor this subsection to the new base.

EDIT: I see you already did it.

Did you test that? It still had a few compile errors.

And done - https://github.com/coelckers/gzdoom/pull/313 - I would suggest both of you review it to make sure I did it right - but it should work.

I've gone ahead and did a git fetch on his repo.

I will do a checkout on the branch directly and then rebase on master into yet another new branch, and fixing conflicts as needed - in essence just updating his branch to the newest GZDoom base. If I am successful, I'll create a pull request for you to review and then you can merge it if you want.

Let's at least include those fixes you already made. What's the best way to get them in with an overlong side branch that makes this hard to track?

I think it is.

A while ago I tried to do similar things for all Heretic visual glitches mentioned in DoomWiki.
Fixed a few levels but then switched to something else and completely forgot about it.
[url=https://github.com/alexey-lysiuk/gzdoom/commits/compat_cosmetic]That branch[/url] is still there although I'm not sure that it's worth the effort to fix them all.

Sure, if this can be fixed, let's fix it.

5E3FCFDE78310BB89F92B1626A47D0AD // heretic.wad E4M7
{
	sideuptex 1948 CSTLRCK
	sideuptex 1955 CSTLRCK
	sideuptex 1956 CSTLRCK
}

E4M7: Ramparts of Perdition suffers from a visual glitch because the upper sidedefs for sidedefs 1948, 1955, and 1956 are untextured. On the other side of the room, the mirror structure uses CSTLRCK on sidedefs 1932, 1941, and 1942. Since it's a pretty large structure, the effect is very noticeable; at least a lot more than, for example, the missing lower textures on sidedefs 457 and 459 of Doom II MAP02.
[img]https://i.imgur.com/JxYyGgq.png[/img]

I figure that it compatibility.txt was given a way to give textures to sidedefs, then this could be solved with something like this:

[code]5E3FCFDE78310BB89F92B1626A47D0AD // heretic.wad E4M7
{
sideuptex 1948 CSTLRCK
sideuptex 1955 CSTLRCK
sideuptex 1956 CSTLRCK
}
[/code]

Then it's just a question of updating the compat param enum, ParseCompatibility() and SetCompatibilityParams(), mostly trivial code.

What do you think, in scope or not?