Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
mikeo007

TEXTURE lumps question for pwads

Recommended Posts

Is it common for a TEXTURE lump to refer to missing patches?
I'm asking because I'm writing a tool to parse WAD files, and I'm finding that many PWADS contain textures that reference patches which aren't included in the actual WAD. I'm not sure exactly how I should interpret this behaviour when parsing the WAD files.

For example, GOTHICTX.wad's first texture (AASHITTY) references the patch "BODIES" which doesn't exist in the WAD. Same thing with ASHWALL2, ASHWALL3 & ASHWALL4 (RW22_1, RW22_2 & RW22_3).

Should I just discard any textures with missing patches, or is there a use for these that I'm not seeing?

Share this post


Link to post

Even if those patch graphics don't exist in the PWAD, if their PNAMES entries exist in the PWAD's PNAMES lump, do not discard any textures using them, because the graphics themselves might be included in another resource wad that's supposed to be loaded together with the PWAD. In your case (with BODIES, RW22_1, RW22_2 & RW22_3), said resource wad is actually the IWAD itself.

Also, the wad might be made for a source port that supports cumulative PNAMES lumps. In that case, you should (probably?) not discard even textures that reference unknown PNAMES entries, as they might be included in another resource wad's PNAMES - but I'm not sure about this.

Share this post


Link to post

Ok, that's what I thought might be happening.
The PNAMES entries are definitely there, there's just no patch data between the patch markers.
Only dealing with vanilla WADs for now, so no worries about cumulative lumps. I will just handle these similar to how SLADE does by giving a "missing patch" message and not displaying the texture.

Share this post


Link to post

Textures DO work and display properly in maps, even in vanilla, if their patch graphics are in a different wad than their PNAMES entries. If your tool is going to be anything else than a SLADE3-like manually operated wad content editor, for example a texture/map viewer/editor or something that analyses the texture's pixels, it should probably try to find the origin of those missing patches, at least look for them into the IWAD.

Share this post


Link to post

The way I have it set up now is that it paints the texture even if there's a missing patch, just leaving the "empty" area white. That way I'm not discarding the data or making it seem like it doesn't exist, but I'd still like to try and handle the multiple WAD scenario.

I guess an easy way to deal with some cases would be to also allow the user to specify an IWAD and search it for patches if they're not found in the PWAD. Allowing multiple PWADS to be loaded should also be doable, although I'll have to look into some things like which one is supposed to take priority when there's more than one PWAD.

Share this post


Link to post
mikeo007 said:

I'll have to look into some things like which one is supposed to take priority when there's more than one PWAD.

In case of lump name conflicts in multiple wads loaded together or even within the same wad, the last loaded lump takes priority over the previously loaded ones. So, the first priority measure is the load order of the wads, and the second priority measure is the particular lump's position within the wad.

Share this post


Link to post

Doom2.wad has the bodies patch. On top of the window in Slade, set the Base Resource to doom2.wad, and the "missing" patches in textures should then show normally.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×