New filesystem project


I added a new feature that lets you customize which files are added to the download and pure lists when running a server. You can specify (or remove) both individual paks and categories of paks from either list by modifying the fs_download_manifest and fs_pure_manifest cvars.

Some of the cases where this can be useful:

  • To remove excess mod paks from the download list that clients don’t really require
  • To add resource paks to the download list that clients do require but aren’t marked as referenced by the normal mechanism
  • To trim the pure list to use the current map instead of everything in baseq3, which enables running a valid pure server with thousands of pk3s installed without overflows

Additional documentation on this feature is available here. If you would like to try it on your server you’ll probably need to build the project from source, unless you use Windows in which case you can get a test build from the release page. Let me know if you have any questions or comments.


I was wondering if it would be okay if I created a pull request for this project on GitHub. I think the project is now stable enough to officially propose for ioquake3 inclusion, and a pull request would provide a place for people to discuss it in that context.

If you haven’t been following this project, here’s an overview of the links to check it out. There have been a lot of improvements since the original release last year. I’d love to hear any feedback.


Hi Chomenor, maybe you remember, I’m a long time tester from the very beginning of your project and I still use it for my programming experiments, you did a really great job. I never had any problems during this period, it really works well, impressive project, imo.
One question, can you explain a bit more if enabling downloads are safer now? Iirc, somewhere here I read that noone should enable auto-downloading (security risk), so is this REALLY fixed with your project?

It would be cool if your work would be included into ioquake3, especially because it doesn’t break mod compatibility as far as I know.
Though, someone said you have to maintain/update your code regulary, and thats a reason why such big projects are usally not included (though, on the other hand, other ‘projects’ had a bigger influence and others are even no longer maintained and these ‘projects’ were included nevertheless…(Mumble, OpenAL, etc.))

So, I hope your project will find its way into ioquake3!
Anyways, please stay with ioquake3, I really like your work (even if I don’t understand it, codewise).

Well done!

P.S.: as aready noted, your code formatting is a bit ‘strange’ :wink:


Automatic downloads should be a lot safer if the download directory restrictions here are enabled. It can block, or restricted to trusted hashes only, the qvm files that are the source of most security vulnerabilities. These options aren’t enabled by default currently, but that could be changed later, especially if cl_allowDownload were to be enabled by default as well.

I didn’t consider this project complete when I first released it, so it needed more maintenance initially. It shouldn’t require too much maintenance now, besides minor tweaks here and there, like any project. I recommend evaluating this project by testing it in real conditions, like download-enabled servers and with existing map and mod packs. It should be pretty stable now, but let me know if you do notice any compatibility or other issues.

I think my code formatting is kind of Python-like, where the indentation is the main guide, there are minimal extra lines, and the braces are just added in afterwards where needed. That’s something that can be changed very easily by script though, if it was requested for ioq3 inclusion.

Thanks for the support and testing!


My personal setup with my ioquake3 fork, Spearmint, involved 40 game directories for 30 unique standalone game releases (retail/demo/etc) with more waiting to be added (granted most are not playable beyond loading maps). 260 pk3 files. 16 pk3dirs for separating data I made for testing a single thing.

Sort of agree, conceptually:

  • Save downloads into a separate directory with a option to disable loading qvms from loaded pk3s. I don’t agree with the sorting precedence or keeping downloaded pk3s loaded when you required by server. However, apparently deep integration with the launcher to allow/deny is planned instead.
  • A way to specific which pk3s to load would be useful for hosting servers and local testing. Loosely similar to new filesystem’s “fs_download_manifest” / “fs_pure_manifest”. Though, I would probably vote for a literal list of pk3 names to be used in the order listed (single cvar for referenced and pure pk3 lists).

The changes I listed above would not require a complete rewrite of the filesystem. I don’t really want any of the other features listed in the new filesystem readme to be added to ioquake3.

Don’t agree:

  • Searching all game directories (to fix broken mods?) is strange and goes against the Quake 3 design. Also I have other standalone games in my search path. I don’t want Quake 3 content pulled into OpenArena or other separate games, if that makes sense.
  • Sharing renderer settings across mods would be nice but it doesn’t seem apporiate to change the config behavior. (Don’t worry we can have consistent video resolution with the lancher!)
  • … I don’t want to go through listing reasons for all of them.

The issues listed by SmileTheory earlier in the thread still apply as well. I’m opposed to merging new filesystem and realistically there isn’t a way you can change ‘new filesystem’ to make it something I would want to merge into ioquake3. It doesn’t really fit with the general concept I work under of ‘make the smallest possible change to fix the problem’. Yeah, it may not always happen.


Thanks for the reply. I’m sorry you don’t have a good impression of my project. I have a few questions, or requests for clarification, if you don’t mind:

  • You said you don’t agree with the “sorting precedence”. Is this in relation to the download directory feature, and what aspect of the precedence do you mean specifically?

  • My download/pure manifest feature can be used to load a literal list of pk3 names, it just supports additional set keywords on top of that. Are you saying would prefer to just remove the set keywords and allow pk3 names only? Why do that, and wouldn’t it just make the feature a lot less flexible and more difficult to use?

The reason this project is done as a rewrite of the filesystem is not to support the supplemental features in the readme, but rather to make architectural changes necessary to support large numbers (up to thousands) of pk3s with good performance and stability. The file precedence has been overhauled to make it almost impossible for any pk3 in baseq3 to override the core paks and break the game or other maps, which means you can download maps and mods from servers or bulk packs without worrying about conflicts. The caching and optimizations allow fast load times with thousands of pk3s installed and the new debug commands show exactly which resources are loaded and how they are selected. The debug commands are pretty great, IMO, if you haven’t tried them yet. I personally wouldn’t want to go back to not having them for any kind of development use.

  • As the readme states, the full inactive mod support is just used as a last resort if the alternative is a texture error. Is there a specific practical reason why this is bad? The only argument I’ve heard is that it could theoretically confuse map authors. At any rate this is entirely cvar controlled and can be disabled or removed for ioq3 integration purposes.

  • The restricted inactive mod support (setting=1, missionpack and pure list pk3s only) allows maps designed for team arena to work with non-team arena mods without convoluted extra download workarounds that servers have to do now. It also gives advanced pure server admins some tools to do things like submodding, if they are targetting only new filesystem clients (like a standalone game scenario). Do you know of any problem that would arise from this feature?

  • I know the shared config file behavior is debatable. That’s why I designed it from the start to be cvar controlled and easily removed if it’s a condition for ioq3 integration.

If there is any way we could discuss your concerns and maybe keep possible integration of this project on the table, that would be great. Otherwise I’ll drop the project here, even though it’s a bit sad and I don’t think this project quite got the consideration it deserves… that’s the way it goes.

Good luck with ioquake3 and your future plans and thanks for the response. Maybe I’ll be able to contribute in some other way in the future :slightly_smiling_face:


I added pk3dir support now. It seems to work better than the original implementation because it supports case-insensitive access like a pk3, even on Linux, although I haven’t played around with it too much yet. @zturtleman perhaps you’d like to give it a try on your config, and see how it works for you? You could also try the find/compare commands with it.


Again, I would like to ask if the ioquake3 maintainers would mind if I open a pull request for this project? It would be nice to be able to at least make the case for this project before you reject it. It would also allow this project to be listed and discussed along with other proposed contributions. There may be code or ideas that are selectively useful to ioquake3 or other projects, even if the project itself isn’t accepted.

If you would like to close the thread on this forum so there isn’t duplicate discussion, that would be fine.