Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2001:
[Freeciv-Dev] Re: [Patch] Introduction of turns
Home

[Freeciv-Dev] Re: [Patch] Introduction of turns

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Cc: freeciv development list <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [Patch] Introduction of turns
From: Jason Dorje Short <jshort@xxxxxxxxxxxxx>
Date: Mon, 27 Aug 2001 18:00:07 -0400
Reply-to: jdorje@xxxxxxxxxxxxxxxxxxxxx

"Ross W. Wetmore" wrote:
> 
> At 07:05 PM 01/08/27 +0200, Raimar Falke wrote:
> >On Mon, Aug 27, 2001 at 12:52:34PM -0400, Ross W. Wetmore wrote:
> >> The client currently displays the Game year to the user, so I am not
> >> sure I understand why an additional mechanism is needed to send this.
> >>
> >> Is there some point in processing where the year can change in ways that
> >> the client won't pickup (immediately)? Is this what is being fixed?
> >
> >As pointed out before it is easier for client side ai planing to
> >handle with turns instead of years. It may be possible to calculate
> >the current turn from the current year but a far easier solution is to
> >add a field to struct civ_game and two packets.
> 
> Unless the computation is incredibly arcane, or there are update issues
> with the year, it seems far "easier" to do a quick conversion in the
> client, rather than have this involve the network and server.
> 
> The algorithm to convert turns to years and vice versa just needs to be
> written once and stored in common code.
> 
> But maybe I am missing something that makes the network solution "easier"
> or more efficient? Or how this helps to control network traffic and load?

It's more correct because the same client will work with any server
setup, even one that uses a different conversion.  Otherwise not only
would things not work, they would fail catastrophically.

jason


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