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]
To: Trent Piepho <xyzzy@xxxxxxxxxxxxx>
Cc: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>, rf13@xxxxxxxxxxxxxxxxxxxxxx, freeciv development list <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [Patch] Introduction of turns
From: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Date: Mon, 27 Aug 2001 19:25:48 -0400

At 03:07 PM 01/08/27 -0700, Trent Piepho wrote:
>On Mon, 27 Aug 2001, Ross W. Wetmore wrote:
>> Unless the computation is incredibly arcane, or there are update issues
>
>That's pretty much it.  In order to compute the turn from the year,
>you need to know if and WHEN certain advances took place.  If I say
>it's year 1950, you can't tell me the absolute turn number with that
>information.  

Yes if the conversion depends on various parameters, the client needs those
to run the algorithm.

>It doesn't seem unreasonable to me to add the turn number to packets that
>contain the year.  The new_year and game_info packets are the only ones that
>need it.  The year and turn number could even be changed to 16-bit, so the
>bandwidth stays the same.
>
>> 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 not like the client needs to query the server for the turn number.  You
>just stick that data in a packet that contains the year and only gets sent
>once per turn.

Updating existing packets to send dual info is fine, especially if this
is/coincides with the current year update. I got the impression from Raimar's 
wording he was using two (extra) new packets. 

Cheers,
RossW




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