Follow-up Comment #3, bug #20495 (project freeciv):
The patch attached seems like a fine thing to apply.
The consequences of the bug for ACTIVITY_SENTRY seem entirely harmless: the
client uses activity_count to display how many turns are left on an activity,
but of course not for ACTIVITY_SENTRY. So I think we get away with it.
> However, what should be done when loading savegames with such
> huge activity counts?
The obvious thing would be to apply the same check as in
update_unit_activity() and zero incoming activity_count for activities where
it makes no sense.
However, that means duplicating logic. We could just put in a special case for
ACTIVITY_SENTRY, to quell these warnings from the network code.
> It also affects Engineers when doing long job (e.g.
> transforming swamp to ocean in default ruleset) in all
...because of ACTIVITY_FACTOR=10 * transform_time=36: total required activity
will be 360 points, easily overflowing the uint8. Oh dear.
The consequence is that the time left displayed in the client will suddenly
increase, but the transformation will complete on schedule. Verified in
testing: a single Engineer transforming to ocean apparently jumps from 6 turns
left to 18 turns left.
I guess most people won't see this because they'll use gangs of Engineers for
such a project, and no individual unit will accrue enough points to trigger an
The obvious solution is to increase these fields to a uint16 (using an
optional capability on stable branches). I don't think this should lead to a
large increase in network traffic, as I think delta compression means that the
extra octet will only be transmitted once a turn, or whenever a unit changes
(I briefly toyed with not scaling by ACTIVITY_FACTOR over the network, but I
don't think that works.)
Reply to this item at:
Message sent via/by Gna!
Freeciv-dev mailing list