Summary: Forced disbanding of units due to shortages is
inconsistent between gold and shield upkeep
                 Project: Freeciv
            Submitted by: jtn
            Submitted on: Sun Mar 11 16:57:15 2012
                Category: None
                Severity: 2 - Minor
                Priority: 5 - Normal
                  Status: None
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
                 Release: S2_3
         Discussion Lock: Any
        Operating System: Any
         Planned Release: 



When a city isn't producing enough shields to maintain all its units, in
city_distribute_surplus_shields(), the candidates for disbanding are those
where utype_upkeep_cost(..., O_SHIELD)>0 for the unit. This includes those
units who happen to currently be enjoying free upkeep due to
EFT_UNIT_UPKEEP_FREE_PER_CITY (see city_units_upkeep()). (In fact it may
happen to prefer them, since the disband unit isn't chosen randomly.)

In contrast, when
city_balance_treasury_units()/player_balance_treasury_units() look for units
to disband due to lack of gold, they only consider units where
punit->upkeep[O_GOLD] > 0. This will spare any who happen to enjoy free upkeep
from their city at the moment. (And units are chosen randomly from the list,
not in iteration order.)

Overall, it doesn't matter -- the correct number of units get sold, and
they're interchangeable -- but it's a bit unfair. (It might in theory give a
player an incentive to do silly micromanagement of unit list orders, to
control which get disbanded.)

It might be nicer if:
* Production-based disband picked a random unit from the candidates.
* Gold-based disband considered units currently enjoying free upkeep, by
looking at utype_upkeep_cost().
** Wrinkle: player_balance_treasury_units() would have to be careful not to
disband units with no homecity (hence no upkeep, hence no use disbanding --
also, particularly valuable and hence annoying if disbanded).


Reply to this item at:


  Message sent via/by Gna!

Freeciv-dev mailing list

Reply via email to