Complete.Org: Mailing Lists: Archives: freeciv-dev: April 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: Mike Kaufman <kaufman@xxxxxxxxxxxxxxxxxxxxxx>
Cc: rf13@xxxxxxxxxxxxxxxxxxxxxx, Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>, "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>, freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: [RFC] Caching AI values
From: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Date: Fri, 05 Apr 2002 19:50:03 -0500

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. 

>-mike

Cheers,
RossW
=====




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