[..] The engine handles duplicate asset names by including the one contained in the pk3 whose name is the highest numerical value.
That's a slight simplification of the algorithm, but basically how it works in layman's terms.
Let them mod the stuff all they want in baseoa, just don't let them screw around with the stock pk3's . That way, when derpy server repacks pak-whatever, they don't break the experience for others. Force the server to either have the new content in a seperate pk3 or use a mod directory.
That sounds a little contradictory at first glance. If you want to modify (add/edit files in)
baseoa/, you need to either
- repack the existing pk3 files
- add a new pk3 file, with carefully chosen name
- only use file extensions that work serverside with pure mode
It should be obvious why you should not repack the original files. As for serverside-only mods, they do not screw up clients since there are no downloads.
So the real problem is adding a new
baseoa/*.pk3. Now if you want to add a map, you do not want it to be downloaded regardless of the map currently being played, so by the logic of the
sv_pure system you have to put it into
baseoa/. Since a pk3 is not restricted to being a certain kind of mod, e.g. only a map, adding
someone-elses-map.pk3 might as well surprise you by including textures, shaders, playermodels and heck even gamecode that overrides the original content in
baseoa/.
Now is that a problem? Not neccessarily with servers running sv_pure, since those tell the client which pk3 files to use. An offline client however uses all pk3 files and unpacked files/directories it can find in its VFS.
Here's the fix for all of that: Clients should see they are asked to download pk3's that are part of the original distribution and NOT download them. It would recognize this via the name. This accomplishes two things: One, protects the copyright integrity of the stock pk3's (albeit just a bit, not a lot). Two: It would leave intact all the original pk3's included with the game. Herp/Derp server owners would only screw up their own servers by repacking their own pk3's.
And yes, it has been done before. RTCW did it, and I believe Quake 3 had it as well to protect their game assets.
With the current download logic, accepting a download might put a pk3 in
baseoa/, thus screwing the client lateron. Again I do not think players will ever choose "DON'T DOWNLOAD" when their favourite but broken server asks them to download
angelyss-nude.pk3.
If the server asks to download a file which conflicts with a file already present at the client, it will get a new name with its pure checksum appended, e.g.
baseoa/pak6-patch088.c6e9e276.pk3.
Yes, id Quake 3 has a list of pk3 patterns (
(baseq3|missionpack)/pak\d.pk3) and their pure checksums, but this does not prevent the problem of additional pk3 files in
baseoa/baseq3.
Well, what to do? The problems are offline game play as well as servers stepping on each other's toes. So from the top of my head two solutions would be
- Have an oa088-offline.dat, which contains the names/checksums of the stock pk3 files (instead of being hardwired into the versioned OA engine). If a client is not connected to any server, the engine would only load those, instead of all files. Problems: how does a player add maps on his own which he wants to play offline? How would (OA/map) development (or sv_pure being off) work?
- Have a download cache for each server, using its ip:port. That way you could have e.g. ~/.cache/openarena/pk3/192.0.2.1/27960/baseoa/pak6-patch088.pk3 alongside with ~/.cache/openarena/pk3/2001:DB8:0:0:0:0:0:0/666/baseoa/angelyss-nude.pk3 (or 127.0.0.1/::1/loopback). Problems: Would require downloading the same files multiple times for multiple servers (or on changes of ip/port with home servers). You could get around that if the game recognizes pk3s by their (md5/sha1 etc., since the "pure" ones might be too weak) checksums instead of downloading them again (symlink, plain copy etc.), this would require a list of (all) downloaded pk3 files to work, though. Either way you might end up with a huge cache folder after a while. Plus it might confuse players even more if their q3config.cfg now exists for each server ip:port, unless you make the cache addition mess with the read-file-in-pk3/write-(un)pure-file-to-disk logic as well.
I think the last idea might actually work with some improvements, e.g. have a global cache which does not get used offline etc.
This whole problem is trickier than it seems