[quake3-bugzilla] [Bug 4962] Protocol version 69 + legacy support

[bugzilla-daemon at icculus.org]

https://bugzilla.icculus.org/show_bug.cgi?id=4962

--- Comment #26 from Simon McVittie <smcv-ioquake3 at pseudorandom.co.uk> 2011-07-01 09:26:35 EDT ---
(In reply to comment #25)
> By making
> com_oldprotocol and com_newprotocol (this naming is not final obviously) I see
> no reason why we should restrict this. The rest has to be figured out by those
> that write the startup scripts for the respective engines, e.g. as a debian
> maintainer, that would be you.

I suppose what I'm really asking for is: whichever way you go on this, I'd like
it to be obvious to standalone game developers what they ought to do when they
rebase onto a version of ioq3 with your new (variant of the) network protocol.

Debian runs OpenArena by using ioquake3 with command-line options, but
OpenArena upstream provides precompiled -DSTANDALONE binaries which have the
hard-coded constants changed; whatever Debian does needs to be compatible with
what OA upstream are doing, otherwise we won't be able to use the same servers.

> > Not between incompatible variants of a game, though - I believe OpenArena 0.7.7
> > and 0.8.x are both considered to be the same game, distinguished only by the
> > protocol cvar?
> 
> Well, I don't view this as a serious flaw. At most, users will be prompted to
> autodownload the new content, but they probably already get an incompatible
> protocol message so they will know they'll have to update. What's wrong with
> that?

0.7.7 to 0.8.x was an incompatible change (non-free files were deleted from
pak0.pk3, IIRC), so from a compat point of view it's a different game: there's
nothing you can add to 0.7.7 to turn it into 0.8.x. In the network-protocol-68
world, this was done by incrementing the protocol cvar; "also increment
com_newprotocol" would be fine as a solution.

0.8.1 to 0.8.5 was a compatible change (it just added more PK3s to the end of
the sequence, like the id patches do) so that particular mismatch can be
resolved by auto-downloading (if enabled).

> (In reply to comment #24)
> > Maybe connecting clients should included the game's heartbeat (sv_heartbeat) in
> > userinfo? In SV_DirectConnect check if client has correct heartbeat for game,
> > drop client with message if they do not. For legacy support allow clients with
> > no heartbeat set to connect. sv_heartbeat can (and should?) be set differently
> > for standalone games.

This sounds good to me; I believe most (all?) standalone games do change
sv_heartbeat. Bonus points if you document that they should/must do so :-)

-- 
Configure bugmail: https://bugzilla.icculus.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.