(Some) Custom textures not showing in GzDoom but showing in UDB

Ask about editing graphics, sounds, models, music, etc here!
Shaders (GLSL) and SNDINFO questions also go here!

Moderators: GZDoom Developers, Raze Developers

Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. If you still don't understand how to use a feature, then ask here.
IgnyteZero
Posts: 18
Joined: Thu Jan 16, 2025 12:17 pm
Operating System Version (Optional): Windows 10

(Some) Custom textures not showing in GzDoom but showing in UDB

Post by IgnyteZero »

Ok, so I've added a few custom texture packs to my WAD. When beginning I started with Boom format, and they all just worked fine there. But for reasons I decided to finish the maps in UDMF. Suddenly some textures I used no longer worked, like 10-20% of them. Some that seem like regular textures from Doom2, but most not showing up are some of the custom ones. I have no idea why this happened. My knowledge is limited, but from what I can see nothing seems to be wrong with the WAD or textures. I've tried converting them to different formats, it make sno difference. I tried renaming PP_START and PP_END to TX-START and TX_End. It makes no difference. So I am at a loss on why these textures don't work in GZDoom. Now, most of it I can work around I guess by just not using those specific textures, but some like the computer panels in the example below is quite frustrating to not be able to use. As some of the normal ones has dissapeared too there.

How it looks in GZDoom.


How it looks in UDB


Anyone have any idea of what might be up here? As I said, it worked just fine in vanilla mode. And there's no issue with any of the flats. They all work.

Edit:
Forgot to add

Using UDB 3 (R4212) and SLADE 3.2.7
Using the following texture packs:

jimmytex.wad
rfhelltx.wad
d1gfxd2.wad
gothictx.wad
nb5texd2.wad
Top
IgnyteZero
Posts: 18
Joined: Thu Jan 16, 2025 12:17 pm
Operating System Version (Optional): Windows 10

Re: (Some) Custom textures not showing in GzDoom but showing in UDB

Post by IgnyteZero »

So, the thing is, to clarify, I've added all textures and flats to the Texture lump and the Patchtable. And still it looks like this in the patch table.



The textures exists in the wad, and they should be in doom format.
Top
User avatar
Enjay
 
 
Posts: 26878
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland

Re: (Some) Custom textures not showing in GzDoom but showing in UDB

Post by Enjay »

Are you able to share your WAD? There's obviously some weirdness going on. If you are certain the patches are present, but Slade and the game are unable to find them, they must be in the wrong place, or wrong format somehow.
Top
IgnyteZero
Posts: 18
Joined: Thu Jan 16, 2025 12:17 pm
Operating System Version (Optional): Windows 10

Re: (Some) Custom textures not showing in GzDoom but showing in UDB

Post by IgnyteZero »

Yeah, I could share it. So, first, full background:

It's a megawad where I'm slightly polishing up seven mediocre levels I did for fun back in -95. As well as finishing an eigth level I had begun on. A work in progress, as converting to UDMF took it's time (went GZdoom because I "needed" some linedef and sector functions not available in vanilla/Boom). I added so many resources because I'm finishing it up with some extra levels that I never got around to doing.

So I made the bad decision of adding all these textures because I knew what kind of new visuals I wanted, but was unsure of which exact textures I would use... So I added all the texture packs I liked. This was when starting to look at it from the beginning using Boom. And everything seemed fine then. But as stated above, some disappeared after converting to GZDoom/UDMF format. But anyway, that's why the wad looks like it looks I suppose.

Here's the link
Top
User avatar
Enjay
 
 
Posts: 26878
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland

Re: (Some) Custom textures not showing in GzDoom but showing in UDB

Post by Enjay »

OK, I *think* I know what's up.

On a quick inspection, the "(!)NOT FOUND" patches all seem to be flats, and they are in the FLATS namespace in the WAD. These should not be added as textures via the PNAMES and TEXTURE1 tables/database. They should just work as resources that you can use on walls or floors with them just being in the WAD, in the correct format and in the correct namespace. (Originally, they were just for floors/ceilings in the original Doom and had to be used for that, and nothing else.) Trying to add them the the patches and texture tables is not suitable.

You should be able to take them out of the patches/texture tables and use them without any further changes.
If you want them to act as textures for some reason, then they should be converted to a suitable format (either a Doom graphic, or a PNG), and placed in the correct namespace for that format.

As a side thing to consider, seeing as how this is now a UDMF GZDoom project and Boom compatibility isn't important: your WAD (while not the worst, not by a long way) is a bit messy because of how it has been constructed using different resources from different places. I would consider changing it to a PK3. IMO, that helps keep things ordered because you put things in the correct namespace by putting them in the correct folder within the PK3. It's a quite deliberate, and well-defined act to do so. It would be a bit of work to do it, but not a huge amount.

https://zdoom.org/wiki/Using_ZIPs_as_WAD_replacement

You don't even have to use any special tools to make a PK3 either. In fact, you can just use a folder with the correct internal structure and have the folder with all the files loose (but in their correct sub folders) and load the folder into GZDoom. So, you are just moving files around as you would with any other files in Windows Explorer. Them when you are done, you can zip the whole thing up and rename it to PK3.

I would also consider getting rid of the old, arcane lumps like ANIMATED, SWITCHES and SWANTBLS and including their contents in your ANIMDEFS lump which is a modern, easier to read, easier to edit, GZDoom format text lump. Again, a bit of work, but not too much. For what it's worth, SLADE can also convert the old TEXTURE and PNAMES lumps into modern TEXTURES.txt lumps too. Again, modern, easier to read and edit IMO. If, however, any of you textures are just single patch textures (as many are) then you can just make them act as textures by putting them in the correct namespace (between TX_ markers in a WAD, or in a textures folder in a PK3). Again, they would need to be in Doom graphics or PNG format for that, not FLAT.


EDIT:
OK, digging a bit further, there are more problems. I only looked at the ones near the end of your textures list (the ones in your screenshot). A LOT of your textures are invalid or reference either unsuitable or missing patches. Look at the BFALL and BIGBRIK textures for example, most of them are referencing sky pictures!

Lots of textures, and I mean lots of textures, reference invalid/missing patches. Very commonly these are patches that have names like INVPATCH2405 (according to SLADE). I don't even know how that happened because the names are too long for the WAD format. The names actually look as if they might have been generated by some sort of checking/validation process at some point and somehow got baked into the texture1 lump.

Basically, your texture database is, to put it technically, well-borked.

I'll attach a copy of the error report from SLADE because it's waaay too long to include in the post.
SladeOut1.zip
I think, with a texture lump this messed up, it might be better to start the texture importing process again (possibly doing it in PK3 format). That way you can be a bit more logical and selective about what you import, and watch for errors/make backups as you go so that you can easily roll-back if something messes up at any stage.
You do not have the required permissions to view the files attached to this post.
Top
User avatar
Enjay
 
 
Posts: 26878
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland

Re: (Some) Custom textures not showing in GzDoom but showing in UDB

Post by Enjay »

Interesting, I just opened your WAD in DeePsea and the Texture1 lump seems far less borked there. Many of the textures that did not look right in SLADE look OK in DeePSea (BFALL etc), but quite a lot of the textures that seemed to be referencing FLATs were referencing real patches, albeit the wrong patches. So, I don't know which of the editing tools is giving the most accurate picture. Neither is showing a particularly usable set of textures.

I think it still comes down to the TEXTURE1 and PNAMES databases getting mashed somehow during the import process. And my suggestion to start the import from scratch again still stands.

For what it's worth, the DeePsea error report is much shorter and quite different. It also clearly isn't flagging up some of the problems that SLADE reported, or which I noticed just by eye.

Code: Select all

** Checking 2686 PNAMES to the all WADS loaded **


** Use EXPORT tool to check ALL graphics **

Total Palette Pixels not used by any TEXTURE graphic = 1
250,

All Texture lumps found

== Checking 3531 Textures ==

LITE128  64x128 (3 patches) not completely covered at 63
SKY3     1024x128 (4 patches) not completely covered at 130816
ADEL_Z03 128x128 (1 patches) not completely covered at 6144
ADEL_Z04 64x128 (1 patches) not completely covered at 3072
ADEL_Z61 128x128 (1 patches) not completely covered at 0
ADEL_Z62 128x128 (1 patches) not completely covered at 0
SKY1N    1024x240 (1 patches) not completely covered at 64
SKY2N    1024x240 (1 patches) not completely covered at 64
SKY3N    512x256 (1 patches) not completely covered at 64
SKY4N    1024x244 (1 patches) not completely covered at 64
SKY1D1   256x128 (1 patches) not completely covered at 64
SKY2D1   256x128 (1 patches) not completely covered at 64
SKY3D1   256x128 (1 patches) not completely covered at 64
SKY3D1B  256x128 (1 patches) not completely covered at 64
SKY4     256x128 (1 patches) not completely covered at 128
SKY4D1   256x128 (1 patches) not completely covered at 64
SKY5     256x128 (1 patches) not completely covered at 96
SKY6     256x128 (1 patches) not completely covered at 128
SKYH1    256x200 (1 patches) not completely covered at 128
SKY1N    1024x240 (1 patches) not completely covered at 64
SKY2N    1024x240 (1 patches) not completely covered at 64
SKY3N    512x256 (1 patches) not completely covered at 64
SKY4N    1024x244 (1 patches) not completely covered at 64
LABWAL3  64x32 (1 patches) not completely covered at 24
PI01A0   24x72 (1 patches) not completely covered at 1536
PI02A0   80x72 (1 patches) not completely covered at 64
PI05A0   32x72 (1 patches) not completely covered at 1312
PIPEX_4  256x128 (1 patches) not completely covered at 64
PS09A0   32x32 (1 patches) not completely covered at 24
PS11A0   32x32 (1 patches) not completely covered at 256
PS19A0   62x36 (1 patches) not completely covered at 32
PS19B0   64x40 (1 patches) not completely covered at 32
PT01A0   80x16 (1 patches) not completely covered at 64
PT02A0   80x16 (1 patches) not completely covered at 64
PT03A0   80x16 (1 patches) not completely covered at 64
PT04A0   80x16 (1 patches) not completely covered at 64
PT19A0   40x16 (1 patches) not completely covered at 16
PT20A0   40x16 (1 patches) not completely covered at 16
PT21A0   40x16 (1 patches) not completely covered at 16
PT22A0   48x16 (1 patches) not completely covered at 16
PT23A0   40x16 (1 patches) not completely covered at 32
PT25A0   40x16 (1 patches) not completely covered at 32
PT27A0   40x16 (1 patches) not completely covered at 32
PT28A0   40x16 (1 patches) not completely covered at 32
PT29A0   40x16 (1 patches) not completely covered at 36
STEP18ND 128x8 (1 patches) not completely covered at 64
STEP19ND 128x8 (1 patches) not completely covered at 48
SUPPRT1N 24x72 (1 patches) not completely covered at 864
SUPPRT4N 24x72 (1 patches) not completely covered at 1488
T15_2    64x128 (1 patches) not completely covered at 62
TP1_1    112x176 (1 patches) not completely covered at 14336
TP1_2    112x176 (1 patches) not completely covered at 16128
TP4_1    128x128 (1 patches) not completely covered at 64
TP4_2    128x128 (1 patches) not completely covered at 64
TP6_1    128x128 (1 patches) not completely covered at 64
TP6_2    128x128 (1 patches) not completely covered at 64
TP8_1    128x128 (1 patches) not completely covered at 64
TP8_2    128x128 (1 patches) not completely covered at 64
W111_4   64x64 (1 patches) not completely covered at 32
W111_6   64x64 (1 patches) not completely covered at 16
W111_7   64x64 (1 patches) not completely covered at 22
W18_1    216x184 (1 patches) not completely covered at 64
W31_8    72x64 (1 patches) not completely covered at 32
W31_9    8x64 (1 patches) not completely covered at 448
W31_A    8x64 (1 patches) not completely covered at 448
W31_B    64x64 (1 patches) not completely covered at 512
W31_C    64x64 (1 patches) not completely covered at 56
W32_2    56x64 (1 patches) not completely covered at 3136
W32_3    64x64 (1 patches) not completely covered at 56
W32_5    56x64 (1 patches) not completely covered at 32
W32_6    56x64 (1 patches) not completely covered at 32
W32_9    40x64 (1 patches) not completely covered at 32
W33_1    128x64 (1 patches) not completely covered at 32
W33_2    64x64 (1 patches) not completely covered at 32
W33_3    64x64 (1 patches) not completely covered at 32
W33_4    64x64 (1 patches) not completely covered at 32
W33_6    64x64 (1 patches) not completely covered at 16
W33_9    96x96 (1 patches) not completely covered at 8
WALL00_4 16x144 (1 patches) not completely covered at 8
WALL00_9 16x144 (1 patches) not completely covered at 2048
WALL02_4 112x72 (1 patches) not completely covered at 64
WALL04_1 48x72 (1 patches) not completely covered at 1536
WALL04_6 16x72 (1 patches) not completely covered at 512
WALL04_8 48x72 (1 patches) not completely covered at 1536
WALL06_1 112x96 (1 patches) not completely covered at 64
WALL06_2 112x96 (1 patches) not completely covered at 64
WALL06_3 32x96 (1 patches) not completely covered at 2304
WALL07_8 80x72 (1 patches) not completely covered at 64
WALL07_9 80x72 (1 patches) not completely covered at 64
WALL07_C 16x72 (1 patches) not completely covered at 8
WALL07_D 16x72 (1 patches) not completely covered at 384
WALL07_E 24x72 (1 patches) not completely covered at 16
WALL09_2 40x72 (1 patches) not completely covered at 1280
WALL09_3 80x72 (1 patches) not completely covered at 64
WALL09_5 80x72 (1 patches) not completely covered at 8
WALL09_6 40x72 (1 patches) not completely covered at 16
WALL09_7 80x72 (1 patches) not completely covered at 8
WALL09_8 40x72 (1 patches) not completely covered at 16
WALL11_1 64x72 (1 patches) not completely covered at 16
WALL11_2 64x72 (1 patches) not completely covered at 8
WALL11_3 64x72 (1 patches) not completely covered at 8
WALL11_4 64x72 (1 patches) not completely covered at 16
WALL11_5 64x72 (1 patches) not completely covered at 8
WALL11_6 64x72 (1 patches) not completely covered at 16
WALL11_7 64x72 (1 patches) not completely covered at 16
WALL26_1 176x96 (1 patches) not completely covered at 24
WALL26_2 88x96 (1 patches) not completely covered at 24
WALL26_3 176x32 (1 patches) not completely covered at 128
WALL26_4 88x32 (1 patches) not completely covered at 32
WALL26_5 88x96 (1 patches) not completely covered at 8
ASD1_1   128x128 (1 patches) not completely covered at 64
ASD5_1   128x128 (1 patches) not completely covered at 14336
BLK1_1   64x128 (1 patches) not completely covered at 7168
MWALL4_8 48x16 (1 patches) not completely covered at 23
MWALL4_A 48x16 (1 patches) not completely covered at 16
SWE_1    64x50 (1 patches) not completely covered at 16
SWE_2    64x50 (1 patches) not completely covered at 16
SWE_3    64x50 (1 patches) not completely covered at 16
SWE_6    56x32 (1 patches) not completely covered at 24
SWE_8    56x32 (1 patches) not completely covered at 16
W120_1   128x32 (1 patches) not completely covered at 64
W121_1   128x128 (1 patches) not completely covered at 64
W122_1   128x128 (1 patches) not completely covered at 64
W122_2   128x128 (1 patches) not completely covered at 64
W20_1    128x168 (1 patches) not completely covered at 64
W20_1B   152x168 (1 patches) not completely covered at 64
W29_1    128x112 (1 patches) not completely covered at 64
W29_2    128x112 (1 patches) not completely covered at 64
W37_1    104x104 (1 patches) not completely covered at 64
W37_2    104x104 (1 patches) not completely covered at 64
W38_1    104x104 (1 patches) not completely covered at 64
W38_2    104x104 (1 patches) not completely covered at 64
W44_2    72x104 (1 patches) not completely covered at 16
W44_3    72x104 (1 patches) not completely covered at 16
W45_1    64x104 (1 patches) not completely covered at 16
W45_2    72x104 (1 patches) not completely covered at 16
W45_3    72x104 (1 patches) not completely covered at 64
W60_1    128x128 (1 patches) not completely covered at 64
W60_2    128x128 (1 patches) not completely covered at 16
W60_3    128x128 (1 patches) not completely covered at 64
W60_4    128x128 (1 patches) not completely covered at 64
W61_2    128x128 (1 patches) not completely covered at 64
W65_1    128x128 (1 patches) not completely covered at 64
W65_2    128x128 (1 patches) not completely covered at 64
W67_8    72x64 (1 patches) not completely covered at 64
W68_1    112x96 (1 patches) not completely covered at 64
W68_2    112x96 (1 patches) not completely covered at 64
WALL6_1  128x80 (1 patches) not completely covered at 64
WALL6_2  128x72 (1 patches) not completely covered at 64
WALL72_1 128x64 (1 patches) not completely covered at 64
BODY_3   128x128 (1 patches) not completely covered at 40
RW29_2   64x128 (1 patches) not completely covered at 32
RW29_3   64x128 (1 patches) not completely covered at 4096
RW49_2   64x128 (1 patches) not completely covered at 4096
RW50_3   64x128 (1 patches) not completely covered at 4096
RW50_4   64x128 (1 patches) not completely covered at 4096
RGLOW_1  64x128 (1 patches) not completely covered at 40
RGLOW_2  64x128 (1 patches) not completely covered at 16
RGLOW_3  64x128 (1 patches) not completely covered at 32
RW6_2    64x128 (1 patches) not completely covered at 22
RW6_3    64x128 (1 patches) not completely covered at 8
RW6_4    64x128 (1 patches) not completely covered at 8
RW6_5    64x128 (1 patches) not completely covered at 8
BASALT1  64x128 (1 patches) not completely covered at 16
BASALT2  64x128 (1 patches) not completely covered at 8
BIGBAN1  128x384 (1 patches) not completely covered at 16
BIGDOORA 128x96 (1 patches) not completely covered at 32
BRIKMET1 128x128 (1 patches) not completely covered at 8
BRIKMET2 128x128 (1 patches) not completely covered at 8
BRIKMET3 128x128 (1 patches) not completely covered at 8
BRIKMET4 128x128 (1 patches) not completely covered at 16
BRIKMET5 128x256 (1 patches) not completely covered at 16384
BRIKMET6 128x256 (1 patches) not completely covered at 24
BRIKMET7 128x256 (1 patches) not completely covered at 16
BRIKMET8 128x256 (1 patches) not completely covered at 32
BRJAIL1M 64x128 (1 patches) not completely covered at 16
BRJAIL2  128x128 (1 patches) not completely covered at 16
BRJAIL2M 128x128 (1 patches) not completely covered at 64
BRJAIL4M 128x128 (1 patches) not completely covered at 64
BRJAIL6  128x256 (1 patches) not completely covered at 16384
BRJAIL6M 128x256 (1 patches) not completely covered at 64
BRJAIL7  128x256 (1 patches) not completely covered at 16384
BRJAIL7M 128x256 (1 patches) not completely covered at 16384
BRJAIL8  128x256 (1 patches) not completely covered at 16384
BRJAIL8M 128x256 (1 patches) not completely covered at 16384
COMPDBG1 256x128 (1 patches) not completely covered at 128
COMPTXT0 256x128 (1 patches) not completely covered at 128
COMPTXT1 256x128 (1 patches) not completely covered at 128
GSTWOOD1 256x128 (1 patches) not completely covered at 128
GSTWOOD2 256x128 (1 patches) not completely covered at 128
GSTWOOD3 256x128 (1 patches) not completely covered at 128
GSTWOOD4 256x128 (1 patches) not completely covered at 128
GSTWOOD5 256x128 (1 patches) not completely covered at 64
KCBASE1  128x128 (1 patches) not completely covered at 64
KCBASE2  128x128 (1 patches) not completely covered at 64
KCBASE3  128x128 (1 patches) not completely covered at 64
KCBASE4  128x128 (1 patches) not completely covered at 64
KCDOOR1  128x128 (1 patches) not completely covered at 64
KCDOORBL 128x128 (1 patches) not completely covered at 64
KCDOORRD 128x128 (1 patches) not completely covered at 64
KCDOORYL 128x128 (1 patches) not completely covered at 64
KCGATE1  128x128 (1 patches) not completely covered at 64
KCGATE2  128x128 (1 patches) not completely covered at 64
KCGATE3  128x128 (1 patches) not completely covered at 32
KCHEX1   128x128 (1 patches) not completely covered at 64
KCMET1H  128x128 (1 patches) not completely covered at 120
KCMET1HS 128x128 (1 patches) not completely covered at 32
KCMET2   128x128 (1 patches) not completely covered at 64
KCMET2S  128x128 (1 patches) not completely covered at 64
KCMET3H  128x128 (1 patches) not completely covered at 64
KCMET3HS 128x128 (1 patches) not completely covered at 64
KCPANEL1 128x128 (1 patches) not completely covered at 64
KCPANEL2 128x128 (1 patches) not completely covered at 64
KCPANEL3 128x128 (1 patches) not completely covered at 64
KCTILE4  128x128 (1 patches) not completely covered at 64
KSW_CAU1 128x16 (1 patches) not completely covered at 64
KSW_CAU2 128x16 (1 patches) not completely covered at 64
LAVAWAL2 64x128 (1 patches) not completely covered at 4608
LAVAWAL3 64x128 (1 patches) not completely covered at 32
LAVAWAL4 64x128 (1 patches) not completely covered at 2048
METFIVE1 256x128 (1 patches) not completely covered at 64
METFIVE2 256x128 (1 patches) not completely covered at 64
METLITE3 16x128 (1 patches) not completely covered at 1024
METOWER1 256x384 (1 patches) not completely covered at 64
METOWER2 128x256 (1 patches) not completely covered at 64
METOWER3 256x256 (1 patches) not completely covered at 64
METOWER4 256x256 (1 patches) not completely covered at 64
METOWER5 256x384 (1 patches) not completely covered at 64
METOWER6 128x256 (1 patches) not completely covered at 64
METTEK1  256x128 (1 patches) not completely covered at 64
METTEK2  256x128 (1 patches) not completely covered at 128
MIDRAIL1 64x32 (1 patches) not completely covered at 1536
MIDRAIL2 64x32 (1 patches) not completely covered at 16
MIDRAIL3 64x32 (1 patches) not completely covered at 16
MIDRAILL 32x48 (1 patches) not completely covered at 16
MIDRAILR 32x48 (1 patches) not completely covered at 16
MIDTEEF0 256x128 (1 patches) not completely covered at 16
MIDTEEF1 256x128 (1 patches) not completely covered at 64
MIDTEEF2 256x128 (1 patches) not completely covered at 64
NUKSOUL1 128x128 (1 patches) not completely covered at 64
NUKSOUL2 128x128 (1 patches) not completely covered at 64
NUKSOUL3 128x128 (1 patches) not completely covered at 32
NUKSOUL4 128x128 (1 patches) not completely covered at 16
NUKSOUL5 128x128 (1 patches) not completely covered at 64
NUKSOUL6 128x128 (1 patches) not completely covered at 64
PIPESCBL 128x128 (1 patches) not completely covered at 64
PIPESCBR 128x128 (1 patches) not completely covered at 64
PIPESCH1 256x128 (1 patches) not completely covered at 64
PIPESCH2 256x128 (1 patches) not completely covered at 64
PIPESCH3 256x128 (1 patches) not completely covered at 64
PIPESCH4 256x128 (1 patches) not completely covered at 64
PIPESCOR 128x128 (1 patches) not completely covered at 64
PIPESCTL 128x128 (1 patches) not completely covered at 64
PIPESCTR 128x128 (1 patches) not completely covered at 64
PIPESCV1 64x256 (1 patches) not completely covered at 8192
PIPESCV2 64x256 (1 patches) not completely covered at 8192
PIPESCV3 64x256 (1 patches) not completely covered at 8192
PIPESCV4 64x256 (1 patches) not completely covered at 8192
ROCKEDG3 128x128 (1 patches) not completely covered at 64
ROCKHOB3 128x128 (1 patches) not completely covered at 55
ROCKHOL1 64x128 (1 patches) not completely covered at 55
ROCKHOL2 64x128 (1 patches) not completely covered at 55
ROCKHOL3 128x128 (1 patches) not completely covered at 55
ROCKLAV1 128x128 (1 patches) not completely covered at 55
ROCKLAV2 128x128 (1 patches) not completely covered at 55
ROCKRDV1 128x128 (1 patches) not completely covered at 64
ROCKRDV3 128x128 (1 patches) not completely covered at 64
ROCKRDW1 128x128 (1 patches) not completely covered at 64
ROCKRDW3 128x128 (1 patches) not completely covered at 32
ROCKRDX1 128x128 (1 patches) not completely covered at 64
ROCKRDX3 128x128 (1 patches) not completely covered at 64
ROCKRDY1 128x128 (1 patches) not completely covered at 64
ROCKRDZ1 128x128 (1 patches) not completely covered at 64
ROCKRDZ2 128x128 (1 patches) not completely covered at 64
SIGALPB2 256x32 (1 patches) not completely covered at 64
SIGALPB3 256x32 (1 patches) not completely covered at 64
SIGALPG1 256x32 (1 patches) not completely covered at 128
SIGALPG2 256x32 (1 patches) not completely covered at 128
SIGALPG3 256x32 (1 patches) not completely covered at 128
SIGALPP1 256x32 (1 patches) not completely covered at 128
SIGALPP2 256x32 (1 patches) not completely covered at 64
SIGALPP3 256x32 (1 patches) not completely covered at 64
SIGALPR1 256x32 (1 patches) not completely covered at 64
SIGALPR2 256x32 (1 patches) not completely covered at 64
SIGALPR3 256x32 (1 patches) not completely covered at 64
SIGALPY1 256x32 (1 patches) not completely covered at 128
SIGALPY2 256x32 (1 patches) not completely covered at 64
SIGALPY3 256x32 (1 patches) not completely covered at 64
SKINPAN2 256x128 (1 patches) not completely covered at 64
SKINPAN3 256x128 (1 patches) not completely covered at 64
STEPWAL4 128x128 (1 patches) not completely covered at 118
STEPWAL5 128x128 (1 patches) not completely covered at 64
STOBRIK3 128x128 (1 patches) not completely covered at 64
STOBRIK4 128x128 (1 patches) not completely covered at 64
STOBRIK5 128x128 (1 patches) not completely covered at 64
STOBRIK7 128x128 (1 patches) not completely covered at 64
STOBRIK8 128x128 (1 patches) not completely covered at 64
TCBLKHDA 128x128 (1 patches) not completely covered at 64
TCBLKHDB 128x128 (1 patches) not completely covered at 64
TCDOORA  128x128 (1 patches) not completely covered at 64
TCDOORY  128x128 (1 patches) not completely covered at 64
TCDRRED  128x128 (1 patches) not completely covered at 64
TCGRATA  128x128 (1 patches) not completely covered at 32
TCGRATB  128x128 (1 patches) not completely covered at 32
TCPNLC   128x128 (1 patches) not completely covered at 13312
TCPNLD   128x128 (1 patches) not completely covered at 13312
TCRCKWLA 256x256 (1 patches) not completely covered at 128
TCRCKWLC 256x256 (1 patches) not completely covered at 128
WOOD5G   256x128 (1 patches) not completely covered at 128
WOOD5H   256x128 (1 patches) not completely covered at 128
WOODFAC2 256x128 (1 patches) not completely covered at 128
WOODFAC3 256x128 (1 patches) not completely covered at 128
WOODFAV1 256x128 (1 patches) not completely covered at 128
WOODFAV2 256x128 (1 patches) not completely covered at 128
WOODFAV3 256x128 (1 patches) not completely covered at 128
WOODGRAT 256x128 (1 patches) not completely covered at 128
WOODOOR5 128x128 (1 patches) not completely covered at 64
WOODSKU2 128x128 (1 patches) not completely covered at 64
WOODSKU3 128x128 (1 patches) not completely covered at 64
ZWOODGR1 256x128 (1 patches) not completely covered at 128
ZZZGATE1 512x512 (1 patches) not completely covered at 64
ZZZGATE2 512x512 (1 patches) not completely covered at 64
ZZZGATE3 512x512 (1 patches) not completely covered at 256
ZZZGATE4 512x512 (1 patches) not completely covered at 64
ZZZWARP1 256x160 (1 patches) not completely covered at 64
ZZZWARP2 256x160 (1 patches) not completely covered at 64
ZZZWARP3 256x160 (1 patches) not completely covered at 64
ZZZWARP4 256x160 (1 patches) not completely covered at 64
TSCRN3   55x54 (1 patches) not completely covered at 1760
TSCRN5   55x54 (1 patches) not completely covered at 1760
TSCRN6   55x54 (1 patches) not completely covered at 32
TSCRN8   55x54 (1 patches) not completely covered at 32
CONVNA1  64x64 (1 patches) not completely covered at 32
CONVNA2  64x64 (1 patches) not completely covered at 32
FLOOR8_6 64x64 (1 patches) not completely covered at 16
TCMFLRG  64x64 (1 patches) not completely covered at 32
TCMUD1   64x64 (1 patches) not completely covered at 32
TCRCKA   64x64 (1 patches) not completely covered at 32
TEKFLR_1 64x64 (1 patches) not completely covered at 32
DEADFAN  64x64 (1 patches) not completely covered at 32
DEADFAN  64x64 (1 patches) not completely covered at 32
STILLFAN 64x64 (1 patches) not completely covered at 32

*** 342 Textures not completely covered by patches ***


== Checking 3531 Textures for duplicates ==

duplicate TEXTURE BRWINDO2
duplicate TEXTURE DEADFAN 
duplicate TEXTURE GRAYNUKE
duplicate TEXTURE SKY1N   
duplicate TEXTURE SKY2N   
duplicate TEXTURE SKY3N   
duplicate TEXTURE SKY4    
duplicate TEXTURE SKY4N   
duplicate TEXTURE SKY5    
duplicate TEXTURE SKY6    
duplicate TEXTURE SKYH1   
duplicate TEXTURE STEP5   
duplicate TEXTURE STEP6   
duplicate TEXTURE TCLTA   
duplicate TEXTURE TCMFLRE 
duplicate TEXTURE TCMFLRF 

*** 16 duplicate TEXTURE names found ***

== Checking 2686 PNAMES for duplicates ==

There are no duplicate PNAMES names

Edit: as an additional thought - and I hate that I am suggesting this, because it's bad practice and I have a real aversion to it - you might find it easier to delete from your WAD all of the textures that you got from the various texture resource wads. Then you could package things up as a PK3 (as discussed already), with your maps in a maps folder, any other lumps in a suitable location, but just package the texture resource WADs that you have been using in the root folder of your PK3. Assuming those resource wads are correctly formatted, that should work, and you can also load them separately in GZDoomBuilder while you work on the maps.

Like I said, it's bad practice because of how GZDoom has to handle embedded WADs like that, but it might be a simple solution to get you going.
Top
IgnyteZero
Posts: 18
Joined: Thu Jan 16, 2025 12:17 pm
Operating System Version (Optional): Windows 10

Re: (Some) Custom textures not showing in GzDoom but showing in UDB

Post by IgnyteZero »

Thanks for going through my wad so rigourously. Must have taken some time.

One thing I did not mention was that before I decided to convert to UDMF I didn't use SLADE either (as I did not know that app existed at first). I just had UDB, and found some minor app someone had made to merge wads. I guess my headaches derive from using that tool for the first merge with texture packs, not having started to learn how the wad worked internally yet. (Still a noob, but things like this makes me learn).

Anyways,
Enjay wrote: ↑Sat Feb 01, 2025 6:59 am On a quick inspection, the "(!)NOT FOUND" patches all seem to be flats, and they are in the FLATS namespace in the WAD. These should not be added as textures via the PNAMES and TEXTURE1 tables/database. They should just work as resources that you can use on walls or floors with them just being in the WAD, in the correct format and in the correct namespace. (Originally, they were just for floors/ceilings in the original Doom and had to be used for that, and nothing else.) Trying to add them the the patches and texture tables is not suitable.
Yeah I used to work with DCK 1.1 back in the days, so I remember the limitations of flats. Which is one of the reason I wanted to move to udmf, so I can use textures more freely. Having animated fan textures on walls and not just floor and ceiling, and aligning them etc. Not using UDMF for polyobjects, slopes or 3D floors. Not even dynamic lightning, as I want the visual feel of an old doom game, but with some of the functionality you had in Hexen etc.

Oh well, I digress. I did not know that about not adding flats to texture tables. Actually not even sure what pnames and patches do in practice. But that's good to know. I was however confused as to not finding a convert option like Convert to Doom (flats) in SLADE. Does that matter?

Patch STILLFAN cannot be found in any open archiveYou should be able to take them out of the patches/texture tables and use them without any further changes.
If you want them to act as textures for some reason, then they should be converted to a suitable format (either a Doom graphic, or a PNG), and placed in the correct namespace for that format.[/quote]

The last line doesn't seem necessary with UDMF, as it can use flats as textures and vice versa if need be.
Enjay wrote: ↑Sat Feb 01, 2025 6:59 amAs a side thing to consider, seeing as how this is now a UDMF GZDoom project and Boom compatibility isn't important: your WAD (while not the worst, not by a long way) is a bit messy because of how it has been constructed using different resources from different places. I would consider changing it to a PK3. IMO, that helps keep things ordered because you put things in the correct namespace by putting them in the correct folder within the PK3. It's a quite deliberate, and well-defined act to do so. It would be a bit of work to do it, but not a huge amount.

https://zdoom.org/wiki/Using_ZIPs_as_WAD_replacement

You don't even have to use any special tools to make a PK3 either. In fact, you can just use a folder with the correct internal structure and have the folder with all the files loose (but in their correct sub folders) and load the folder into GZDoom. So, you are just moving files around as you would with any other files in Windows Explorer. Them when you are done, you can zip the whole thing up and rename it to PK3.
Nice, that sounds simple enough if I decide to go that route. At least if I were working from scratch.
Enjay wrote: ↑Sat Feb 01, 2025 6:59 amI would also consider getting rid of the old, arcane lumps like ANIMATED, SWITCHES and SWANTBLS and including their contents in your ANIMDEFS lump which is a modern, easier to read, easier to edit, GZDoom format text lump. Again, a bit of work, but not too much. For what it's worth, SLADE can also convert the old TEXTURE and PNAMES lumps into modern TEXTURES.txt lumps too. Again, modern, easier to read and edit IMO. If, however, any of you textures are just single patch textures (as many are) then you can just make them act as textures by putting them in the correct namespace (between TX_ markers in a WAD, or in a textures folder in a PK3). Again, they would need to be in Doom graphics or PNG format for that, not FLAT.
Didn't I already change them to be between TX_markers? Maybe I didn't with the new batch of textures I added manually from Legacy of Rust.


Enjay wrote: ↑Sat Feb 01, 2025 6:59 amOK, digging a bit further, there are more problems. I only looked at the ones near the end of your textures list (the ones in your screenshot). A LOT of your textures are invalid or reference either unsuitable or missing patches. Look at the BFALL and BIGBRIK textures for example, most of them are referencing sky pictures!

Lots of textures, and I mean lots of textures, reference invalid/missing patches. Very commonly these are patches that have names like INVPATCH2405 (according to SLADE). I don't even know how that happened because the names are too long for the WAD format. The names actually look as if they might have been generated by some sort of checking/validation process at some point and somehow got baked into the texture1 lump.

Basically, your texture database is, to put it technically, well-borked.
Somehow I am not surprised, and feared this.
Enjay wrote: ↑Sat Feb 01, 2025 6:59 amI'll attach a copy of the error report from SLADE because it's waaay too long to include in the post.
Reports like "Patch MFLR9_8 cannot be found in any open archive" seems to be the type of error coming from those Legacy of Rust and a few other custom textures I added in. But all those work in editor and in GZDoom somehow.

Reports like "Texture WOODOLD contains invalid/unknown patch INVPATCH2678" seems to be the initial borked up error that makes some textures not showing up in GZDoom. Some of those listed with that show up (like all those from the Gothic textures pack named ADEL_xxx), while many others don't.
Enjay wrote: ↑Sat Feb 01, 2025 8:20 am Interesting, I just opened your WAD in DeePsea and the Texture1 lump seems far less borked there. Many of the textures that did not look right in SLADE look OK in DeePSea (BFALL etc), but quite a lot of the textures that seemed to be referencing FLATs were referencing real patches, albeit the wrong patches. So, I don't know which of the editing tools is giving the most accurate picture. Neither is showing a particularly usable set of textures.

I think it still comes down to the TEXTURE1 and PNAMES databases getting mashed somehow during the import process. And my suggestion to start the import from scratch again still stands.

For what it's worth, the DeePsea error report is much shorter and quite different. It also clearly isn't flagging up some of the problems that SLADE reported, or which I noticed just by eye.


*** 342 Textures not completely covered by patches ***

*** 16 duplicate TEXTURE names found ***

== Checking 2686 PNAMES for duplicates ==

There are no duplicate PNAMES names
This feels more close to what conflicts I'm experiencing ingame more than the SLADE report did though. So much I can tell.
Enjay wrote: ↑Sat Feb 01, 2025 8:20 amEdit: as an additional thought - and I hate that I am suggesting this, because it's bad practice and I have a real aversion to it - you might find it easier to delete from your WAD all of the textures that you got from the various texture resource wads. Then you could package things up as a PK3 (as discussed already), with your maps in a maps folder, any other lumps in a suitable location, but just package the texture resource WADs that you have been using in the root folder of your PK3. Assuming those resource wads are correctly formatted, that should work, and you can also load them separately in GZDoomBuilder while you work on the maps.

Like I said, it's bad practice because of how GZDoom has to handle embedded WADs like that, but it might be a simple solution to get you going.
I'm an conservative man and I kinda like the WAD format. I mean ".pk3", that sounds so Gen Z don't you think? But yes, I hear you. Of course it makes things look better sorting in subfolders. It's really strange to me Carmack who is known to love aestethically clean solutions in code and whatnot were fine with the WAD format. Maybe it was efficient back then, what do I know.

But I have a few questions regarding that. Of course moving things into folders will be easier to work with when editing in a way, rather than the way it is. But some of the other resources I use, weapons, decoration, enemies are most from Realm 667 and they come in both wad and pk3 formats. How do I do with them?

You mentioned earlier (didn't wuote that part I think), that I should delete Texture1 and Pnames and rebuild them. Will that mess up my maps? I mean as long as I use the same texture names, will they apply? Same question goes for changing to pk.3 from scratch.

And thanks for all the advice so far! Much appreciated.
Top
User avatar
Enjay
 
 
Posts: 26878
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland

Re: (Some) Custom textures not showing in GzDoom but showing in UDB

Post by Enjay »

IgnyteZero wrote: ↑Sat Feb 01, 2025 12:33 pm Yeah I used to work with DCK 1.1 back in the days, so I remember the limitations of flats.
I go right back to the original DEU. It's been a long journey. ;)
Oh well, I digress. I did not know that about not adding flats to texture tables. Actually not even sure what pnames and patches do in practice. But that's good to know. I was however confused as to not finding a convert option like Convert to Doom (flats) in SLADE. Does that matter?
My understanding is that TEXTURE1 and PNAMES was a cunning way to save space back when that was important. Put a graphic in the WAD and enter it into the PNAMES table. Now you can construct as many textures as you like by referencing the entry in the PNAMES without having to duplicate the much bigger graphic lump. Even by the time Doom2 came out, iD were getting a bit lazy on that though as several textures that could have used that system didn't.

Slade should allow you to convert FLATS to other graphics formats though. They are a special format and do not work like regular graphics, even the Doom native graphics format.
https://zdoom.org/wiki/Flat

The last line doesn't seem necessary with UDMF, as it can use flats as textures and vice versa if need be.
Agreed. That why I said you could do it if you wanted to for some reason. However, properly inserted flats should work just as you say.
BTW, it's not actually a UDMF thing. This ability was added to ZDoom long before UDMF was a thing. Although, obviously, the ability is there in UDMF.
Didn't I already change them to be between TX_markers? Maybe I didn't with the new batch of textures I added manually from Legacy of Rust.
Actually, yes, I think that you did with most. But that's actually a problem. Putting them between TX_ markers means that you have told GZDoom to treat them as textures (you have put them into the textures namespace, same as putting them into a textures folder in a PK3). If you do that, there is no further need to add them to a PNAMES or TEXTURE1 lump anyway. They should just work. Adding them to those lumps *may* even cause a problem. In fact, that could explain some of the errors - the PNAMES lump is looking for patches, and by putting them between TX_ lumps, you've said "these are textures, not patches."

This feels more close to what conflicts I'm experiencing ingame more than the SLADE report did though. So much I can tell.
Yes, I thought it looked closer to what was being seen in game.
I'm an conservative man and I kinda like the WAD format. I mean ".pk3", that sounds so Gen Z don't you think? But yes, I hear you. Of course it makes things look better sorting in subfolders. It's really strange to me Carmack who is known to love aestethically clean solutions in code and whatnot were fine with the WAD format. Maybe it was efficient back then, what do I know.
:lol:
Probably just that: a format that worked well for for what iD wanted. Also, at the time, zip files were still relatively young and, I dunno, maybe the extra load of having to decompress files while loading might have caused problems on 1993 machines.
Of course moving things into folders will be easier to work with when editing in a way, rather than the way it is. But some of the other resources I use, weapons, decoration, enemies are most from Realm 667 and they come in both wad and pk3 formats. How do I do with them?
It's pretty straight forward. The PK3 system supports all the same lump formats that are present in the original WAD format. So, for either a WAD or a PK3, you can extract the relevant lumps and dump them into the appropriate part of the folder structure of your own PK3. Sprites in a sprites folder, sounds in the sounds folder and so on. That's it. If they are in the right place, they should work. There are even nice things like GZDoom being sub-folder blind. What I mean by that is you can have, say, a sprites folder and then a separate sub-folder for all the different enemies. GZDoom won't care, if the sprites are there, it will read them all, provided they are within in the sprites folder. The only thing to be aware of is that this can leave you open to accidentally putting two different files with the same name into different sub-folders. GZDoom will only use the last one that it loads in game.
You mentioned earlier (didn't wuote that part I think), that I should delete Texture1 and Pnames and rebuild them. Will that mess up my maps? I mean as long as I use the same texture names, will they apply? Same question goes for changing to pk.3 from scratch.
I mean, your textures lump is borked anyway. ;)
But, yes, provided you use the same names, your maps should be fine. Much of the map data relating to textures/flats is just references to named resources. The names are baked into the map, but that's all - just references to names (in fact, with UDMF being a text format, you can go in and read them if you really want). Part of the sidedefs of the lines are just references to texture names. As long as a texture (in any format) is present, it will be shown on that sidedef in game. It doesn't even matter which format. If you had an original style PNAMES TEXTURE1 entry called COOLTEX1 and deleted it from the TEXTURE1 and PNAMES lump, and then just shoved a PNG called COOLTEX1.png into a Textures folder, GZDoom would use that without any changes needed to the map.

The only time where something might have messed up is if you have allocated a texture with a broken setup to a wall, when you fix the texture definition, what appears in game may look different. However, if your maps pre-date your consolidation of the resources, and you haven't made much in the way of changes to them, they should still all have the references to textures that worked when you made the maps. So, recreating a legitimate set of textures (by whatever method) should be fine.

Basically, your maps should be fine, and you have the original source for the textures. So, it should be possible to reconstruct things reasonably quickly, and get things working. It's a bit fiddly, especially if you are unfamiliar with how some of it works, but it's certainly doable.
And thanks for all the advice so far! Much appreciated.
No problem. :) Feel free to keep asking. I know it might feel like things are a bit messed up, but it just requires a bit of reasonably straight-forward work to get a working file.

I think I've answered all the important questions - I accidentally deleted part of my post. :oops:
Top
User avatar
Enjay
 
 
Posts: 26878
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland

Re: (Some) Custom textures not showing in GzDoom but showing in UDB

Post by Enjay »

BTW, after you have the textures problem sorted, there are a handful of minor problems elsewhere.

If you turn on developer mode in the console (type developer 2 and restart) you'll see the following:
Spoiler:
So, those are things to look into at some point. All pretty minor stuff, but worth fixing for a tidy project.
Let's get the textures sorted first though. ;)

edit: Oh, while thinking about that, if you do still want to go the route of merging different TEXTURE1 lumps , I've always found DeePSea very good at doing it. SLADE does a fine job too of course, but I like how DeePsea does it. The program is old and clunks around the edges - definitely not a modern program, and struggles a bit on modern OSs, but its ability to merge WADs with different texture lumps is good. https://www.sbsoftware.com/
Top
IgnyteZero
Posts: 18
Joined: Thu Jan 16, 2025 12:17 pm
Operating System Version (Optional): Windows 10

Re: (Some) Custom textures not showing in GzDoom but showing in UDB

Post by IgnyteZero »

Enjay wrote: ↑Sat Feb 01, 2025 1:41 pm BTW, after you have the textures problem sorted, there are a handful of minor problems elsewhere.

If you turn on developer mode in the console (type developer 2 and restart) you'll see the following:

----

So, those are things to look into at some point. All pretty minor stuff, but worth fixing for a tidy project.
Let's get the textures sorted first though. ;)

edit: Oh, while thinking about that, if you do still want to go the route of merging different TEXTURE1 lumps , I've always found DeePSea very good at doing it. SLADE does a fine job too of course, but I like how DeePsea does it. The program is old and clunks around the edges - definitely not a modern program, and struggles a bit on modern OSs, but its ability to merge WADs with different texture lumps is good. https://www.sbsoftware.com/
Oh thanks. Yeah, I'll definitely check up on that. Error and conflict free is the preferred way to go even if it's minor stuff. But not a priority atm.

Never heard of DeePSea. Sounds like AI stuff by name, but if it's old I guess it's not. I'll download it and give it a whirl!

Edit:
One thing I wish existed though was a tool that can go through a WAD/pk3 and remove any texture/flat not used in any map therein. While havign the options while creating, having any surplus weight removed afterwards would be nice. But doing that manually is a headache.
Top
IgnyteZero
Posts: 18
Joined: Thu Jan 16, 2025 12:17 pm
Operating System Version (Optional): Windows 10

Re: (Some) Custom textures not showing in GzDoom but showing in UDB

Post by IgnyteZero »

Enjay wrote: ↑Sat Feb 01, 2025 1:29 pm
Agreed. That why I said you could do it if you wanted to for some reason. However, properly inserted flats should work just as you say.
BTW, it's not actually a UDMF thing. This ability was added to ZDoom long before UDMF was a thing. Although, obviously, the ability is there in UDMF.
Didn't I already change them to be between TX_markers? Maybe I didn't with the new batch of textures I added manually from Legacy of Rust.
Actually, yes, I think that you did with most. But that's actually a problem. Putting them between TX_ markers means that you have told GZDoom to treat them as textures (you have put them into the textures namespace, same as putting them into a textures folder in a PK3). If you do that, there is no further need to add them to a PNAMES or TEXTURE1 lump anyway. They should just work. Adding them to those lumps *may* even cause a problem. In fact, that could explain some of the errors - the PNAMES lump is looking for patches, and by putting them between TX_ lumps, you've said "these are textures, not patches."
Aaaaaah. I see. The more you know.
Enjay wrote: ↑Sat Feb 01, 2025 1:29 pm :lol:
Probably just that: a format that worked well for for what iD wanted. Also, at the time, zip files were still relatively young and, I dunno, maybe the extra load of having to decompress files while loading might have caused problems on 1993 machines.
Makes a lot of sense.

Enjay wrote: ↑Sat Feb 01, 2025 1:29 pmIt's pretty straight forward. The PK3 system supports all the same lump formats that are present in the original WAD format. So, for either a WAD or a PK3, you can extract the relevant lumps and dump them into the appropriate part of the folder structure of your own PK3. Sprites in a sprites folder, sounds in the sounds folder and so on. That's it. If they are in the right place, they should work. There are even nice things like GZDoom being sub-folder blind. What I mean by that is you can have, say, a sprites folder and then a separate sub-folder for all the different enemies. GZDoom won't care, if the sprites are there, it will read them all, provided they are within in the sprites folder. The only thing to be aware of is that this can leave you open to accidentally putting two different files with the same name into different sub-folders. GZDoom will only use the last one that it loads in game.
Yeah, I've noticed the last loaded part. That is good info though. Maybe I'll sort it all into a pk3 eventually then.


Enjay wrote: ↑Sat Feb 01, 2025 1:29 pmI mean, your textures lump is borked anyway. ;)
Lol
Very true. And I have several backups.
Enjay wrote: ↑Sat Feb 01, 2025 1:29 pmBut, yes, provided you use the same names, your maps should be fine. Much of the map data relating to textures/flats is just references to named resources. The names are baked into the map, but that's all - just references to names (in fact, with UDMF being a text format, you can go in and read them if you really want). Part of the sidedefs of the lines are just references to texture names. As long as a texture (in any format) is present, it will be shown on that sidedef in game. It doesn't even matter which format. If you had an original style PNAMES TEXTURE1 entry called COOLTEX1 and deleted it from the TEXTURE1 and PNAMES lump, and then just shoved a PNG called COOLTEX1.png into a Textures folder, GZDoom would use that without any changes needed to the map.

The only time where something might have messed up is if you have allocated a texture with a broken setup to a wall, when you fix the texture definition, what appears in game may look different. However, if your maps pre-date your consolidation of the resources, and you haven't made much in the way of changes to them, they should still all have the references to textures that worked when you made the maps. So, recreating a legitimate set of textures (by whatever method) should be fine.

Basically, your maps should be fine, and you have the original source for the textures. So, it should be possible to reconstruct things reasonably quickly, and get things working. It's a bit fiddly, especially if you are unfamiliar with how some of it works, but it's certainly doable.
Gotcha! :)

Enjay wrote: ↑Sat Feb 01, 2025 1:29 pm I think I've answered all the important questions - I accidentally deleted part of my post. :oops:
Yeah I'm good I think :)
Top
User avatar
Enjay
 
 
Posts: 26878
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland

Re: (Some) Custom textures not showing in GzDoom but showing in UDB

Post by Enjay »

IgnyteZero wrote: ↑Sat Feb 01, 2025 2:48 pm Yeah I'm good I think :)
Excellent. :thumb:
Top

Return to “Assets (and other stuff)”