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

["Raimar Falke" <rf13@xxxxxxxxxxxxxxxxx>]

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.


> >>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.
> 
> What about the UI?

??

> >>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.

> 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));

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.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Make it idiot-proof and someone will make a better idiot."