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: Petr Baudis <pasky@xxxxxxxxxxx>
Cc: rf13@xxxxxxxxxxxxxxxxxxxxxx, Gregory Berkolaiko <gberkolaiko@xxxxxxxxxxx>, freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: AI (THRESHOLD magic)
From: Raahul Kumar <raahul_da_man@xxxxxxxxx>
Date: Tue, 27 Nov 2001 22:09:10 -0800 (PST)

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

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

The threshold value controls how many squares we evaluate to. The move costs
get fiddled with a lot. Some people thought it would be a good idea to make
move costs on land(for sea units) and unexplored terrain higher cost.

> > You want to maximise the distance for caravans.
> You have a good point.

Great, we agree. Now the tricky part, working out what works best for 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. 

What's happening there is that we are trying to discourage movement into
squares by making it cost far more than the nearby squares. But now, we thanks 
to parts 1 & 2 we have explored all partially exposed squares. We now want to 
go explore the unknown, so we have to set the unknown value to much higher than
it normally needs to be because the move costs of an unknown square is very
Am I making myself clear? Gregory Berkolaiko is the man to ask about these
warmap questions.

> 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 ;-)
strator, hobbies = IPv6, IRC
> Real Users hate Real Programmers.
> Public PGP key, geekcode and stuff:

Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.

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