[freeciv-ai] Re: (PR#10110) AI underestimates Temples

["Per I. Mathisen" <per@xxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=10110 >

On Wed, 15 Sep 2004, Jason Short wrote:
> >>Of course this is hard since you're not allowed to check SP_ELVIS.
> >
> > Why are we not allowed to check SP_ELVIS??
>
> In theory, because I want SP_ELVIS go to away.

Then we need to iterate over all specialists that increase luxury. When we
get that. (Or whatever output that reduces unhappiness, when/if we get
generalized outputs.)

> In actuality, because it won't help.There used to be (maybe still is)
> code that assumes for every 2 luxury we can get rid of 1 elvis and put
> him to work on the best tile.Thus for every 2 luxury we get
> ai_calc_best_tile_value() points.Unfortunately this doesn't work even
> with the current system because the luxury an elvis generates can be
> changed by effects or edited directly in the ruleset.

Not by effects, yet. But I want such effects eventually. Yes, we should of
course not assume such hardcoded values, and should look up the
appropriate values from the ruleset, and when we get effects that apply,
do apply them, but other than that, I do not really see your point.

> > We can iterate through all cities first, calculate some want for
> > happy/content buildings, and store it in pcity->ai.contentwant or
> > something.
>
> Are we allowed to do a full recalc here? This would be quite
> sufficient.Each city could have a value pcity->ai.contentment[]
> holding an array of goodness for contentmentvalues up to a certain
> level (probably 4).

We cannot do a full recalc, but if it is a general value in pcity, then it
can be filled out as part of generic_city_refresh(), which is called
whenever the city changes, so when we are passed pcity, it will be correct
even if we don't refresh it ourselves.

> At its core granary just increases food output. It allows 50% of food
> to be saved when certain things happen. Thus it basically grants extra
> food at an ammortized rate of food_surplus/2.
>
> So:
>
>  v += pcity->food_surplus * food_weighting(pcity->size) / 2;

Interesting. Except that we it should be
   v += pcity->food_surplus * food_weighting(pcity->size) * 100 / amount;

>  v += (c - 1) * food_weighting(3);
>
> it might be useful here to know the average or median size of the cities
> we own.It might also be useful to cache the food_weighting() values or
> to have a pcity->food_weighting.

The latter seems more reasonable. We can create and cache these values
once before entering the building evaluation code.

> Also as a side note some places divide v by MORT.v should be
> ammortized, but it should be done for all calculationsof v.And for it
> to work it needs to be done everywhere building goodness is calculated
> (miss one place and you'll end up completely breaking things).

v is amortized at the end of the adjust function already.

  - Per