Page 1 of 1

GZDoom lump names detection

PostPosted: Sat Jan 12, 2019 12:21 am
by Mere_Duke
(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: Select allExpand view
MENUDEF.txt
SNDINFO.txt
MAPINFO.txt

will't be recognized, while:
Code: Select allExpand view
MENUDEF.Main.txt
SNDINFO.Blabs.txt
MAPINFO.Mymap.txt

won't be recognized.

And other lumps work fine, these all will be recognized by parser:
Code: Select allExpand view
DECORATE.New.Enemy.txt
Decaldef.Blood.Waterblood
GLDEFS.Sidekicks.gl


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

Re: GZDoom lump names detection

PostPosted: Sat Jan 12, 2019 1:58 am
by Graf Zahl
The rule is in general that the extension starts with the last '.' in the name, not the first.

Re: GZDoom lump names detection

PostPosted: Sat Jan 12, 2019 5:18 am
by 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.

Re: GZDoom lump names detection

PostPosted: Sat Jan 12, 2019 8:51 am
by Mere_Duke
Enjay wrote: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.

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" will 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.

Re: GZDoom lump names detection

PostPosted: Sat Jan 12, 2019 9:47 am
by Gez
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.