Complete.Org: Mailing Lists: Archives: freeciv-ai: May 2003:
[freeciv-ai] Re: [Freeciv-Dev] (PR#4137) Auto-Explore with new path-find

[freeciv-ai] Re: [Freeciv-Dev] (PR#4137) Auto-Explore with new path-find

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: cameron@xxxxxxxxxx
Subject: [freeciv-ai] Re: [Freeciv-Dev] (PR#4137) Auto-Explore with new path-finding
From: "Gregory Berkolaiko" <Gregory.Berkolaiko@xxxxxxxxxxxx>
Date: Sat, 3 May 2003 13:16:47 -0700
Reply-to: rt@xxxxxxxxxxxxxx


On Sat, 3 May 2003, Cameron Morland wrote:

> This patch merges parts 1 and 2 of the explorer code into one. Note that
> this does change the behaviour of the explorer somewhat, since slightly
> distant highly-desirable tiles are preferred over adjacent tiles (which
> were always preferred before). I also fiddled with the desirability
> definitions so they make more sense.
> The code works by searching out from the current location using
> simple_unit_path_iterator (where the path length is be non-decreasing,
> as I understand it). It then keeps track of the greatest possible
> desirability score at each given location (which is non-increasing). As
> soon as the best score found so far exceeds the best possible score at
> the given range, or we run out of tiles, we can be certain that the best
> tile found is in fact the best tile available, so we break.

Very good!  That's precisely what I had in mind.  Well done!

Here are some comments:

1. It took me awhile to remember why you multiply by 100 in 
BEST_NORMAL_TILE.  A comment would be helpful here ("TER_SCORE is given 
per 1% of certainty about the terrain").

2. Same place, I think

3. A bad thing about these defines is that they are not constants: they 
depend on vision_range.  I don't know what to do about it though...  Maybe 
set vision_range to 1 ?

4. Remove the TODO in the comment ;)

5. put the #include together with other includes, at the top of the files.  
Raimar wrote something about ordering includes too...

6. To do the early breaking, you multiply the BEST_POSSIBLE_SCORE by the 
dist factor.  Which means you do a pow every step.  I would instead 
calculate the furthest dist we are prepared to go each time we update 
most_desireable.  That would be logarithm.

7. What is this check doing there?
+    if (punit->moves_left == 0) {
+      /* We can't move on anymore. */
+      return TRUE;
+    }
+  } simple_unit_path_iterator_end;

8. Please put a TODO "read the path off the map we made".
+    /* Go there! */
+    if (!ai_unit_goto(punit, best_x, best_y)) {
+      return FALSE;
+    }

Some comments on PF use: 

9. The PF should respect ZoC and avoid unknown using a proper TB-callback.
It might also want to try to walk _past_ unknown, so a nice EC-callback 
can be used here.  

If you are unsure of the PF and how to use it, I will do the PF-related 


> I'm going to be away for the next week or so (biking from Waterloo to
> Ottawa), but here it is for your consideration. It reduces the size of



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