Complete.Org: Mailing Lists: Archives: freeciv-dev: March 2002:
[Freeciv-Dev] Re: game.timeout

[Freeciv-Dev] Re: game.timeout

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: game.timeout
From: Jason Short <vze2zq63@xxxxxxxxxxx>
Date: Tue, 12 Mar 2002 02:14:11 -0500
Reply-to: jdorje@xxxxxxxxxxxx

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 
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.)


[Prev in Thread] Current Thread [Next in Thread]