[Solved] Texture not found using changefloor()

[Ty Halderman]

I'm having a problem with script-modified animated flats.

Script sort of works like this:

1. Floor is 0fcomp1n, animated 1n-4n
2. Something Happens
3. Script uses changefloor(n,"0fcomp0n"); // turned off
4. Something Else Happens
5. Script uses changefloor(n,"0fcomp1n"); // back on
6. ZDoom says "Unknown texture: 0fcomp1n"

Zdoom lies.

Error message is from FTextureManager::GetTexture. The hash routine doesn't find the texture on the first hit, or it isn't of the right type, or something. Hash returns 65535 so that's the only test. I imagine it finds it but doesn't think it's the right texture type.

The only oddity might be that this is an animated flat that is subsequently used in scripting to change the floor. I am using a Boom SWANTBLS file to create SWITCHES and ANIMATED lumps, not ANIMDEFS, if that makes a difference.

I could go find the docs on ANIMDEFS (help?) and convert my stuff to that, but I think Boom compatibility is still desired (and for that matter, ANIMDEFS might not work either--don't know yet).

[Hirogen2]

http://zdoom.sourceforge.net/reference/animdefs.html

[Ty Halderman]

Yeah, thanks, Hirogen2. I had that but I knew that there were enhancements (allowdecals, stuff like that) since and was hoping there was a current summary.

[Ty Halderman]

Followup: Same problem after moving everything to ANIMDEFS. It's got to be some sort of problem with using changefloor() with an animated texture. This worked fine in 47i, broken since the newer releases. Just tested 49 and 52 to be sure.

[randi]

Any animated texture or just certain ones? Does the texture still change when it reports it's unknown?

[Ty Halderman]

This particular script just was concerned with that one 0fcomp1n, which is the first of a 4-frame animation. As it complains, it switches the flat texture in question to the checkerboard "not found" pattern. It successfully switches back to static texture 0fcomp0n periodically, so it's specific to the animated one.

[Ty Halderman]

I just traced this as it happened, and it's a bit more convoluted than I thought. Abbreviatedly this is what's going on:

Code: Select all

FTextureManager::CheckForTexture
{
	...
	i = HashFirst[MakeKey (name) % HASH_SIZE];

	while (i != HASH_END) 
	{
		const FTexture *tex = Textures[i].Texture;

		// first time through finds another texture

		if (stricmp (tex->Name, name) == 0)
		{
			...
		}
		i = Textures[i].HashNext;

		// this never finds another hash in the chain
		// after the first mismatch
	}
	...
	return -1;
}

I don't know if it's something in the hash routine that's not putting this texture in the chain or what--the type is right (2=TEX_Flat) and that's what's being searched for.

Hope this helps--I'm lost

[randi]

I'm not so sure it's anything to do with the texture being animated, since that doesn't matter until it comes time to actually render it. I think it's just coincidence that you experienced this with an animated texture.

To illustrate, this hideous example works just fine switching the floor to an animated texture. So, you'll need to come up with a test case that exhibits this bug.

[Edit: Don't need the attachment anymore.]

[Ty Halderman]

Just thought of something when I saw your example. Is it a problem if the texture name is the same as one of the pics? This is the kind of thing I've got in ANIMDEFS:

texture 0fcomp1n

• pic 0fcomp1n tics 8
  pic 0fcomp2n tics 8
  pic 0fcomp3n tics 8
  pic 0fcomp4n tics 8

Note that I didn't do anything on my end for this to start happening since 47i, and it works the same way whether the above definition is done this way in ANIMDEFS or if I do it in SWANTBLS style.

I'm okay with new rules that say I can't do that and will change it--I just need to know which way to go.

[randi]

No, there's nothing wrong with using the same texture name in the animation as the animation is defined for. There's also nothing wrong with using the same texture more than once in a single animation.

To confirm whether the animation is really the problem, take out the animation for 0fcomp1n and see what happens. I bet it still won't work.

[Ty Halderman]

Oh, poo.

Okay, let's rephrase the problem definition . If you specify a texture with a trailing space in 2.0.47i, it works. In later versions, it fails:

Code: Select all

changefloor (n,"0fcomp1n "); <--- worked in 47i, not later

delete the space

changefloor (n,"0fcomp1n");  <---- works in all versions

A typo in our script, in other words. I don't know if you want to trim texture strings or not during hashing/storing/searching. The result was that after 47i it could no longer find it in the hash table.

I think we should use big blobs to represent spaces so we'd notice them!

[randi]

Yay! You solved it. I'll put quotation marks around the texture name in the unknown texture message so this should be more obvious in the future.