[Freeciv-Dev] Re: game.timeout

[Jason Short <vze2zq63@xxxxxxxxxxx>]

Mike Kaufman wrote:
> On Sun, Mar 10, 2002 at 04:39:25PM -0400, Mark Metson wrote:
>
> > On Sun, 10 Mar 2002, Mike Kaufman wrote:
> >
> >
> > > does anybody have any idea why GAME_MAX_TIMEOUT 
> > > is set at 8639999? Why not MAX_INT 
> > >
> > > or make game.timeout an unsigned or an unsigned long?
> > Did anyone find out why it doesnt work, too? I found when I set timeout to 
> > 24 hours it would briefly display as such each turn but promptly get 
> > overwritten as 5 hours 37 minutes.
> Attached is the fix. Somebody (Trent in '98) decided that 18 hours and 16 bits 
> was
> quite enough.
>
> Note that this breaks network protocol.
>
> maintainers: what do we want to do about this? I'm inclined to say:
> now's a good a time as any to break it, (raimar: don't you have some 
> network efficiency code lying around waiting for such an opportunity?)
Correct me if I'm wrong, but doesn't the +trade_size capability added 
last week effectively break compatibility with anything from before 
trade_size was applied?
Given that, making an official break doesn't seem like such a big step.


Speaking of capabilities, I have a question about them.  When I 
implemented general-topologies, I changed the network protocol and added 
capabilities.  Ross has presumably done the same thing, although I 
haven't looked at that part of the corecleanups.  The problem is that 
the capability can't just be checked when map data is sent, although 
this is as far as I've gotten.  For instance, if we're playing on an 
iso-rectangular map and an old client connects, it's not sufficient just 
to send the map data in the old form.  In actuality, there's no way for 
the old client to join the game.
However, capabilities could probably still be used, though it would be 
rather tricky.  If a player without support for topology X joined 
pre-game, then topology X shouldn't be an available option to switch to. 
 In other words, any time someone tries to switch topologies pre-game, 
we need to check that all clients support this topology.  After a 
topology has been chosen (either after the game starts, or pre-game so 
that a player joining can't cause a switch *back* to the basic 
topology), players whose clients don't support that topology must not be 
allowed to join at all (presumably with some effective error message).
Is this the correct way to handle things?

My first thought was that this would be a good time to break protocol 
compatiblity completely.  However, I quickly realized this wouldn't 
work.  It's not the protocol itself that is the issue, but support (in 
map.c) for the topology in use.  For instance, if topology support is 
added for iso-rectangular maps, with wrapping in any direction, then 
clients which do not support such maps should not join the game. 
However it might be possible to add topology support to be added for 
hexagonal maps (_not_ the same as hexagonally tiles maps, note) to be 
added shortly later, which would not visibly change the protocol but 
would have the same problem.  (I say "visibly", because it actually 
would change the range of values that can be sent as the "topology type" 
over the protocol.  But it may not be immediately obvious that a new 
capability is needed.)
jason