Complete.Org: Mailing Lists: Archives: freeciv-dev: March 2002:
[Freeciv-Dev] Re: [RFC] Caching AI values
Home

[Freeciv-Dev] Re: [RFC] Caching AI values

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: rf13@xxxxxxxxxxxxxxxxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: [RFC] Caching AI values
From: Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>
Date: Wed, 20 Mar 2002 19:16:37 +0000 (GMT)

On Tue, 19 Mar 2002, Raimar Falke wrote:

> On Tue, Mar 19, 2002 at 08:36:02PM +0000, Gregory Berkolaiko wrote:
> > 
> > That might be right, but let's have a look at the overall picture:
> > 1. Unit A thinks about moving to city C to kill things around.  The number 
> > of things to kill around C is calculated and recorded in struct city C.
> > ----
> 
> > 2. we are doing other stuff, but whenever we kill a unit, we have to 
> > figure out if it was counted in the targets_around_C and if it was, 
> > subtract its value

I thought this problem over and I got this great idea which, it seems, is 
the same as you propose below (although I do not fully understand your 
wording):

If a unit is killed, we call a function which does not recalculate 
anything by itself, but instead increments some "time" variable to show 
that the cached values have expired.  Then, the next time we try to access 
cached values, we will have to recalculate them.  This way we do not 
recalculate anything that isn't going to be used and avoid all these 
complex decisions "what to update" as well.

Of course each type of cached values will have it's own "time" variable 
associated with it.

> 
> This would indead hard. What about "update these targets_around_foo
> counter of all cities after a unit is killed".
> 
> > 3. Now unit B thinks about moving to city C and it can use the up-to-date 
> > number of targets around.
> > 
> 
>       Raimar
> 
> 



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