Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
scifista42

Broken TEXTURE1 due to a SLADE3 bug?

Recommended Posts

I have a wad full of custom patches with a custom TEXTURE1 lump for new textures. I've decided that I no longer need one of the patches (it was roughly in the middle of the list). So I've deleted it from the wad. Then I've remembered that this is going to break vanilla/Boom compatibility as long as the patch name stays listed in PNAMES. So I've opened PNAMES, found the respective patch name and clicked "Remove Patch". The patch was removed, I've closed SLADE3 and wanted to play. But something was wrong. PrBoom+ didn't complain, but Zandronum did: "PNAMES has 604 entries, but XXXXXXXX wants to use entry 605.". I've opened the wad in SLADE3 again and checked TEXTURE1 lump. To my surprise, the patches were no longer applied properly. Precisely, their patch indexes were shifted by 1, therefore the textures displayed wrong patches (by 1, according to the PNAMES list).

So I'm stuck with a large, broken TEXTURE1. Might it be a SLADE3 bug? And how do I fix it now without reassembling all the textures again?

EDIT: My version of SLADE3 is v3.1.0 beta 4.

Share this post


Link to post

So, the patch you've deleted was between SCIFIWHI and SCIFIMP6.

Here's how you can do a manual fix without too much pain:
1. Export the PNAMES lump
2. Open the exported file in a hex editor. You're gonna do hex-surgery on it.
3. Edit the "5C 02" right at the start, make it say "5D 02" instead
4. Search for the string (not hex value) SCIFIMP6
5. Hit the "insert" key so that the hex editor goes in "insert" mode instead of "overwrite"
6. Right before the SCIFIMP6 string, insert an 8-letter name, for example BUGDUMMY. It's very important to use all 8 characters.
7. Save PNAMES.lmp from text editor, and import it in SLADE.
8. Open texture editor, the textures should work correctly again.

Now there's definitely a bug where textures aren't written with their correct patch indices when a patch was deleted. I've been able to replicate it so it hasn't been fixed yet. I'll work on it.

Share this post


Link to post

I'm uploading a fixed version of SLADE on DRD Team's devbuilds site. Look for Slade-3.1.0.1-626-g0336db5.7z. (For reference: 626 is the number of commits it has since version 3.1.0.1, which itself has 230 commits after 3.1.0 beta4. The weird hexadecimal number preceded by a g is the shortened hash of the latest commit.)

Share this post


Link to post
scifista42 said:

Then I've remembered that this is going to break vanilla/Boom compatibility as long as the patch name stays listed in PNAMES.

I don't think that's true. If you delete a patch (but leave it in pnames) and remove any references to the patch in the texture1 lump, then it should load in vanilla/boom (just tried it).

Share this post


Link to post

Here's some info explaining the problem more precisely.

The PNAMES lump and the TEXTUREx lumps are related: TEXTUREx lumps store patches added to a texture not as plain text, but as an index in the PNAMES lump. Therefore when an entry in PNAMES is deleted, all patch indices in TEXTUREx which are higher than the one of the deleted patch, should be decremented with 1. The problem of TS was that he deleted the PNAMES entry, but did not decrement the higher refs in the TEXTURE1 lump. That's why the patches looked being shifted by 1, and Zandronum gave the '605 missing' error. Obviously re-inserting the removed entry at the correct position in PNAMES, as Gez posted, solved his problem.

See for this http://doom.wikia.com/wiki/TEXTURE1_and_TEXTURE2 and http://doom.wikia.com/wiki/PNAMES.

@ scifista42 & TimeOfDeath: from a textures POV, entries in PNAMES which are not referenced to by any texture definition are simply unused. And obviously is the corresponding image lump. So deleting the image lump of an unused patch while leaving the patch entry in PNAMES should (in theory) be perfectly ok in any engine.

Share this post


Link to post

Yes, that was the mechanical explanation of the problem and why it was possible to fix it easily with a hex editor.

The explanation for the bug was that SLADE keeps track of lumps that have been modified, and only writes those when saving. And here, only the PNAMES lump was modified, so it neglected to rewrite the TEXTURE1 lump (there was no edits to the texture themselves, after all...). Fixing this consisted in simply forcing it to write TEXTUREx lumps if they have been modified or if PNAMES was modified.

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
×