Editing PNAMES in SLADE: How to fix many textures breaking

[Acts 19 quiz]

Reading this topic on Doomworld reminded me of how much of a headache editing PNAMES and TEXTUREx has been over the years. Nevermind what chaos XWE is capable of causing, even using SLADE to change PNAMES can cause all kinds of awful-looking or invalid textures. Adding patches to PNAMES is usually okay. Removing or changing them is a big no-no. However, I like a neatly ordered PNAMES, and I've often found occasion to 'manually' rearrange the order of the PNAMES by deleting up to the first one in my intended correct order, and manually putting everything back in. (As an aside, I would like for SLADE to be able to let me drag and move individual patches or groups of patches in PNAMES like I can in TEXTUREx, and deal with the mess later, but that's another topic for another day.)

The reason this breaks TEXTUREx is because it references not the names in PNAMES, but its order in line. So if texture ORIGAMI originally calls for patch NEWTHING (patch position #6 on PNAMES), but NEWTHING is rearranged in PNAMES to position #9, ORIGAMI will still look for whatever patch is now occupying position #6 in PNAMES. It might be LISTER now.

After growing tired or deleting a bunch of textures and having to manually put in the new texture information back in, I found a quick-ish workaround in SLADE that prevents texture breakages caused by removing and/or rearranging patches in PNAMES. In this tutorial, we'll be working with a fictitious PWAD called "patch.pk3".

1. Make a backup of your WAD or archive (IPK3/IPK7/PK3/PK7/ZIP) the moment before you start editing PNAMES. Change the backup's filename from something like "patch.pk3" to "patch.bak.pk3".
2. Open the original "patch.pk3" in SLADE. Make whatever changes to PNAMES you need to. Remove, rearrange, whatever. Your TEXTUREx lump is now broken....
3. ...so let's fix that! Open TEXTURE1/TEXTURE2 in "patch.pk3". Delete all textures (from both TEXTURE1 and TEXTURE2 if you have chosen to use both) since we know they're broken (they might appear okay at first glance, but if you close SLADE's TEXTUREx Editor and reopen it, they'll update to be broken).
4. Now open "patch.bak.pk3" in SLADE, and go to TEXTUREx. Use the mouse cursor to drag over the entire list of textures, right click, and select "Copy" (or use the Ctrl + C keyboard shortcut).
5. Go back to the TEXTUREx Editor for "patch.pk3", and go to the TEXTUREx lump. You can't right click here, but don't despair. You can still use the Ctrl + V shortcut or the Textures toolbar in SLADE. Do either to paste the textures.
6. If you use both TEXTURE1 and TEXTURE2, perform this process for both, and make sure to not cross things up (e.g., copy from TEXTURE2 and paste into TEXTURE1).
7. Close the TEXTUREx Editor for "patch.wad" ["TEXTUREx Editor (patch.wad)" in the toolbar]. Select "Yes" on the prompt.
8. If done correctly, all texture-related lumps should be blue and have asterisks. Save the WAD. Congratulations, you've updated PNAMES and saved TEXTUREx from destruction!

The magic sauce here is that while TEXTUREx internally references PNAMES entries by order #, SLADE appears to be programmed to recognize patch name in PNAMES when performing texture copy commands.

If your intent is to do more than rearrange PNAMES order, like rename or change the patches used by certain textures, there will be a couple of extra steps. For example, if you removed a patch that textures are still using it and didn't add it back, you'll need to revisit each texture that used it and fix each instance of INVPATCH###. SLADE will also automatically add missing PNAMES if it can find them in other WADs you have open, so check your PNAMES to make sure SLADE didn't add anything to it you weren't expecting.

This trick is mainly to fix texture breakages caused by any changes in PNAMES that changes the listed order of patches. Maybe this is already widely known, but I haven't found anything about it online, and had to discover it myself after doing things the slower way. I hope you find this tutorial useful.