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

["Raimar Falke" <rf13@xxxxxxxxxxxxxxxxx>]

On Mon, Feb 17, 2003 at 12:52:51AM -0800, Jason Short wrote:
> 
> [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???

Yes. But it is only a hack to support old client/servers and old
savegames. I would really like to remove it but than you won't be able
to load old savegames.

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

I have converted the client code and the client doesn't need more
dates. It makes the overall design easier.

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

The spaceship part above is the _only_ case in the current code where
such things happen. So about what cases are you speaking.

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

This is unneeded complexity. What is the gain?

        Raimar

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