I didn’t get to look over your system and try it out yet, but I will definitely at some point. My primary interest with a new file system is for another game that is based on ioquake3 (as one of the project leaders of GrangerHub working on Tremulous), so the goals may be different from that of the goals of the ioquake3 project. Although for awhile we have been working to keep backwards compatibility with old servers/clients, we will probably change that requirement (at least with old clients), so we could have less restrictions for a new file system than ioquake3.
But yes, one of the main issues is being able to not be limited in the amount of pk3 files you have downloaded. I have found that many players don’t even know how to get to their homepath to delete excess pk3 files (although if there was a button from the main menu for opening your homepath in a file explorer, that could help a lot), and if you have a development server where you update new pk3 files often, after awhile you have to change the fs_game or many people would crash from just trying to connect.
Other issues are with conflicts, commonly used settings changing with fs_games, and the possibility of the main menu being overridden by a mod in an undesirable way (we did change our file system for the client a bit to use a common fs_game for the configs/screenshots/etc, and force the client to only load our ui and menus on startup so that it can’t be overidden, but in some ways that is a broken approach, like you can’t play back demos nor load mods from the main menu).
It sound like your project might address the above issues. Again, I didn’t get a chance to review your work yet, so I’m in no position to argue one way or another the merits of your project’s design and implementation at this time. It is possible that using your file system may be a beneficial route for our project.
With that said, another important issue is simplicity, and I have been wondering lately if the fs_game concept is just fundamentally flawed making things more complicated than they have to be, and perhaps might not even be necessary for backwards compatibility.
There was a another project that implemented a file system close to what I described in my previous post, although it wasn’t designed to for backwards compatibility (but perhaps could be). The other thing is that that project is licensed GPLv3+, and I don’t think that ioquake3 will upgrade their GPLv2+ license anytime soon. But we will probably upgrade to GPLv3+ for our project at some point, and I was thinking of porting and adapting the FS of that other project. But perhaps there might be some inspiration from that file system for improving your project, and if you implement the same kind of features, you may not have to upgrade your GPLv2+ license (if you don’t want to), provided your code is original and non-derivative.
If you’d like, I can om you information about that other file system.