[Engine Standard] External Texture names for MDL/SPR

[mh]

Right now there are two competing methods for naming external textures used by MDL (and SPR) files. Some engines just tack the frame number onto the end of the base name (example: s_light0.tga) whereas others use the full name, including extension (example: s_light.mdl_0.tga).

All engines should use the second method, and all content creators should use the second method too. Why?

Pop quiz time. If you used the first method and you had an image called "s_light0.tga", which texture would it replace?

The screenshot below (from ID1's pak0.pak) should give a hint:

[Spike]

use a particle effect for the shambler's lightning, and problem solved.
Alternatively you can use different texture paths for content, like models/*.tga for models and sprites/*.spr, which results in it potentially working on dos ports, the platform quake was originally released for.

what's more annoying is the identical names for differing textures in maps.

[Karatorian]

I'd say I'd have to agree with the OP. While I can see how having multiple dots in a filename might give some wimpy filesystems fits, I don't think it matters much on modern systems. Simply put, I'd favor clarity over the sort of kludges that stripping the extension causes. This one example in pak0.pak is reason enough, but there are sure to be more in the vast quantity of Q1 content out there.

The multiple textures in maps thing is indeed obnoxious, but I think it's possible to work around it. I believe the QRP has documented all concurrences of this in the standard Quake levels.

Per level texture overrides should be able to handle cases where different levels use the same name for different textures. (Although, of course, this needs to be standardized as well.)

Symbolic links would work nicely to solve the problem of multiple names being used for the same texture, if it weren't for the fact that a particular (popular, but garbage) OS doesn't support them. The QRP guys came up with the link file idea for this. I don't know how widely (if at all) this has been implemented, but I think it's a good workaround.

[mh]

Symbolic links would work nicely to solve the problem of multiple names being used for the same texture, if it weren't for the fact that a particular (popular, but garbage) OS doesn't support them.

It actually does, and has done since at least 2000. They're not called "symbolic links" and they work slightly different, but just because everything isn't the same as Weenix doesn't mean that it's "not supported" or "doesn't exist". Just saying.

[revelator]

goood ol nt junction points

cygwin has been using them to emulate symlinks on windows for ages

[mh]

Symlinks are useless in a PAK or PK3 anyway, so the argument immediately becomes bogus.

[dreadlorde]

Symbolic links suck anyway.

[Karatorian]

It actually does, and has done since at least 2000. They're not called "symbolic links" and they work slightly different, but just because everything isn't the same as Weenix doesn't mean that it's "not supported" or "doesn't exist". Just saying.

Hmm, this is the first I've heard of this. I thought they only supported hard links, which (in my opinion), are kinda evil. Then again, I'm probably wrong.

So, how do you make an NTFS symlink? That would be handy to know.

[Spike]

windows 2000 supports 'junctions', which are basically symlinks but limited to directories (you need to use tools which are not provided in windows, microsoft don't directly support such tools as recursion=crash).
windows vista adds support for reparse points. which can be configured in such a way that they mimic symlinks exactly, but I've no idea how to set that stuff up.

[mh]

...and there's actually a very good reason why.

http://blogs.msdn.com/b/oldnewthing/arc ... 00082.aspx

[Spike]

hard links have their uses, but symlinks are more useful. Either way, both sorts are evil when it comes to portability.
To be honest, ezquake is the only engine I know of that supports .LINK files. So look at it this way, if you support dp's naming system, you don't have to, but if you support ezquake's naming system, you need to support .LINK files too. :P

Someone made a tool at some point to add hardlinks inside pak files, which means that engines can just use whatever they want and the same pak will work with all (assuming the engine in question is able to distinguish between the two s_lights).
... Which sucks if you want to release your textures in a pk3.

[mh]

DirectQ supports .link files as well, but that's by the by; if they're not widely supported elsewhere they may as well not exist.

If we're talking about hacking a PAK file (presumably having two or more entries in the PAK directory have the same fileofs and filelen) we're definitely deep in the realms of complex, fiddly and prone to subtle bugs. Oh, the engine can handle it for sure, but can common PAK management tools? What happens if you unpack it? Etc?

To be honest, storage is cheap and ample these days and bandwidth is sufficient enough to make multiple instances of the same image having different names a complete non-issue.

[metlslime]

Per level texture overrides should be able to handle cases where different levels use the same name for different textures. (Although, of course, this needs to be standardized as well.)

There is an informal standard where you put the textures in a subfolder called "<mapname>" and they only get used when that map is loaded. We might as well use that unless there's some flaw in that system.

Of course, there is one more annoying issue which is that a few rare bsps have multiple textures with the same name, or a zero-length string as the name. My suggestion is we don't bother fixing that; content creators who want to use these features should avoid it, and it's actually hard to create such a bsp with standard tools.