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

[bugzilla-daemon at icculus.org]

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

--- Comment #25 from Thilo Schulz <arny at ats.s.bawue.de> 2011-07-01 08:59:28 EDT ---
> If this is the way to go, then we should make sure that when using Thilo's new
> protocol, the protocol cvar (at least) is looked at to determine compatibility
> (even though what we're actually going to talk is Thilo's new protocol, not
> protocol 68); and that it's made obvious to standalone game developers that
> they should *not* change newprotocol (or whatever it's called), even when
> they're changing protocol.

I don't believe in placing any restrictions of this sort. 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.

> > The getServersExt query does already differentiate between games.
> 
> 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?

> However smart the server browser is, in an ideal world we'd be able to get
> something like this, even when the server browser isn't used:
> 
>     \connect arena.example.com
> 
>     Error: server not compatible with this game
>     Server is Tremulous-2, protocol 68
>     This is Quake3-1, protocol 68

Can do, see my answer to Zack's comment below

(In reply to comment #23)
> The other major case that I'd like to continue to "fail nicely" is using the
> same base game as the server, but an incompatible version. So if you connect to
> an OA 0.8.x server with a hypothetical incompatible OA 0.9, you'd get:
> 
>     \connect arena.example.com
> 
>     Error: server not compatible with this game
>     Server is OpenArena-1, protocol 71
>     This is OpenArena-1, protocol 72

This happens already, not as verbose though as wrote it here, but it won't be
changed.

(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 should work for keeping games using the same protocol (but different
> heartbeats) separate. Doesn't seem to solve the differing game content issue
> though.

Yes, that is a good idea. It won't make any problems with legacy clients,
because added parameters to messages in connectionless messages are simply
ignored. And new clients can exchange enough information to make connection
attempts fail gracefully.

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