OpenArena's modified ioquake3 engine has changed the PROTOCOL_VERSION to reflect incompatible changes to game logic and content; the actual protocol is the same, however. With the patches I'm about to attach here, an ioquake3 executable can be made to interoperate with OpenArena's modified ioquake3 via the command line:
ioquake3 +set com_standalone 1 +set protocol 71 [etc.]
This is advantageous for distributions, since a single ioquake3 binary (with suitable configuration) can play both OpenArena and Quake III. We'd like to ship "the real ioquake3" in Debian and Ubuntu instead of OpenArena's somewhat outdated version, use it for OpenArena, and gain Quake III support as a nice side-effect.
Created attachment 2393[details]
FS_FOpenFileRead: allow loading any demo, not just the current protocol
This just expands the "pure server" check exemption from current-version demos to all demos ever.
Created attachment 2394[details]
Allow protocol cvar to be changed on the command line
This allows an unmodified ioquake3 binary to run standalone games that
have the same underlying protocol, but change PROTOCOL_VERSION to reflect
incompatible changes to game content, such as OpenArena. For instance,
OpenArena >= 0.8.1 can use:
ioquake3 +set protocol 71 [...]
I have these comments to these patches:
FS_FOpenFileRead: allow loading any demo, not just the current protocol
and
Load demos using the protocol version from the command line, if overridden
How are we supposed to take into account the global variable demo_protocols, which is defined in common.c? There is a reason why it checks against a list of supported protocols. I guess the best thing you can do is check for these protocol versions in common.c + additionally the new protocol version as defined in the cvar, but reject all other protocols. Is this the case with your current patch?
Second issue I have with your second patch is that you named the cvar "sv_protocol". There's no reason for this, it should be called "com_protocol", because the client AND server both need the protocol version.
I will accept your patches once these issues are resolved. Thank you for your contributions, they are appreciated.
(In reply to comment #4)
> FS_FOpenFileRead: allow loading any demo, not just the current protocol
This one is about relaxing the engine's restrictions on what files it's willing to load from outside a .pk3 file, so it'll allow anything that "looks like a demo", but only if some other code path results in it being loaded at all. This is to avoid having to check through demo_protocols here as well, for simplicity.
> Load demos using the protocol version from the command line, if overridden
and this one tries the chosen demo extension before the contents of demo_protocols. I'm relying on the fact that Quake III's actual network protocol has been stable for quite a long time (since before it was GPL'd, I think?); the only reason OpenArena changes its "protocol version" is to fail early and gracefully when an OA player joins a Q3 server, or vice versa.
> I guess the best thing you can do is check for these
> protocol versions in common.c + additionally the new protocol version as
> defined in the cvar, but reject all other protocols.
I actually tried the cvar *before* demo_protocols, but yes. In the common case where the cvar's value is repeated in demo_protocols, we'll just try that extension twice, which should be pretty cheap; we're not on a fast-path here or anything.
> Second issue I have with your second patch is that you named the cvar
> "sv_protocol". There's no reason for this, it should be called "com_protocol",
> because the client AND server both need the protocol version.
It's sv_protocol because that already existed; I moved it from CVAR_READONLY to CVAR_INIT. If you'd prefer com_protocol, we probably also still need a sv_protocol that's a read-only copy of com_protocol, for compatibility?
(In reply to comment #6)
> It's sv_protocol because that already existed
Oh, sorry, I misremembered, the cvar is just "protocol", but that's too namespace-colliding for a global variable. You're right to call the variable com_protocol, and this shouldn't cause any problems for us.
OpenArena's modified ioquake3 engine has changed the PROTOCOL_VERSION to reflect incompatible changes to game logic and content; the actual protocol is the same, however. With the patches I'm about to attach here, an ioquake3 executable can be made to interoperate with OpenArena's modified ioquake3 via the command line: ioquake3 +set com_standalone 1 +set protocol 71 [etc.] This is advantageous for distributions, since a single ioquake3 binary (with suitable configuration) can play both OpenArena and Quake III. We'd like to ship "the real ioquake3" in Debian and Ubuntu instead of OpenArena's somewhat outdated version, use it for OpenArena, and gain Quake III support as a nice side-effect.Created attachment 2393 [details] FS_FOpenFileRead: allow loading any demo, not just the current protocol This just expands the "pure server" check exemption from current-version demos to all demos ever.Created attachment 2394 [details] Allow protocol cvar to be changed on the command line This allows an unmodified ioquake3 binary to run standalone games that have the same underlying protocol, but change PROTOCOL_VERSION to reflect incompatible changes to game content, such as OpenArena. For instance, OpenArena >= 0.8.1 can use: ioquake3 +set protocol 71 [...]Created attachment 2395 [details] Load demos using the protocol version from the command line, if overridden