Update of bug #18736 (project freeciv):

                  Status:                    None => In Progress            
             Assigned to:                    None => jtn                    
        Operating System:       Microsoft Windows => Any                    
         Planned Release:             2.3.2,2.4.0 => 2.3.2,2.4.0,2.5.0      


Follow-up Comment #10:

Yeah, pretty obvious now I come to stare at the code again.

In city_build_unit():

  utype = pcity->production.value.utype;
  unit_shield_cost = utype_build_shield_cost(utype);

upgrade_unit_prod() changes pcity->production.value.utype (and indeed we see
"Production of Horsemen is upgraded to Knights in 22" in the reproduction
case), but then the cached utype and unit_shield_cost are used throughout the
rest of the function, and the upgraded utype isn't referred to.

But functions _called by_ city_build_unit() on pcity do see the upgraded unit,
and that includes city_production_build_units(), which determines how many
units to build. Since the shield cost of the upgraded unit is greater, it
returns 0 (which normally it would never do).

But since we passed the "so are we building some units then" test in
city_build_unit() (based on the cached data), we end up calling
choose_build_target() after building 0 units.

The obvious rearrangement fixes the basic problem. Need to think a bit about
the policy. I'm kind of tempted to special-case buying -- you hurried a
Phalanx last turn, you get a Phalanx, regardless of whether your R&D allows
you to build Pikemen now. (Too harsh?)

(Since city_production_build_units() is implicated, which is a
build-slots-related function, this could be a regression since 2.2.x --
haven't checked yet.


Reply to this item at:


  Message sent via/by Gna!

Freeciv-dev mailing list

Reply via email to