[Freeciv-Dev] Re: AI

[Raahul Kumar <raahul_da_man@xxxxxxxxx>]

--- Petr Baudis <pasky@xxxxxxxxxxx> wrote:


> > int maxcost = pplayer->ai.control ? 2 * THRESHOLD : 3;
> > 

> 
> Discard that. After two hours of digging in various places of code, I finally
> realized it's something like how much tiles distant targets we should care
> about.  We just need to replace 6 * THRESHOLD in some code with 2 * THRESHOLD
> *
> SINGLE_MOVE (see my TODO for my personal tips - basically, in relation to
> warmap costs, THRESHOLD _must_ be multiplied by move_rate - and more than 2 *
> THRESHOLD doesn't make much sense).  For example, we care only about huts
> maximally 24 tiles away from us in the code above.
> 

One thing you missed as to why the 24 tile limit exists: It's due to aircraft.
No aircraft can successfully reach any destination on the third move without
finding a city or aircraft carrier on the second. Other units, in particular
sea units could possibly use a much higher threshold.


> The worst thing in current AI is there may be various thesis about what one
> thing means, and they all look sensible until one will try to abide them :-).

> Because they don't need. It does not relate to unit type at any rate, it just
> tells you how far targets you should care about.

Unit type does make a difference. Why should settlers have a high threshold
value? Caravans need a much bigger threshold value than they currently have.
You want to maximise the distance for caravans.
 
> Attached yet another patch with yet another comment describing yet another
> thesis about still same THRESHOLD.
> 
> I would make also patch converting 6 to 2*SINGLE_MOVE, however there is
> something I want to discuss first. I noticed that in some code we use
> SINGLE_MOVE, and in yet another code we use move_rate. Both in relation to
> still same code in really_generate_warmap(), which is using SINGLE_MOVE for
> its
> threshold calculations.  That seems really odd to me, as we then consider
> some
> places for units with high move_rate (e.g. boats) as too far away, won't we?

This I have a problem with. Why calculate out the entire path all the time?
The route we are taking could have changed by the time we get there ( enemy
units, cities, railroad and road improvs etc). 

> E.g. in first part of exploring code we don't care about real unit's
> move_rate
> too, so we will compare values with same multipliers, that would be at least
> partially ok. However, in part three, we subscript value multiplied by
> SINGLE_MOVE from value multiplied by move_rate! So we get malformed (too big)
> results IMHO.

You've confused me. Can you give me a Filename:Function:Line no ref to the
things you are talking about? In particular, if things happen in part three
as you describe, that is almost certainly a bug. 



__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1