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

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

[rfalke - Sat Feb 15 10:03:08 2003]:

> On Sat, Feb 15, 2003 at 01:39:03AM -0800, Jason Short wrote:
> > Raimar Falke wrote:
> > > 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.
> > 
> > Seems like this could be part of the gen-calendar change, specifying 
> > starttime, intervals, and endtime for the scenario.  To begin with we 
> > would have startyear and endyear as the server options, while the 
> > intervals are fixed (50 year intervals until -1000, 25 year intervals 
> > until 0, 20 year intervals until 1000, 10 year intervals until 1500, 5 
> > year intervals until 1750, 2 year intervals until 1900, 1-year
intervals 
> > after that).  The conversion year<->turn can be done as an O(n) process 
> > where n is the number of intervals.
> 
> The current mapping isn't this easy. The spaceship parts also have an
> influence here.

But this is the mapping you are introducing, isn't it???

> > >>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.
> > 
> > So the client is only able to determine the year for the current turn? 
> 
> Yes this was the plan.

What is the reason for this?

> > That seems like an unnecessary restriction just so that turn_to_year
can 
> > be moved into the server.  Information like what year a city was 
> > founded, what year a spaceship will arrive, etc., is not essential but 
> > is good to be able to give the user.
> 
> That can always be given in the form "4 turns ago" or "in 3
> turns". See also cal3.diff which has this:
> 
> +    my_snprintf(total_travel_buf, sizeof(total_travel_buf),
> +               _("Total travel time:     %5.1f turns"), travel_time);
> +    my_snprintf(remaining_travel_buf, sizeof(remaining_travel_buf),
> +               _("Remaining travel time:     %5.1f turns\n"),
> +               travel_time - (game.turn - pship->launch_turn));
> 
> -               "Success prob.:   %5d %%\n"
> -               "Year of arrival: %8s"),
> +               "%s"
> +               "Success prob.:   %5d %%"),
>               pship->population,
>               (int) (pship->support_rate * 100.0),
>               (int) (pship->energy_rate * 100.0),
>               mass_buf,
> -             travel_buf, (int) (pship->success_rate * 100.0), arrival);
> +             total_travel_buf, 
> +             remaining_travel_buf,
> +             (int) (pship->success_rate * 100.0));

Yes, but in many cases you don't *want* everything to be shown in terms
of turns.

> In the worst case we add a new packet PACKET_QUERY_DATE_OF_TURN which
> the client sents to the server and get the answer. But I'm against
> making the the implementation of the turn-to-date and turn-to-date
> transformation available to the client.

I think the client should know what the calendar is and be able to make
these calculations itself.  This should be very easy (we do it for just
about every other part of the rules).

jason