Complete.Org: Mailing Lists: Archives: freeciv-ai: May 2003:
[freeciv-ai] Re: improve diplomat logging + bugfix

[freeciv-ai] Re: improve diplomat logging + bugfix

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-ai@xxxxxxxxxxx
Subject: [freeciv-ai] Re: improve diplomat logging + bugfix
From: "Per I. Mathisen" <per@xxxxxxxxxxx>
Date: Tue, 6 May 2003 12:41:06 +0000 (GMT)

On Tue, 6 May 2003, Gregory Berkolaiko wrote:
> > > You logic escapes me.
> > >
> > > If
> > >   time_to_dest is == ut->move_rate
> > > it means the diplomat can reach the city in one move. So it's nice and
> > > convenient to bribe. Why is it any worse than any other city which we
> > > can reach in one move?
> >
> > It isn't so much about ttd == move_rate, but rounding the results too
> > early. A penalty which was meant to be there didn't kick in.
> Huh? Why do you want to penalise city which is 2 moves away more than a
> city 2 (sic!) moves away. If the only difference is that in the second
> city the diplomat would have some moves left. But if it does the bribing
> he would have no moves left anyway!And would probably be dead too!

Look at the larger picture.

In this function, the desired result isn't some kind of exact value which
is valid for each and every situation. We don't really need micro-level
correctness here. We're just trying to come up with an algorithm which
gives us diplomat production in just about the right number of cities, and
preferably in cities close to the action.

The previous code meant that cities if different players close to each
other produced too many diplomats overall. The fix changes this slightly
to the better (giving a better supply curve to use a term from economics).

Of course, if you can come up with a(n even) better algorithm here, all
the better. After all, you're the math wizard ;)

  - Per

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