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

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Fri, Apr 05, 2002 at 07:50:03PM -0500, Ross W. Wetmore wrote:
> At 10:10 AM 02/04/04 -0600, Mike Kaufman wrote:
> >On Thu, Apr 04, 2002 at 06:01:27PM +0200, Raimar Falke wrote:
> >> On Thu, Apr 04, 2002 at 09:36:07AM -0600, Mike Kaufman wrote:
> [...]
> >>   if (activity==ACTIVITY_AIRBASE) {
> >>     if (total_activity (punit->x, punit->y, ACTIVITY_AIRBASE)
> >>         >= map_build_airbase_time(punit->x, punit->y)) {
> >>       map_set_special(punit->x, punit->y, S_AIRBASE);
> >>       unit_activity_done = TRUE;
> >> +     add to list
> >>     }
> >>   }
> >
> >yes, I would rather it be here rather than in set_special. Mainly because
> >it does the same exact thing, but gets called _a_lot_ less.
> 
> A refreshing touch of sanity on the performance front ...
> 
> >> > Besides, don't we have to have a list for each player?
> >> 
> >> You can't own specials.
> 
> I think "knowing" not "owning" may be the correct concept here. A list 
> of *known* airbases could be kept for every player. When an airbase is
> created, the list of players for which the tile is known (and seen?) 
> would be updated. As the FOW drifts in and the tile is no longer actively
> seen by a player, it would have the airbase removed from its list. Only
> destroyed airbases that can be seen would need to be removed at time of 
> destruction. Note that only players flagged by the known state and a
> fairly small per player list (i.e. almost always a minor subset of the
> total possible) need to be accessed on destruction, or loss of sight,
> so list maintenance is small. If the tile becomes known (again) and has, 
> an appropriate special then that player needs to update his list.
> 
> After the Apollo Program there is a single global list that everyone
> shares with only creation and destruction updates :-).
> 
> There is no reason not to apply the same logic to maintaining city lists
> on a per player basis.
> 
>  ... except that repetitive computation of triply nested for loops might 
> become extinct, to the annoyance of those that are fond of such things.
> 
> To use this technique for mobile units, one would call an update function
> if the XOR of the from and dest tile known states was different. But one 
> might want to do a better heuristic of the cycles updating vs computing
> at need would take before implementing this. 

Under the assumption that the global list would be small (<50) I think
that creating the "which-airbases-does-the-player-sees" at runtime is
fast.

As always it is easier to discuss this stuff with number.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "- Amiga Y2K fixes (a bit late, wouldn't you say?)"
    -- Linus Torvalds about linux 2.4.0 at 4 Jan 2001