Complete.Org: Mailing Lists: Archives: freeciv-ai: November 2004:
[freeciv-ai] Re: (PR#8992) Patch: Building ferries
Home

[freeciv-ai] Re: (PR#8992) Patch: Building ferries

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Gregory.Berkolaiko@xxxxxxxxxxxxx
Subject: [freeciv-ai] Re: (PR#8992) Patch: Building ferries
From: "Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 1 Nov 2004 12:03:26 -0800
Reply-to: rt@xxxxxxxxxxx

<URL: http://rt.freeciv.org/Ticket/Display.html?id=8992 >

Mike Kaufman wrote:

>>pcity->coastal would need to be updated at least every turn.
> 
> no. this needs to be updated only three times. Once on city creation. Once
> when a tile is terraformed. This means looking only at the adjacent tiles
> to the terraformed one looking for a city to update. Once when global
> warming happens. This will mean iterating over all cities to check for
> update. The latter two are very rare events. You stick the check and update
> in the functions that do the terraforming and warming. Solved. The first
> happens once. You stick the check in create_city(). 

AFAIK there is nothing preving a ruleset from setting irrigation_result 
to "ocean".

I think this stored data is similar to ptile->move_costs.  The move 
costs need only be updated when the tile's terrain type or special, in 
map.c.  Except that as the code is developed there have become more and 
more special cases until now this value does more harm than good.

>>This is a problem in many other places in the code.  Adding values like 
>>this that are assumed to be correct creates many dependencies that are 
>>not easy to keep track of (or even to find).  If you do use precomputed 
>>values, you should always treat them as approximations and assume they 
>>might be wrong.
> 
> this value should only be used in the server. The client should use the
> function all the time.

Yes.  In this case it should be pcity->server.coastal.

jason




[Prev in Thread] Current Thread [Next in Thread]