You are not logged in

> ...although the logic in patch #3693 (food upkeep) is unit-type
> specific, isn't it? It could be worrying about Settlers' food
> upkeep even if it would end up building Workers?

Yes. Though this (and pop cost part too) might work perfectly at the moment by using same mechanism to select unit to build. I cannot tell any situation where the result would differ between the time want is calculated and the time actual build target is chocen, or it's at least very rare situation; player somehow gaining tech enabling new unit between the two parts of the code - and even then it would really hurt if it had calculated want with unit without food upkeep/pop-cost, and would then use that want to build unit with food upkeep/pop-cost, maybe even one it cannot sustain (I don't know if it could end turning whole city to Settler in a one in a billion turns chance with such a ruleset)

> It's calculating general UTYF_SETTLERS want, not that of
> specific unit type.

Hm, yes, good point.
Still, this can't be helping with the AI's reluctance to improve food production, can it?

> In somewhat related note it's not necessarily good idea that
> it's worker want of the very city used when deciding if worker
> should be built.

Hm, yes, indeed. You want some way to export wants to other cities. And a generalised background "our civ needs more workers" probably won't do, as you could end up with piles of workers on the wrong continent (and I read the AI tends not to transport them). So the want has to be exported only to "nearby" cities, I guess, FSVO nearby.
That speculation rather outruns my knowledge of the AI, anyway, so could be worthless. And it certainly belongs in another ticket.

Taking the unit type in to account here would have its problems, though. It's calculating general UTYF_SETTLERS want, not that of specific unit type. In theory this want may make it later to build a UTYF_SETTLER unit, but of different type than virtual one used here.

In somewhat related note it's not necessarily good idea that it's worker want of the very city used when deciding if worker should be built. The cities that need workers most probably need other things too (new underdevelopet cities). Even higher wants may win over quite high worker want, such a city might not be able to build workers (chicken & egg), and even when it builds workers, that is away from other important projects. At the same time well-off nearby city may have no urgent tasks at all, so it could very well build the workers for the other city to use.

While reviewing patch #3693, I noticed that in contemplate_terrain_improvements(), this code:

(which runs in the context of F_SETTLERS units, which actually means terrain improvers) is I think considering units with a population cost.

However, unit_foodbox_cost() doesn't actually look at the unit type; it seems to assume that any unit it might be called with has a nonzero pop_cost and thus consume food from the city when created. Clearly this isn't true of Workers in the default ruleset.

unit_foodbox_cost() seems bogus in other ways (at least on S2_4):

If passed a non-virtual unit, it returns a fixed cost of 30. (Fortunately it never is.)

Asserts pcity != NULL only after use.

Doesn't consider pop_cost > 1.

(I assume the calculation is not referring to the effect on city food of actually building the unit -- as far as I can tell, there is none beyond clipping it, which itself isn't accounted for -- but the marginal amount of food that will be required to get back to where the city would have been had it not built the unit.)

If these are real issues, I guess that fixing them is likely to mess up balance / fudge factors.

Copyright (C) 2004-2006, the Gna! people. Posted items are owned by whoever posted them.
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.