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(pcity);
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:
<http://gna.org/bugs/?18736>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
