ZDoom

Note that for MAPINFO, you can use the name ZMAPINFO to get an eight-char lump name. For GLDEFS, perhaps DOOMDEFS and co. still work. SNDINFO and MENUDEF, you're out of luck.


I will point out; however, that most text lumps do feature the ability to include other files. So you probably should be using that instead of relying on cumulative loading.

[quote="Enjay"]And to add to that (Please correct me if I'm wrong) gzdoom is looking for up to 8 letter lump names an is ignoring the characters after 8. So, a name like gldefs.sidekicks.gl is being treated as s file with the extension .gl and the lump name is being truncated to gldefs.s and that's not a name gzdoom recognises.[/quote]
Seems so. I was wrong saying that "GLDEFS.Something.txt" will work, it will not; the mod I tested this on has "include" directive in "main" GLDEFS lump (but "GLDEFS.Something" [b]will[/b] work). Actually, all lump names less than 8 chars (MENUDEF, SNDINFO, MAPINFO, ZSCRIPT, GLDEFS and probably some more I forgot) can't have long names like GLDEFS.MyMod.gl. It seems (correct me if I'm wrong) that parser finds extension (after the last '.'), truncates it and then if the remaining string is more than 8 chars, it truncates the string to 8 chars and tries to process this name as lump name (in above mentioned case it seems to be "GLDEFS.M").
So the feature I suggest is: if lump name was not recognized -> try to find a '.' in it and trunc in with everything to the right. So the "GLDEFS.M" will become "GLDEFS" and thus will work as planned.

And to add to that (Please correct me if I'm wrong) gzdoom is looking for up to 8 letter lump names an is ignoring the characters after 8. So, a name like gldefs.sidekicks.gl is being treated as s file with the extension .gl and the lump name is being truncated to gldefs.s and that's not a name gzdoom recognises.

The rule is in general that the extension starts with the last '.' in the name, not the first.

MENUDEF.txt
SNDINFO.txt
MAPINFO.txt

MENUDEF.Main.txt
SNDINFO.Blabs.txt
MAPINFO.Mymap.txt

DECORATE.New.Enemy.txt
Decaldef.Blood.Waterblood
GLDEFS.Sidekicks.gl

(Apologize if there is a reason behind the behavior I want to discuss.)
(Tested on GZDoom 3.7.1)

Without further ado, I have 'pk3' file. There are some lumps. GZDoom detects standard lump names (e.g. SNDINFO) and processes the file with that name like a sound definitions file. Also I can "extend" that file name and name it, say, SNDINFO.txt or SNDINFO.Enemies, and GZDoom will notice that SNDINFO.Enemies == SNDINFO lump. But if I name it, say, SNDINFO.Enemies.txt, it won't work. Unlike DECORATE files, that work even if named something like "DECORATE.Weapons.txt".

So, after some research, I've found that:
[code]MENUDEF.txt
SNDINFO.txt
MAPINFO.txt[/code]
will't be recognized, while:
[code]MENUDEF.Main.txt
SNDINFO.Blabs.txt
MAPINFO.Mymap.txt[/code]
won't be recognized.

And other lumps work fine, these all will be recognized by parser:
[code]DECORATE.New.Enemy.txt
Decaldef.Blood.Waterblood
GLDEFS.Sidekicks.gl[/code]

I wonder why such a restriction for that set of lumps, is it a "bug" or by intention?