bugFreeciv - Bugs: bug #20522, AI assumes all terrain improvement...

 
 
Show feedback again

bug #20522: AI assumes all terrain improvement units (F_SETTLERS) cost population?

Submitted by:  Jacob Nevins <jtn>
Submitted on:  Sun 17 Feb 2013 03:47:07 PM UTC  
 
Category: aiSeverity: 3 - Normal
Priority: 5 - NormalStatus: None
Assigned to: NoneOpen/Closed: Open
Release: S2_4 r22361Operating System: Any
Planned Release: 

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Tue 19 Feb 2013 02:30:40 AM UTC, comment #4:

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

Marko Lindqvist <cazfi>
Project Administrator
Tue 19 Feb 2013 12:49:08 AM UTC, comment #3:

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

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

Jacob Nevins <jtn>
Project Administrator
Mon 18 Feb 2013 10:11:25 PM UTC, comment #2:

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

Jacob Nevins <jtn>
Project Administrator
Mon 18 Feb 2013 12:48:15 AM UTC, comment #1:

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.

Marko Lindqvist <cazfi>
Project Administrator
Sun 17 Feb 2013 03:47:07 PM UTC, original submission:

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.

(Only checked S2_4.)

Jacob Nevins <jtn>
Project Administrator

 

(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by cazfi (Posted a comment)
  • -unavailable- added by jtn (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    No Changes Have Been Made to This Item
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup