Complete.Org: Mailing Lists: Archives: freeciv-ai: February 2005:
[freeciv-ai] Re: [Freeciv-Dev] Re: (PR#11995) Stupid AI Creates Tall Sta

[freeciv-ai] Re: [Freeciv-Dev] Re: (PR#11995) Stupid AI Creates Tall Sta

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Subject: [freeciv-ai] Re: [Freeciv-Dev] Re: (PR#11995) Stupid AI Creates Tall Stacks
From: "Benedict Adamson" <badamson@xxxxxxxxxxx>
Date: Fri, 25 Feb 2005 10:28:42 -0800
Reply-to: bugs@xxxxxxxxxxx

<URL: >

Jason Short wrote:
> That's quite a patch.  The logic seems clear enough although I can't be 
> sure of the specifics.  How much testing has this gotten?

Quite a bit of testing and debugging. I've done a (calendar) month of 
work on it.

> One question I have (probably for after the patch goes in), is how are 
> the goto destinations obtained in the first place?  What I mean is, the 
> logic now (and in your patch) is that we know where we want to go and we 
> create a PF map to get there.  Creating the PF map is very expensive. 
> Probably this map was already created once in determining where to go, 
> and should be saved rather than created again.

Correct, except for the case that a warmap is used for creating the 

Note that, even if performed the optimisation you suggest, there might 
still be times when we wanted the AI to do PF twice. The first PF we 
might use extra-cost callbacks to favour particular destinations, then 
use a more typical PF to find the quickest route there.

Once we have the movemap code incorporated, I guess we could compute 
some destinations using the movemap.

> It doesn't seem like that method would work.  is_pos_dangerous is only 
> useful one or more turns in the future at which point the tall stack is 
> likely to have disbanded.  I think it's only usefull to look at tall 
> stacks that would be created at the end of the current turn, rather than 
> trying to look ahead.


> I think amphibious gotos need more documentation.  Does this work for 
> units that are inside an island moving to another island, or only for 
> units that are already being ferried?

I'll add some documentation. It assumes you are starting on a ferry. It 
is like the overlap movement code, but allows movement further inland, 
and (importantly for this patch) eliminates the need for a separate 
computation to select a beachhead.

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