Allow loading mods on a per-map or per-vote basis

[bmorel]

Currently, daemonded does not allow to load specific mods in the maprotation.cfg file, or at least, not with the command set fs_extrapaks which is used by the usual configuration files.

I tried several workarounds to achieve that goal, including creating "map-meta-$name" packages which would depend on the real map, but no luck (this specific work-around failed because the game then searches for a file named "meta-$name.bsp" in the archive).

There can be multiple usages, ranging from voting for a specific mod+map combination to provide lightweight patches to maps (navmeshes, navcons, AI map-specific behaviors, etc). My personal use-case is to provide players with a set of res-navmesh upgrades, which would contain navmeshes for several maps. Those navmeshes are pretty heavy, but expected to be very rarely updated. Then for each map, to have individual navcon updates, which currently can not be generated automatically and thus are likely to have lot of updates. Splitting the navmeshes in set allows to provide a single file for all official unvanquished maps, another for karith, nexus6 and niveus, which are also FOSS, and a last one for others, depending on licences and/or admin's tastes. The combined size of all the navmesh I regerenated is of roughly 36 megs: all official maps, plus the 3 trem I mentioned, and 11 other ones.

The navcon files themselves have a negligible size, especially since they compressed, which is, considering the fact they'll need frequent updates at start, a blessing.

[slipher]

1. Technically speaking, you can load navmeshes from the game/ directory... but only if there aren't any in the paks! FS_Game_FOpenFileByMode should probably be changed to check game/ first and then paks, rather than the other way around. That would make more sense, so that it is possible to do server-side overrides like you expected.
2. I believe you could achieve different extra paks per-map by using map configuration files. See dist/ for an example of map configs (except there is only default.cfg there, you will need map-specific ones like chasm.cfg etc.). If I'm not mistaken, the map configs are usually executed before restarting the sgame, so you would be able to set fs_extrapaks in them. But there will be a hiccup with the first map that the server loads - for that map the configs will be executed after the sgame has already loaded, so you can't influence the paks. So you'd need to set the paks on the command line, or immediately issue a nextmap command so that the server gets into its normal flow.

[slipher]

Probably the opening files for reading should be split into two syscalls:

1. One that only looks in paks.
2. One that looks first in game/, then in paks. This one should be available only in the sgame, so that junk in game/ can't affect the client experience.

Also looking in game/ first all the time wouldn't be good since it would lead to unnecessary filesystem access.

[slipher]

Looks like I was wrong about that extra paks thing. Although the command is enqueued before the end of the previous map, the sgame entirely restarts within one frame, and so the command is not executed until after sgame initialization. So the bit that runs the code at the end of the previous map is pointless and should be deleted.