Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2001:
[Freeciv-Dev] Re: AI

[Freeciv-Dev] Re: AI

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: rf13@xxxxxxxxxxxxxxxxxxxxxx
Cc: Raahul Kumar <raahul_da_man@xxxxxxxxx>, Gregory Berkolaiko <gberkolaiko@xxxxxxxxxxx>, freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: AI
From: Petr Baudis <pasky@xxxxxxxxxxx>
Date: Sun, 25 Nov 2001 21:22:02 +0100

> > > Threshold what do you think this magic no is? I was initially inclined to
> > > believe that threshold * some movement factor was meant to be the max no 
> > > of
> > > squares a unit can move in one turn.
> Well, IMHO not in one turn, but in reasonable number of turns. Maximal tiles
> we can move through in one move are 3 (roads) (see bellow for railroad), and
> current value is 12, so the reasonable number is 4 turns. So, basically, in
> most of the code, we accept anything where we can get in maximally 4 turns.
> So if we glance at e.g. exploring code, we see:
> int maxcost = pplayer->ai.control ? 2 * THRESHOLD : 3;
> So, if we aren't AI, just in autoexplore mode, we hunt only huts to which we
> can get in one turn, otherwise we hunt even to the distance of 8 turns, seems
> to me.

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.

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 :-).

> > >                                      Unfortunately, railroad move cost = 0
> > > makes it fairly useless. 
> We always compare threshold to warmap cost (if warmap cost is less than
> threshold, we accept it, basically) - and if railroad is built to there, 
> warmap
> cost is zero, so it's always less, and we accept it - also because we can get
> there in less that 4 turns. It is not useless, because you also must keep on
> the mind combined situations, where we can use railroad only for a part of our
> trip.
This should be true anyway, just with s/threshold/threshold*move_rate/g. And
we can get there in less than 12 turns.

> > >                          And why are threshold nos not far lower for sea
> > > and air units?
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.

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?
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.

What do you think? I'm being confused from this all enough actually, and I
strongly suspect I overlooked something. Need other opinion :-).


                                Petr "Pasky" Baudis

UN*X programmer, UN*X administrator, hobbies = IPv6, IRC
Real Users hate Real Programmers.
Public PGP key, geekcode and stuff:

Attachment: threshold-comment.diff
Description: Text document

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