Substantially increase lump name character limit >8

[JPL]

8 character lump names is a holdover from the DOS days, but recently as I put together a PK3 I've noticed it results in large directories full of names that are way more difficult for humans to distinguish. "manor_wall_bookshelf" becomes MWBKSHLF, for example. Individually these abbreviations are human parse-able, but when you have a lot of them with similar names, as is common when textures are grouped into sets, the chances of making a mistake when typing in TEXTURES def data increases a lot, and making updates to content in WADs/PK3s is more painful. Increasing the name limit from 8 to 64 would help a lot.

I tried making this change in the files ZDoom's codebase that seem relevant and got lots of segfaults on launch, as I'm not as knowledgable with the code yet. I can easily imagine that the resource loading code has a lot of nuances and back-compatibility might be an issue, but I think this change would really help modders like me.

[Graf Zahl]

If it was that easy...

The big problem are textures. The entire code is so littered with assumptions that texture names are limited to 8 characters that it's a hopeless undertaking trying to change it.
Most other stuff can already use full file names - sounds and music for example. But since 90% of all new stuff ends up as a texture...

[Nash]

This would be nice to have but I imagine it requires major reworking of everything. Sprites, textures, graphics, fonts, ACS scripts/libraries... heck just about everything I guess.

[Gez]

Sprites are really tied to their 4444-1-1-[1-1] convention, there's no way around it.

Take advantage of PK3 format to organize resources in subdirectories. MWBKSHLF can become textures/manor/wall/MWBKSHLF. It makes it a bit easier to manage because you get less files per directory.

SLADE 3 has a visual TEXTURES editor. You can use it to "proofread" and fix your TEXTURES lump.

[Graf Zahl]

I think what could be done is to allow specifying full paths to graphics lumps in UDMF maps for textures - but I think that's really the limit. This would require special checks at precisely 5 points in the UDMF loader. Everything else is more or less a gamble.

[Nash]

Not trying to make this another "just" post but regarding sprites:

Assuming an effort would be made to expand on it; is it not possible to expand only the 4444 part, so you can use long filenames for sprites... then use delimiters to separate the long name and the other stuff (frame letter and angle)... ?

That was just something at the top of my head, heh, it probably won't translate well technically.

[Graf Zahl]

Sorry, but the sprite stuff is too rigidly tied to the naming scheme. Changing it may cause unforeseen problems.

[JPL]

Assuming an effort would be made to expand on it; is it not possible to expand only the 4444 part, so you can use long filenames for sprites... then use delimiters to separate the long name and the other stuff (frame letter and angle)... ?

My suggestion was mainly for lumps with more arbitrary names, eg textures and sounds and such like. The sprite naming scheme encodes a lot of information that's useful both to humans and to the engine, so while it's hard to read I don't consider it as much of a usability stumbling block as other lump types.

So, question for the devs: specifically regarding textures etc, if I were to lose my mind for a while and get this code change working, would you accept patches or would you categorically refuse them based on LoC + how much important code it would touch? I'd understand if it were the latter :]

[NeuralStunner]

Re: Sounds - Given that sounds are referenced by a name alias, it might actually be sane to support paths and long filenames in SndInfo. (I would make considerable use of that myself!)

[Graf Zahl]

SNDINFO has been supported full paths since ... forever...?

For textures, as I said, it's not that big a problem to add support for full file names to the UDMF texture field, but that's as far as I'd be willing to go. For everything else there'd be some non-trivial secondary issues to solve.
But if you find an approach that manages to solve this, be my guest. I'd be the last person to refuse a submission, provided that it's stable and doesn't break things, of course.

[JPL]

For textures, as I said, it's not that big a problem to add support for full file names to the UDMF texture field, but that's as far as I'd be willing to go. For everything else there'd be some non-trivial secondary issues to solve.

I think just that change would have a lot of value, for the reasons described in my first post. Thanks for considering it.

[NeuralStunner]

SNDINFO has been supported full paths since ... forever...?

Has it? I've never seen an example of such, nor does the wiki mention it at all. (It uses the term "lumpname" which is pretty narrow in meaning.)

SFor textures, as I said, it's not that big a problem to add support for full file names to the UDMF texture field, but that's as far as I'd be willing to go. For everything else there'd be some non-trivial secondary issues to solve.

Does this mean that TEXTURES is out? I imagine long filenames for patches would be OK, but do texture names have to be bound to 8 characters? (I do a lot of TEXTURES compositing/translating, so it's worth knowing how much use I could expect from this extension.)

[XutaWoo]

SNDINFO has been supported full paths since ... forever...?

Has it? I've never seen an example of such, nor does the wiki mention it at all. (It uses the term "lumpname" which is pretty narrow in meaning.)

I can confirm that I've poked through more than a few PK3s with over-eight sound names. It's not too common, but it definitely works.

[Graf Zahl]

SFor textures, as I said, it's not that big a problem to add support for full file names to the UDMF texture field, but that's as far as I'd be willing to go. For everything else there'd be some non-trivial secondary issues to solve.

Does this mean that TEXTURES is out? I imagine long filenames for patches would be OK, but do texture names have to be bound to 8 characters? (I do a lot of TEXTURES compositing/translating, so it's worth knowing how much use I could expect from this extension.)

To do TEXTURES, I'd have to change the handling of texture names globally.
To allow file names on texture fields in UDMF I'd have to add one function.

Totally different workload.
I'll have to investigate first what is possible but the main danger I see is that if the naming for textures is changed it may break some older mods depending on file name truncation. Don't forget: The entire lump/texture naming system inherently depends on the 8 character limit. Changing it without any need may cause some non-trivial issues. Better handle the one single place where it is most useful separately.

[Gez]

An alternative approach would be to do that on the editor side. Have a lump name <==> logical name mapping done in your configuration and the editor can show you the long and legible name in the map editor, while writing the short, compressed name to the map data.