self-referencing texture warning - should it be?

[Enjay]

More of a question than a bug report, but I wasn't sure where else to put this and it could be something to address so...

Sparked from a discussion here: viewtopic.php?f=19&t=47573&p=1073712#p1073712

If a texture is defined in the TEXTURES lump like so

Code: Select all

WallTexture "HOUS11", 64, 128
{
   Patch "HOUS11", 0, 0
}

i.e. the texture has the same name as the patch contained within it, then GZDoom will give a warning with developer messages active:

Code: Select all

Resolved self-referencing texture by picking an older entry for HOUS11

I'm just wondering if it should be? It is very common for mods using the older TEXTURE1 format to have textures defined that way (many of the old lump editing utils would take a graphic, stick it in a WAD and define a TEXTURE1 and PNAMES entry for it from the file name). GZDoom does not give an error for TEXTURE1 textures in this format. However, it does for TEXTURES format ones.

SLADE creates TEXTURES entries of this type using the "add to TEXTURES" feature (that's how the ones in the above linked thread were made) and anyone converting a TEXTURE1 lump to the TEXTURES format would also come across this.

TEXTURES lumps of this format are very likely to be in the wild and given that TEXTURES lumps tend to be extensive, the warnings could be part of a very long list that might mask other issues. I wonder should it be getting warned about in this way?

Of course, if there is something potentially harmful in a TEXTURES entry of that format then the warning is justified. (If there is a problem, could I get an explanation of what that problem is for my own knowledge please?)

[Graf Zahl]

Yes, it should be. This means that you essentially have a texture definition error and no patch with the given name could be found. In that case the last defined texture of any type will be picked, which in this case is the one you were defining.

There are tons of old WADS which would suffer from this and none emit this warning if their texture definitions are converted.

[Enjay]

There are tons of old WADS which would suffer from this and none emit this warning if their texture definitions are converted.

Maybe we are talking about a different conversion? Perhaps you mean the engine is performing a conversion internally? I meant if a modder uses SLADE to convert an existing TEXTURE1 lump to TEXTURES. I just tried using SLADE to convert a WAD with a TEXTURE1 lump that gives no warnings to the TEXTURES format and got loads of warnings with a slightly different error message to the one above.

(just picking one of the warnings at random - there were thousands of them)

Code: Select all

Script warning, "test.WAD:TEXTURES" line 3955:
Texture 'DOORWHT7' references itself as patch

The texture definition as produced by SLADE:

Code: Select all

Texture "DOORWHT1", 8, 128
{
	Patch "DOORWHT1", 0, 0
}

I do see the logic of the error though.

[edit]
I just realised the above warning was given when I hadn't loaded the actual patches. Putting the relevant patch into the test WAD, the warning changed to:

Code: Select all

Resolved self-referencing texture by picking an older entry for DOORWHT1

i.e. same as before.

[Graf Zahl]

Where do you put the patch?

[Enjay]

In the above example, it was a WAD file, so it was just in the WAD (it was just a quick and dirty test so I hadn't put any P_START markers in). I forget where the patches are in the Ashes PK3 (although the list of warnings included textures in the PK3 and the separate WAD for the maps). I've also seen an example where the "patch" was in the graphics folder rather than the patches one.

I'm on my phone right now so I can't check any files but I can when I get home from work. I'll see if things change at all depending on patch location.

[Enjay]

Update: if I put the patch in the patches folder of a pk3, GZDoom does not throw up a warning when loading a texture of this type.

With a WAD, however, even if the patch is between P_START/P_END (or PP_START/PP_END) markers, the warning will appear.

I've attached a sample file for a quick check. Inside the zip are two files; a WAD and a PK3. Both have exactly the same TEXTURES lump. The PK3 has a patches folder with the patch in it (as a PNG). The WAD has a Doom graphics format version of the patch between P_* markers (I got the same result with a PNG in the WAD too). When loading, the PK3 does not give the warning, the WAD does.

texturetest.zip

So, defining in a texture with the same name as its patch will not throw up a warning if the patch is in a patches folder of a PK3. However, it will throw up a warning if the patch is in a WAD (inside P_* markers or not).
This seems to be an inconsistency at least, if not an outright bug.

[Enjay]

Additional:

I tried a further test. I put the patch in a graphics folder inside a PK3 (instead of a patches one) and, not surprisingly, the warning came back. I thought that changing the TEXTURES lump to read:

Code: Select all

Graphic "METBRUIS", 64, 128
{
   Graphic "METBRUIS", 0, 0
}

might silence the warning but it didn't.

I then repeated this with a sprites folder and changing the TEXTURES lump to have the word "Sprite" wherever "Graphic" appears above. Again, I still got the warning. Perhaps having these inside those folders means they are already considered to be of that type and do not need to be defined again?

Anyway, putting the patch back in the patches folder and changing the TEXTURES to read:

Code: Select all

Graphic "METBRUIS", 64, 128
{
   Patch "METBRUIS", 0, 0
}

Again silenced the warning.

So, the only way I have found of not getting a warning when defining a Graphic or Sprite with a "patch" of the same name as the graphic/sprite is to put the image lump into the patches folder and to call it a patch in the graphic/sprite definition. All other combinations that I tried (and I think I tried them all) gave the warning. I don't know if this should be considered a problem or not.

[Graf Zahl]

No, it's not a problem. It's a clear sign to you that what you tried to do is not the correct way. If you define a texture with the same name and the same namespace, that texture will always hide the patch you intend to reference and therefore trigger the substitution logic that prints the warning.

The correct way here is to put the patch into "patches". If that's not possible, do not use the same name for both the patch and the defined texture.
Before the warning was added, this would have caused some circular logic resulting in a crash.

[Enjay]

Fair enough.

But what about the WAD situation where being between P_* markers doesn't prevent the warning? Is that just because the P_* aren't really required in the first place within a WAD? (I'm assuming that the original Doom logic is something like if it is a graphic and not between F_* or S_* markers, it's eligible to be considered a patch and that P_* markers are merely a convenience/convention?)

[Graf Zahl]

That shouldn't happen - the problem is most likely that the engine does not know it is a patch.
But why are you so hung up on giving both the same name?

[Enjay]

I'm not really - not for a new mod from scratch anyway. I just know that there are mods out there that already do so, lump management tools seem to do it by default* and anyone converting a traditional TEXTURE1 mod to a modern TEXTURES format is likely to come across literally hundreds, if not thousands, of entries in their texture definitions where this is the case.

*for example, anyone using SLADE to generate a hundred texture definitions from existing patches in one go would then have to go back and edit the texture names of all 100 textures manually.