[freeciv-ai] Re: (PR#10110) AI underestimates Temples
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
<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
- [freeciv-ai] Re: (PR#10110) AI underestimates Temples, Jason Short, 2004/09/14
- [freeciv-ai] Re: (PR#10110) AI underestimates Temples, Per I. Mathisen, 2004/09/15
- [freeciv-ai] (PR#10110) AI underestimates Temples, Mateusz Stefek, 2004/09/15
- [freeciv-ai] Re: (PR#10110) AI underestimates Temples, Jason Short, 2004/09/15
- [freeciv-ai] Re: (PR#10110) AI underestimates Temples, Marko Lindqvist, 2004/09/15
- [freeciv-ai] Re: (PR#10110) AI underestimates Temples, Jason Short, 2004/09/15
- [freeciv-ai] Re: (PR#10110) AI underestimates Temples, Per I. Mathisen, 2004/09/15
- [freeciv-ai] Re: (PR#10110) AI underestimates Temples, Per I. Mathisen, 2004/09/15
- [freeciv-ai] Re: (PR#10110) AI underestimates Temples,
Jason Short <=
- [freeciv-ai] Re: (PR#10110) AI underestimates Temples, Jason Short, 2004/09/15
- [freeciv-ai] Re: (PR#10110) AI underestimates Temples, Marko Lindqvist, 2004/09/15
- [freeciv-ai] Re: (PR#10110) AI underestimates Temples, Vasco Alexandre da Silva Costa, 2004/09/15
- [freeciv-ai] (PR#10110) AI underestimates Temples, Mateusz Stefek, 2004/09/16
- [freeciv-ai] Re: (PR#10110) AI underestimates Temples, Per I. Mathisen, 2004/09/16
- [freeciv-ai] (PR#10110) AI underestimates Temples, Mateusz Stefek, 2004/09/16
- [freeciv-ai] Re: (PR#10110) AI underestimates Temples, Per I. Mathisen, 2004/09/16
- [freeciv-ai] Re: (PR#10110) AI underestimates Temples, Mateusz Stefek, 2004/09/16
- [freeciv-ai] Re: (PR#10110) AI underestimates Temples, Benoit Hudson, 2004/09/16
- [freeciv-ai] Re: (PR#10110) AI underestimates Temples, Vasco Alexandre da Silva Costa, 2004/09/16
|
|