This patch is essential for win32 servers that want to run an updated game.qvm since there is no searching of a user-specific directory like in Linux/OSX.  For example, on Linux, you can copy the game.qvm file to ~/.quake3/baseq3/vm/ and it will get used over the one in the pk3.

The only workaround currently on win32 is to set fs_game to another name and use that directory for the game.qvm.  This causes annoyances for the clients.

I'm very unkeen on this patch. It's a major departure from what many people expect the behaviour of the Q3 VFS to be. If you want to use the new qvms, you should just zip them up into a new pk3.

(In reply to comment #1)
> This patch is essential for win32 servers that want to run an updated game.qvm
> since there is no searching of a user-specific directory like in Linux/OSX. 
> For example, on Linux, you can copy the game.qvm file to ~/.quake3/baseq3/vm/
> and it will get used over the one in the pk3.

Windows should really do the equivalent, in Documents and Settings/User/Application Data, or whatever the fuck it is. Somebody should write a patch for this. :)

> The only workaround currently on win32 is to set fs_game to another name and
> use that directory for the game.qvm.  This causes annoyances for the clients.

AFAIK, you can just use a gamex86.dll with +set vm_game 0. The server is free to run in whatever vm mode it likes, pure or not. At least I think this is the case, from what I recall.

Unless somebody comes up with a really compelling reason this should go in, I think this should be rejected, sorry :(.

(In reply to comment #2)
> I'm very unkeen on this patch. It's a major departure from what many people
> expect the behaviour of the Q3 VFS to be.

I guess I don't see how it would cause much confusion.  Anyone who knows about this quirk is already using their $HOME/.quake3/baseq3/ dir anyway right?  QVM files in that dir would still have precedence so there should be no inconsistency for the user even if they have an ancient .qvm file sitting in the main baseq3 dir.  It's only the fringe case where someone happens to have an ancient .qvm in their main baseq3 folder that has never been used and nothing in their $HOME baseq3 dir.  Speaking of that, if this patch does get included it should probably also include a patch that prints more detail about exactly which .qvm was loaded.

It seems a lot easier to explain to someone that the .qvm file in their baseq3 dir will be used above ones in the pk3 than to try to explain in which baseq3 dir it works in (especially since it's different on every platform).

Unless I'm missing something, it seems like this change just makes things more consistent.  The only other way to make it consistent is to disallow loading .qvm files that are not in a pk3 (which would make developing with .qvm a pain).

> If you want to use the new qvms, you should just zip them up into a new pk3.

You can't do this on a pure server without forcing the client to download the pk3 of your game.qvm though right?

> 
> (In reply to comment #1)
> > This patch is essential for win32 servers that want to run an updated game.qvm
> > since there is no searching of a user-specific directory like in Linux/OSX. 
> > For example, on Linux, you can copy the game.qvm file to ~/.quake3/baseq3/vm/
> > and it will get used over the one in the pk3.
> 
> Windows should really do the equivalent, in Documents and
> Settings/User/Application Data, or whatever the fuck it is. Somebody should
> write a patch for this. :)

Yes, but there are still the sad win98/winme users if there are any left.

> > The only workaround currently on win32 is to set fs_game to another name and
> > use that directory for the game.qvm.  This causes annoyances for the clients.
> 
> AFAIK, you can just use a gamex86.dll with +set vm_game 0. The server is free
> to run in whatever vm mode it likes, pure or not. At least I think this is the
> case, from what I recall.
> 
> Unless somebody comes up with a really compelling reason this should go in, I
> think this should be rejected, sorry :(.

> (in reply to comment #2)
> It's a major departure from what many people expect the behaviour of the Q3
> VFS to be.

I don't think so. Most people would expect to just drop in a new file in baseq3/ and have it used by quake 3. This is supported by your own Makefile installing files there that should be used instead of those found in the .pk3.

If you really want to keep that unexpected behaviour you should change your Makefile to not install unused files.

You are right that the current behaviour is documented in the code. The implementation is inconsistent though as the same file will be used or ignored depending on it's position in the search path.

> AFAIK, you can just use a gamex86.dll with +set vm_game 0. The server is free
> to run in whatever vm mode it likes, pure or not. At least I think this is the
> case, from what I recall.

That would be a bug that needs to be addressed. In pure mode the server is supposed to run the same game as the client.

> (in reply to comment #3)
> Unless I'm missing something, it seems like this change just makes things more
> consistent.  The only other way to make it consistent is to disallow loading
> .qvm files that are not in a pk3 (which would make developing with .qvm a
> pain).

My patch changes the search order for all files (QVM, maps, sounds, ...). If you want to alter some existing one you had to either put it in a directory in the quake search path not having a .pk3 file with a file named the same as your changed file or zip it up into a .pk3 with the right name. This obviously is inconsistent.

> > If you want to use the new qvms, you should just zip them up into a new pk3.
> You can't do this on a pure server without forcing the client to download the
> pk3 of your game.qvm though right?

Isn't the idea of a pure server that everybody (including the server) runs the same game?

(In reply to comment #2)
> Windows should really do the equivalent, in Documents and
> Settings/User/Application Data, or whatever the fuck it is. Somebody should
> write a patch for this. :)

Added bug 2813

(In reply to comment #4)
> > (in reply to comment #2)
> > It's a major departure from what many people expect the behaviour of the Q3
> > VFS to be.
> 
> I don't think so. Most people would expect to just drop in a new file in
> baseq3/ and have it used by quake 3. This is supported by your own Makefile
> installing files there that should be used instead of those found in the .pk3.

Most people expect the same functionality from Q3 as they have always had. There is a good overview of the Q3 VFS in the comments at the top of qcommon/files.c

> If you really want to keep that unexpected behaviour you should change your
> Makefile to not install unused files.

Perhaps. You really are mischaracterising the existing behaviour though. To the vast majority of the people who have worked with Q3 over the years, it's entirely 100% expected.

> That would be a bug that needs to be addressed. In pure mode the server is
> supposed to run the same game as the client.

This is definitely not a bug. There are many server side only mods out there that /rely/ on this functionality.

> Isn't the idea of a pure server that everybody (including the server) runs the
> same game?

Yes and no. The idea of pure server is that the server ensures the clients are all running what it thinks they should be running, but it is free to run whatever it wants itself.

Created attachment 1007 [details]
don't copy unused .qvm files on 'make copyfiles'

since the changed search order is rejected the Makefile should be corrected to not install files *that will never be used*

Comment #7 patch applied.

Setting a QA contact on all ioquake3 bugs, even resolved ones. Sorry if you get a flood of email from this, it should only happen once. Apologies for the incovenience.

--ryan.