weird patch/texture bug

[hex11]

In the most recent /newstuff reviews, kashimir.wad looks okay with id's doom2.wad but under Freedoom there is lots of texture strangeness:
http://www.doomworld.com/vb/showthread.php?s=&postid=983922

I don't understand what the warning "R_GenerateLookup: column without a patch (xxxxxxxx)" signifies, but it gets printed to console several hundred times.

[boris]

I'd say the problem is that kashimir.wad comes with a new TEXTURE1 lump, but not with a PNAMES lump, so it's using different (wrong) patches to build the texture.

[fraggle]

Realistically I guess there are always going to be a few WADs that don't play properly under Freedoom. Boris's explanation sounds plausible. I guess theoretically we could construct the PNAMES lump so that the ordering of patches matches that from doom2.wad.

EDIT: After some more investigation, it seems that deutex doesn't preserve the order of patches as they appear in wadinfo.txt - they just appear in a random order in PNAMES. So I'd have to write a script to manually generate a PNAMES lump.

Ideally TEXTURE1 should be sorted in the same way (textures as they appear in doom2.wad at the start, added textures at the end). I think this might potentially affect multiplayer ports when playing between doom2.wad and Freedoom.

[Catoptromancy]

http://www.doomworld.com/vb/freedoom/52810-pnames-wad-for-freedoom/

All the effort to rescript deutex or whatever needs done will only affect a dozen wads.

[hex11]

So then, the majority of PWADs in /idgames that have a TEXTURES1 also contain a PNAMES lump? And if that is the case, is there something peculiar about his editing tools which explains this deviation?

Editor(s) used : Doom Builder 1.68, XWE

It's worth noting that kashimir.wad was just released, so there may be more situations like this in the future.

But at least prepending cct.wad to the -file arguments acts as a workaround. This is what the map looks like otherwise:







The "gradient" sky in the last two pics is especially trippy. Goes well with the music. ;)

[fraggle]

hex11 said:

So then, the majority of PWADs in /idgames that have a TEXTURES1 also contain a PNAMES lump? And if that is the case, is there something peculiar about his editing tools which explains this deviation?

Generally speaking, having one without the other is a pretty bad idea. I don't know what tools were used to generate this WAD, TEXTURE1 and PNAMES are pretty closely intertwined, so it's hard to imagine one that could edit one without the other.

[GreyGhost]

I REALLY must try to type faster.

fraggle said:

After some more investigation, it seems that deutex doesn't preserve the order of patches as they appear in wadinfo.txt - they just appear in a random order in PNAMES. So I'd have to write a script to manually generate a PNAMES lump.

Ideally TEXTURE1 should be sorted in the same way (textures as they appear in doom2.wad at the start, added textures at the end). I think this might potentially affect multiplayer ports when playing between doom2.wad and Freedoom.

Random indeed. A quiet browse through the retail IWADs suggests to me that the PNAMES lump is derived from the TEXTURE* lump/s. It's a pity DeuTex doesn't do things that way. :(

hex11 said:

So then, the majority of PWADs in /idgames that have a TEXTURES1 also contain a PNAMES lump? And if that is the case, is there something peculiar about his editing tools which explains this deviation?

Nothing wrong with those tools. The author decided to replace some existing patches instead of defining new ones, which means no changes would have been made to the PNAMES lump - making it's inclusion unnecessary if you're playing with id's IWAD. Adding a PNAMES lump cures the problem with Freedoom - until you get to Map02.

[boris]

Only editing TEXTURE1 can be useful if you want to create new textures with the existing patches, like makeing a new door texture with a radiation sign on it or whatever. However, in kashmir.wad no new textures are defined, just some patches are replaced. The TEXTURE1 lump seems to be exactly the same one from doom2.wad. I didn't do a checksum, but removing the TEXTURE1 lump makes the level look normal in Freedoom.

GreyGhost said:

Adding a PNAMES lump cures the problem with Freedoom - until you get to Map02.

What do you mean? Map02 looks fine.

Does the PNAMES lump server any purpose, besides saving some disk space? Maybe just a relic from eariler Doom builds?

[Memfis]

The TEXTURE1 lump seems to be exactly the same one from doom2.wad.

Not exactly. I've changed the width of ZZZFACE1 and ZZZFACE2.

[boris]

Memfis said:

Not exactly. I've changed the width of ZZZFACE1 and ZZZFACE2.

You are right, removing the TEXTURE1 lump results in incomplete textures, I just didn't notice it at the first glance.

[wesleyjohnson]

Somewhat similar to when I asked about Caesar.wad. My solution was to load gothic.wad or gothic2.wad also, which apparently has the PNAMES lump. It made Caesar.wad work.

[fraggle]

If I get the time I can probably hand-craft a TEXTURE1/PNAMES generator script.