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

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

Raimar Falke wrote:
> On Mon, Feb 17, 2003 at 12:52:51AM -0800, Jason Short wrote:
> 
>>[rfalke - Sat Feb 15 10:03:08 2003]:

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

In that case, the intervals themselves are variable.  The math is still 
easy, it just makes the interface (for the user) harder.

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

Hmm, I hadn't considered savegames.  But I don't see why they're a 
problem.  If you load a savegame you just use the default calendar in 
loading; you have to convert the values (that you load) from years into 
turns but this is easy.  I still don't see why a hard-coded list of 
turn->year values is helpful.

We should use a manditory capability to avoid network compatability 
issues.  We have so many of them right now that one more will make 
little difference.

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

OK, that is reasonable.

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

I gave several hypotheticals.  None of them are in the current code.

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

It is simpler and _far_ better than adding PACKET_QUERY_DATE_OF_TURN. 
But if it is not needed yet then, well, it is not needed yet.

jason