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

[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: "Mike Kaufman" <kaufman@xxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 1 Nov 2004 11:59:21 -0800
Reply-to: rt@xxxxxxxxxxx

<URL: >

On Mon, Nov 01, 2004 at 11:32:19AM -0800, Jason Short wrote:
> <URL: >
> Per I. Mathisen wrote:
> > You call is_ocean_near_tile(acity->tile) a lot of times. Perhaps we should
> > add a new variable bool pcity->coastal instead, since the function call
> > above is comparatively expensive.
> I would be extremely wary of adding new global data fields that will 
> need to be kept updated.

actually this is probably one of the best of any of the candidates for a
global data field.

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

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


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