Complete.Org: Mailing Lists: Archives: freeciv-ai: September 2004:
[freeciv-ai] Re: (PR#10110) AI underestimates Temples
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: mstefek@xxxxxxxxx
Subject: [freeciv-ai] Re: (PR#10110) AI underestimates Temples
From: "Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 15 Sep 2004 10:04:56 -0700
Reply-to: rt@xxxxxxxxxxx

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

Per I. Mathisen wrote:
> <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.)

Yeah, except that the specialists may have other output as well.

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

If you have a marketplace and a bank, each elvis generates 4 luxury.  If 
you assume that for each 2 luxury you generate you can put one elvis to 
work in the fields, your calculations will be way off.

Or to put it another way, stock exchange isn't as good as marketplace. 
Marketplace increases the output by 50%.  Stock exchange only increases 
it by 25%.

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

Hmm, except generic_city_refresh() is still called all the time.  These 
AI values should only be filled out once per turn at most, when we 
recalculate city productions.

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

amount / 100, I think.  See elsewhere why looking at the food_surplus 
directly may not be so good.  But a factor of amount/100 (or K * amount 
/ 100 for some constant K) should always be included here I think.  The 
bonus from increasing amounts is linear for granary.

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

Yes.

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

OK.  What is the use of MORT in the EFT_GIVE_IMM_TECH calculation?

And are you sure you ammortize in the other (per-tile) calculation of 
building goodness?

jason




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