Feature request: New filesystem about quake3e HOT 10 OPEN

Thank you for your work and intentions.
I'm already reversed shader load order (since 2009) and commented known buggy shaders in renderer code.
For future - sure, I'd like to implement performance-related ideas, piece by piece and with intermediate releases to check for bugs.
Rest of the ideas is more or less discussable, I'll leave them in mind.

For some operative feedback or any suggestion - feel free to join discord channel related to this engine https://discordapp.com/invite/X3Exs4C

from quake3e.

Normalizing the shader order is good. The original reversed behavior is pretty ridiculous :/ My comment is that prioritizing ID paks can be helpful to prevent breakage from bad map conversions that were only tested under the reversed order.

There are actually ways to integrate my filesystem with some intermediate steps, if you are concerned about bugs. A large part does need to be integrated at once, but some features can be initially disabled, and some changes outside the filesystem code can be deferred. For example the renderer can be left unchanged and keep using the old API doing its own shader parsing, and updated later to use the new filesystem image and shader lookup functions.

Generally my filesystem is well tested and very stable, and I think the architecture is a lot better in the long run than what can be done with incremental changes on the original code. If there are any specific bugs or concerns you have with implementation that make you feel uncomfortable integrating it, feel free to ask me about it any time.

from quake3e.

Is it fully intrgrateable with compatibility with vanilla servers etc?

from quake3e.

It should be compatible with all servers. Part of my normal testing routine is to connect to every public Quake 3 server I can find, especially download enabled servers.

from quake3e.

Also, can it be made to be compatible with dll mods? Such as for Enemy Territory? They utilize extraction from mp_bin.pk3 to handle it normally.

Because if this does move forward in the mean time, I would want to port it to my fork of ET (ETe) which integrates most things from here for ET.

from quake3e.

Yes, it shouldn't be hard to add such a function.

I'm not familiar with Enemy Territory at all. How are dll pk3s selected? Is it like Quake where the highest priority pk3 in the current fs_game is used, or are there other conditions? Does qvm support exist in Enemy Territory as well?

I'm also curious how the security model works if pk3s downloaded from servers can contain dlls? Normally you want to avoid trusting remote servers with full code execution privileges.

from quake3e.

In normal mods there is only a mp_bin.pk3 that is always overridden when an update happens. There is no security model. Though I am not sure it allows downloading of mp_bin off hand. It does prevent downloading of mp_bin in the base folder.

from quake3e.

By overridden do you mean it gets replaced, or a differently named pk3 gets used instead? The download folder restriction system in my filesystem could help with security. It can block or restrict qvm files to only allow qvms on a trusted hash list. It could probably be adapted to handle dlls as well.

If you are interested in porting my filesystem, it is mostly a matter of transferring the source files and the ifdefs, but there are a few tricky areas that can require more work, as well as anything game-specific that is changed or added from ioquake3. If you would like to open an issue for it on your ETe repository we could discuss it more there.

from quake3e.

By overriden I mean, there is only ever a file called "mp_bin.pk3" AFAIK. So when a mod distributes a new version, they just override and update that file with new dll/so. I know that the etlegacy project diverged from this behavior but I am not sure of any other vanilla compatible mods that have.

from quake3e.

I will hold off on creating an issue there until there is progress here, because I just manually merge changes from this repository for the most part.

from quake3e.