Complete.Org: Mailing Lists: Archives: freeciv-dev: February 2003:
[Freeciv-Dev] Re: (PR#2912) Remove last traces of year usage
Home

[Freeciv-Dev] Re: (PR#2912) Remove last traces of year usage

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients:;
Subject: [Freeciv-Dev] Re: (PR#2912) Remove last traces of year usage
From: "Raimar Falke" <rf13@xxxxxxxxxxxxxxxxx>
Date: Sat, 15 Feb 2003 01:07:04 -0800
Reply-to: rt@xxxxxxxxxxxxxx

On Sat, Feb 15, 2003 at 12:51:48AM -0800, Jason Short via RT wrote:
> 
> [rfalke - Sat Feb  1 13:48:47 2003]:
> 
> > On Mon, Jan 27, 2003 at 12:13:25PM -0800, Per I. Mathisen via RT wrote:
> > > 
> > > Inconsistency between "endyear" and "onsetbarbs". One wants years, the
> > > other was changed to turns.

> > I'm for changing everything to turns.

I remembered one reason against this change. You can't specify the
year 2000 as endyear. This may be required for
historical/compatibility reasons.

> > Even in the user interface. So
> > if both are given in turns it may first confuse players but it is the
> > right thing to do. In another calendar which may not have the same
> > mapping from turn to year the knowledge of "-2000 is a good value for
> > onsetbarbs" is useless. However the knowledge of "total turns/10 is a
> > good value for onsetbarbs" or "20 is a good value for onsetbarbs"
> > holds its value.
> 
> OK, I'm all in favor of doing everything in turns now.
> 
> But several parts of this patch seem error-prone.  For instance the
> turn_to_year function seems no good.  The array it uses won't work past
> the year 2000.  Also this could be calculated arithmetically in many
> fewer lines than it takes to use a static array.  Turn_to_year() is
> similarly over-complicated.

I though that an precalculated array was the easiest. You are right
that this can be expressed in less space. But as the lifetime of this
function is limited I took the easy way. You are right that >2000
isn't handled. This is an easy to fix bug.

> As a side question, in the comment:
> 
> +/***************************************************************
> +  turn_to_year and year_to_turn assume a standard (from -2000 to
> +  4000) game where the spaceshipparts doesn't change the anything.
> +
> +  ONLY USE THESE FUNCTIONS FOR BACKWARDS COMPATIBILITY.
> +
> +  Move the functions to server/savegame.c if the "year2turn"
> +  capability is removed.
> +***************************************************************/
> +int turn_to_year(int turn)
> 
> What does the bit about moving to server/savegame.c mean?  The year2turn
> capability was just added; it seems unlikely that it would be dropped in
> the future.  Do you mean it will become a manditory capability and
> eventually be supplanted by a +1.15.0 (or similar) capability?

If the capability is non-mandatory than two areas still operate with
year and so need turn_to_year: network and savegames. The network will
be removed in this if we remove the non-mandatory capability at the
time of the next release.

Mike had suggested and I agree with him that it is easier to just add
a manditory capability. This way only the savegame loading will need
the mapping turn-to-year.

> And how could this function every leave the client; doesn't the
> client need to know about the calendar?

The client (like the rest of the code) operates on turns only. Only
for certain activities a pretty printed turn (the date, years here)
are needed. The client only needs the date of the current turn. The
server sends this to the client as a string.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  Living on earth may be expensive, but it includes an annual free trip
  around the sun.




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