Maps that have invalid offsets will thus have Texinfo objects that refer to incorrect textures and to textures with an index exceeding the size of the Textures lump.
The engine handles this differently. It allocates a list of nummiptex textures, zero initializes all of them and loads them one by one. Textures with invalid offsets are skipped, leaving the texture object as all zeroes.
When the Textures lump deserializes textures invalid offsets are ignored, but no texture is added: https://github.com/LogicAndTrick/sledge-formats/blob/b9b5f956a694a5faa9a307afb364c090573c2d05/Sledge.Formats.Bsp/Lumps/Textures.cs#L24-L30
Maps that have invalid offsets will thus have Texinfo objects that refer to incorrect textures and to textures with an index exceeding the size of the Textures lump.
The engine handles this differently. It allocates a list of
nummiptextextures, zero initializes all of them and loads them one by one. Textures with invalid offsets are skipped, leaving the texture object as all zeroes.See https://github.com/id-Software/Quake/blob/bf4ac424ce754894ac8f1dae6a3981954bc9852d/WinQuake/gl_model.c#L358-L364
The compiler initializes the offsets here: https://github.com/ValveSoftware/halflife/blob/c7240b965743a53a29491dd49320c88eecf6257b/utils/qcsg/textures.c#L353-L368
The correct way to handle this case here would be to create a MipTexture object with an empty name and defaulted properties.
This is known to happen with
cz_recoil,cz_stadium_czand possibly Sven Co-op'sgrunts2.