[Freeciv-Dev] Re: game.timeout
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
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
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.
or make game.timeout an unsigned or an unsigned long?
Attached is the fix. Somebody (Trent in '98) decided that 18 hours and 16 bits
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.)