[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.
[Freeciv-Dev] Re: (PR#2912) Remove last traces of year usage, Anthony J. Stuckey, 2003/02/17
|
|