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

[Freeciv-Dev] Re: AI (THRESHOLD magic)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Raahul Kumar <raahul_da_man@xxxxxxxxx>
Cc: rf13@xxxxxxxxxxxxxxxxxxxxxx, Gregory Berkolaiko <gberkolaiko@xxxxxxxxxxx>, freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: AI (THRESHOLD magic)
From: Petr Baudis <pasky@xxxxxxxxxxx>
Date: Tue, 27 Nov 2001 14:11:36 +0100

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

Cool idea, that's true. Do you have also an idea why somewhere it's used
THRESHOLD and somewhere 2 * THRESHOLD?

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

You have a good point.

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

That wasn't my point, but that doesn't matter :-). We need to reconcile with
that imho. What would be your solution? How you would detect which direction
initially take?

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

That happens in more locations as well, basically in each location where we
multiply THRESHOLD by move_rate instead of fixed value up to 2 * SINGLE_MOVE.
However, it would be much more appropriate fix to modify
really_generate_warmap() to multiply THRESHOLD by move_rate than to multiply
THRESHOLD everywhere with a fixed value, which is obviously dainbramaged ;-) -
if I get the things in right way.


                                Petr "Pasky" Baudis

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

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