Complete.Org: Mailing Lists: Archives: freeciv-ai: February 2003:
[freeciv-ai] Re: (PR#2477) Improved Auto-Explore
Home

[freeciv-ai] Re: (PR#2477) Improved Auto-Explore

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Cc: freeciv-ai@xxxxxxxxxxx
Subject: [freeciv-ai] Re: (PR#2477) Improved Auto-Explore
From: "Cameron Morland via RT" <rt@xxxxxxxxxxxxxx>
Date: Wed, 5 Feb 2003 19:12:09 -0800
Reply-to: rt.freeciv.org@xxxxxxxxxxxxxx

On Wed, Feb 05, 2003 at 11:07:41AM -0800, Gregory Berkolaiko via RT wrote:
> 
> Looked at explorer23.
> 
> Problem 1: explorer strays from the shore (rare).  Savegame attached (try 
> it with the original explorer23, before fixing other bug detailed below).
> 
> Problem 2: verrrry slow.  The problem is two-fold.  First, you don't set 
> activity to IDLE, so handle_unit_move_request fails and you have to 
> generate warmap for _every_ move.  Second, the code in explorer_desirable 
> is rather slow and it's called often.  The former is easily fixable, 
> just add:
> 
>   /* Idle unit, since otherwise handle_unit_move_request fails! 
>    * TODO: Fix it and remove this idling */
>   if (punit->activity != ACTIVITY_IDLE) {
>     handle_unit_activity_request(punit, ACTIVITY_IDLE);
>   }

Yeah, I was wondering why it was so slow, but I figured some other
part of the AI code was broken. Adding this helps a lot.

> before PART 1.  Still, when warmap does have to be calculated, the whole
> thing is significantly slower.  The pig is is_within_own_city_radius,
> according to my analysis (60%).  But unless we remove it altogether, I
> don't know what can be done.  likely_ocean is also quite bad (30%).  But
> maybe we can help by checking the warmap distance first and if it is
> outside reasonable bounds (even MAXCOST would be better than nothing), not
> call explorer_desirable at all.  This should work for bigger maps.

I think we could remove is_within_own_city_radius, or simply check a
square as big as the city, which should be considerably faster.

> Other comments:
> 
> 3. likely_coastline can return bool (and be renamed into
> is_likely_coastline) same about likely_trireme_loss_pct
> (is_likely_trireme_loss), this function you can shorten quite a bit.

> 4. you obsolete tile_is_accessible.  Please check if this function is 
> undeed not needed (i.e. you didn't forget to put it where it should be) 
> and then remove it.
> 
> 5. get_range_at should not peek under the fog (relevant handicap for AI is 
> H_MAP, I think).  Or it can be killed altogether :)

I think I'll toast it; I put it in at the beginning because I was
trying to make it act as similar to the old code as possible, but
even if somebody were to use fortresses, they wouldn't use them
extensively enough for the explorer to care.

I'll look at the rest over the weekend, I really need to get this
patch off my plate soon.

-- 
+-----------------------------------------------------------------
| PGP http://www.eng.uwaterloo.ca/student/cjmorlan/public-key.pgp
| Cameron Morland             ----             Cameron@xxxxxxxxxx
|
| Finally, antitrust. Let's break up these big companies. When we went
| into Germany and Japan in 1945 we broke their media up. We said
| concentrated media was anti-democratic and promoted fascism. I think
| we should take a dose of our own medicine.
|     --Robert McChesney
+-----------------------------------------------------------------

Attachment: pgpojuMYsWh3F.pgp
Description: PGP signature


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