[BUG] Client crash when exiting any level of chapter 5 in SIGIL

[Sbzro12345]

Describe the bug
Upon exiting any level in chapter 5 of sigil_v1_21.wad, Odamex client crashes. In multiplayer, the client also crashes. But the server moves on to the next level, so the players can just rejoin the server.

Build that the bug occurred in
v10.4.0 Release version. Commit ID 46e0e1d of stable branch.

To Reproduce
Windows 11 Pro 64-bit OS, OS build 22631.2715. Exit any level of chapter 5 of sigil_v1_21.wad. https://www.doomworld.com/idgames/levels/doom/Ports/s-u/sigil_v1_21

Expected behavior
Client should not crash, and move on to the next level properly. Name of map should also be displayed on automap properly.

Screenshots, NetDemos, & Crash Dumps
For some reason, the e5 level names are displayed as DOOM2 levels, even though DOOM.wad is being used as the iwad. This is not the case for the other episodes though.

Crash Dump:
odamex_g46e0e1_37152_20231118T200959.dmp

[Acts19quiz]

Possibly, if not probably, related to #858 efforts to remove ZMAPINFO support due to confusion with ZDoom's syntax, mods with both a MAPINFO (old ZDoom format) and ZMAPINFO (new ZDoom format), missing features from ZDoom, and other similar things.

I tested sigil_v1_21.wad with both Odamex 10.2.0 and 10.4.0, and there is some difference: 10.2.0 doesn't have the level exit crash. However, as mentioned, this could be related to ZMAPINFO support being removed.

This is why most, if not all, Odamex servers running SIGIL use SIGIL_COMPAT.WAD. sigil_v1_21.wad is intended for GZDoom, ZDaemon, and Eternity. I am, however, most curious with the level title there. That very much looks like a DOOM II level title, which suggests the incorrect IWAD (DOOM2.WAD is being used). However, I can't get SIGIL to load at all with it, and while DOOM.WAD crashes on 10.4.0 level exit, I don't get the borked level title.

The ironic thing about this is that Odamex MAPINFO support from ZDoom's older format has grown past when SIGIL first came out to the point that if MAPINFO in sigil_v1_21.wad was rewritten, the main SIGIL WAD could probably work just fine in Odamex. But as it stands now, the MAPINFO in sigil_v1_21.wad just isn't written with Odamex in mind.

[Sbzro12345]

no, I was running sigil_v1_21.wad with doom.wad. This also happened with 2022: A Doom Odyssey Chapter 5.

Crash Dump:
odamex_g46e0e1_22700_20231119T000803.dmp

Relevant Screenshots:

[Acts19quiz]

Just to follow-up a bit on this, I tested both mentioned WADs out. Removing the UMAPINFO from both WADs alleviated the E5M# crashes. Notably, 2022ado.wad doesn't crash on a non-E5 episode. This again seems likely related to #858 specifically the part about defaulting to UMAPINFO if one is present. With UMAPINFO removed, Odamex falls back to both WADs' regular MAPINFO which produce no crashes. There may be an error in how UMAPINFO is being interpreted.

[SpecLad]

I hit what is probably the same bug with SIGIL II. Debugging revealed that the crash happens here:

odamex/client/src/wi_stuff.cpp

Lines 1511 to 1532 in a9cb2de

	if (wbs->epsd < 3)
	{
	for (int j = 0; j < NUMANIMS[wbs->epsd]; j++)
	{
	animinfo_t* a = &anims[wbs->epsd][j];
	for (int i = 0; i < a->nanims; i++)
	{
	// MONDO HACK!
	if (wbs->epsd != 1 || j != 8)
	{
	// animations
	sprintf (name, "WIA%d%.2d%.2d", wbs->epsd, j, i);
	a->p[i] = W_CachePatch (name, PU_STATIC);
	}
	else
	{
	// HACK ALERT!
	a->p[i] = anims[1][4].p[i];
	}
	}
	}
	}

When playing SIGIL II, wbs->epsd equals -1, and therefore the array accesses NUMANIMS[wbs->epsd] and anims[wbs->epsd] are invalid.