Duke4.net Forums: Trouble with loadgrp directive (.DEF files) - Duke4.net Forums

I don't know if this is a bug or intended behaviour that I am supposed to work around, so perhaps some kind soul could explain where the .def language LOADGRP directive searches for group/zip files.

Supposed I have in a directory

A/xxxx.grp
A/B/yyyy.grp

and yyyy.grp includes a .def file that has a loadgrp directive requesting xxxx.grp.

I would expect eduke32 -gA/B/yyyy.grp -jA to allow the loadgrp command to find xxxx.grp. However, this does not seem to work. I thought maybe loadgrp searches the current directory from which eduke32 is launched or the same directory as the group file from which the .def file is loaded, but those don't work either. In fact, only having xxxx.grp in the same directory as yyyy.grp AND explicitly loading directory A/B with -j seems to do any good.

Now this is important as in Linux one is supposed to keep static data and dynamic data separate so using paths like that ought to work. In particular I do not want to have a "your duke3d directory" with everything including the kitchen sink and the cat's food bowl bunged in there, like in the evil bad days of Windows


So how exactly from a command line can I tell eduke32 the directories for a loadgrp directive to search for the file it requests?

I seem to recall loadgrp not working from within another GRP. It may only work from a file loose in a directory.

It may (or actually even should) work if the second file is not a grp file, but a zipfile. I used this trick in the addon compilation if an additional groupfile was needed. However, you have some restrictions in that case, e.g. art files wouldn't work if loaded from within a zipfile.
You would load the def file from the first groupfile which contains the loadgrp command for the second groupfile.

Example for a def file that does that (loadwide.def from WGRealms2):

loadgrp widescreen.dat   // Loads second file, in that case a zipfile with .dat ending
include wgrealms.def   // Load that def file from within widescreen.dat

Keep in mind that you cannot load con files with def, just in case you aren't aware of that.

Well in fact, it's my scripts that manage the AOC, as part of my overall DN3D library, that triggered this. I had examined examples like the above in the AOC and understood what they are trying to do and on seeing that, also looked up the Wiki entry for LOADGRP.

If I write a bash script equivalent to the Windows addons.bat script and put it alongside that then run that from the same directory, widescreen.dat loads fine. However any other method of loading widescreen.dat fails. My script resorts to scanning the readme file for the group file name and a "[w]" after it, and loading widescreen.dat explicitly with -g; but that's really a hack.

For clarity: I do not like the way modern engines provide an integrated file picker UI, and prefer to use the engine purely for running the game and under the control of a command line, so I can use my own UI or game launcher. It really annoys me when things happen behind my back due to arcane file loading conventions. Though I do understand this is necessary, as most people just want to play the game via a UI, I feel that stuff like LOADGRP should be fully documented or subject to the regular search path conventions.

If I at least knew how LOADGRP searches for files, it would help but the EDuke32 source is huge so I was hoping somebody knew it before I resort to spending a lot of time understanding the abstraction tree it uses for file loading. Especially if this behaviour of LOADGRP is a bug and not meant to behave like this anyway