smcv
Nub
Cakes 5
Posts: 23
ioquake3/OA/Q3 Debian maintainer
|
 |
« on: August 08, 2011, 12:30:29 PM » |
|
I know ioquake3 1.37 hasn't been released yet, but it looks as though it's probably quite imminent, so now is the time to think about how to make/keep OA compatible with it... I've been uploading recent snapshots to Debian experimental, which might be useful as a reference.
master server (dpmaster) heartbeat
All released versions of OpenArena send the "QuakeArena-1" heartbeat string to the master server. This causes dpmaster to identify it as Quake III Arena (technically: game name "Quake3Arena").
Newer versions of ioquake3 use the "DarkPlaces" heartbeat string, which selects use of the DarkPlaces protocol. This is heavily based on the Q3A protocol, but instead of a hard-coded mapping from "QuakeArena-1" to "Quake3Arena", dpmaster looks for a "gamename" key in the server info, and uses that.
In a generic "any game" ioquake3 engine (like the one I upload to Debian), the gamename is set on the command line via "+set com_gamename Something". In a standalone build with things hard-coded (like the official OpenArena engine binaries), you'd redefine GAMENAME_FOR_MASTER, which just sets the default value of com_gamename (formerly cl_gamename).
When looking for servers, "getservers" guesses a gamename based on the protocol, and "getserversExt" explicitly sends one. This actually means that the engine supplied with OA 0.8.5 will never find any IPv6 servers - it queries for them with "getserversExt openarena ipv6" as a result of GAMENAME_FOR_MASTER having been defined to "openarena", but all current OA servers implicitly advertise themselves as "Quake3Arena", so they won't be found like that.
In Sago007's "updated engine" builds (which are compatible with, and intended to be used with, OpenArena 0.8.1 and 0.8.5), and in my Debian packages (likewise), I think we have no choice but to set com_gamename to "Quake3Arena" - this is the only way to have dpmaster.deathmask.net send us details of existing OpenArena 0.8.1 and 0.8.5 servers.
Next time OpenArena deliberately breaks network-compatibility with older versions (is this planned for 0.8.7, or 0.9.0, or what?), com_gamename should clearly change - it could become "OpenArena0.9" or something.
(I did propose some patches for dpmaster, to treat the combination of QuakeArena-1 + protocol 71 as meaning that gamename was "openarena", to work around the 0.8.1 and 0.8.5 binaries that most people will still be using, but the author of dpmaster rejected that idea.)
New network protocol
ioquake3 now supports up to two network protocols in parallel: the new protocol (currently 71, confusingly enough) and the legacy protocol (68, the same as Q3A 1.32). It always advertises the legacy protocol to the master server, unless configured not to support it at all. When a client actually joins, it will attempt to negotiate use of the new protocol instead.
In the new protocol, the client and server also compare their com_gamename (see above) in order to give a better error message if they're incompatible - in the distant future, joining a Quake III Arena server with OpenArena will give you a message like "that server is Quake3Arena, not OpenArena".
The conservative thing to do is to switch off support for the new protocol altogether, and keep using protocol 68 (re-labelled as 71 in OpenArena-land). You do that by setting the com_protocol cvar to the same value as com_legacyprotocol (in a standalone OA engine, you'd change some #defines to change the default values of those cvars, but the effect is the same). In my Debian packages I currently set both to 71, so they always use the legacy protocol, and are completely interoperable with 0.8.1 and 0.8.5.
Another possibility would be to say something like: "the OpenArena-0.8.5-compatible version of the "new protocol" will always be the engine's real protocol version + 85000". So with current svn snapshots of ioquake3 you'd have com_legacyprotocol = 71 and com_protocol = 85071, but if 1.37 gets released with com_protocol = 75, you'd use com_legacyprotocol = 71 and com_protocol = 85075 for that version of the engine. If you want to go that way, I have a patch to add a "com_protocoloffset" cvar, which would mean I'd set com_protocoloffset = 85000 in the Debian OpenArena package, and always get an appropriate version number for the engine (and I'll try to send that upstream to ioquake3, if it'll be useful).
When OpenArena next breaks compatibility (0.9.0 or whatever), I think the thing to do would be: keep increasing the legacy protocol number (perhaps to 90068), set the new-protocol number back to what the engine would "naturally" call it (so it stays 71 or 75 or whatever), and set com_gamename to "OpenArena0.9" or something as the way to discriminate between OpenArena and non-OpenArena clients.
ioquake3 upstream don't consider it to be useful to offer the legacy protocol in standalone games, but I'd appreciate it if you'd leave it in - that would mean that a client and a server with the "official" OpenArena 0.9.0 engine would use the "new protocol" that was current at the time that engine was released, but an updated client based on a newer version of ioquake3, with an even newer "new protocol", would still be able to join that server by falling back to the legacy protocol. The ioquake3 authors don't plan to support more than one "new protocol" at a time; if I need to, I could patch in support for that in Debian, but I'd really rather not!
(By the way, the legacy protocol can be disabled at runtime, by setting com_legacyprotocol to 0, if you're into that sort of thing.)
|
