pk3dir support

[SpineyPete]

Some of the newer Quake based games have a so called pk3dir feature. A pk3dir is simply a directory with ".pk3dir" appended to the directory name. The engine then interprets it as if it was a zipped pk3.

This is useful when making maps since it's really easy to move files around as they're no longer scattered inside different spots in the game directory. It also makes zipping up maps a one click affair. Quemap already does the latter for us but it's still a win in terms of easy file management and makes accidental screw-ups less likely.

Xonotic and Unvanquished for example support the feature.

[jdolan]

Adding this would simply require a post-processing step in Fs_AddSearchPath, where we enumerate each path as it is added, looking for directory entries ending in .pk3dir, and recursively adding them. Good first issue for someone looking to touch the engine code.

[jdolan]

@SpineyPete Didn't you say this was effectively already supported?

[SpineyPete]

So, IIRC, if you slap a .pk3 at the end of a folder name then Quemap will do exactly what I would like the .pk3dir to do. The problem is that the engine then chokes when trying to unzip the folder.

So... to support this you would need:

• handle a folder with a .pk3dir suffix the same as if it were with a .pk3 suffix
• make the engine load it as if it were a .pk3
• (optional) have some way to select between a map when there's both a .pk3 and .pk3dir with the same name -- maybe have like /devmap instead of /map in the console and they can both list pk3dir and pk3 respectively.

The first two are probably 5 mins of work if you're familiar with the code?

[illwieckz]

For reference, this is stuff I wrote about how idtech3 engines and tools handle pk3/pk3dir overriding: https://github.com/kduske/TrenchBroom/issues/2554#issuecomment-466245050

It's probably worth the read.

(optional) have some way to select between a map when there's both a .pk3 and .pk3dir

Probably the wrong solution to a good problem. Some engines support things like -pakpath (I think quetoo already supports something like that, right?) so it's up to the mapper to use a clean directory for mapping (where he stores wip .pk3dir). As reference I also added -fs_pakpath to q3map2 (and -fs_nohomepath option to not load stuff from home dir that is likely to contain downloaded random stuff from the internet) to allow mappers to work on a completely clean and controlled workflow.

Edit: there is also pakpath support in NetRadiant (quick&dirty support hardcoded to 5 entries at this point) and options to disable home path and even engine path:

[jdolan]

This one has hung around long enough. If someone really wanted it, we'd have it by now ;)