Summary: Pool worker progress on terrain projects for
Submitted by: jtn
Submitted on: Sunday 08/29/10 at 00:27
Priority: 5 - Normal
Status: In Progress
Assigned to: jtn
Discussion Lock: Any
I wrote in bug #15510:
> Another related issue is that I think progress towards an
> improvement is somehow accounted to individual engineers;
> if I have one working on a transformation, and later put
> another one on the same activity/tile, after that, if I
> want to take one of the engineers off the project, how long
> the remaining one will take to finish the transformation
> depends on which one it is (and I have no way of telling
> them apart). I haven't tested this rigorously, though, so
> I may be wrong about this.
Patch not written yet, but here's a sketch of the design I have in mind to
deal with this.
I want to make it so that progress (activity_count) is accounted to a project
(i.e. "the airbase on (42,23)") rather than individual units (as currently) --
or at least to behave that way.
One way of doing this would be to maintain a list of in-progress projects in
the per-tile structure, but that's tedious. Instead I propose to keep the
activity_count in the units (since units can only be working on one project
at once), but move the points around between units working on the same
project if one of them stops (for whatever reason), so that points are not
lost. (Unless the last unit stops working on a project, in which case it will
be abandoned, as currently.)
The client doesn't display individual activity_counts, just aggregated
progress for the tile; as long as it continues to do that, this
implementation detail will be invisible. (It does mean that an out-of-sync
client could in theory report progress more inaccurately than it would
I can't think of any undesirable effects from this. The only slightly unusual
behaviour this enables that I've thought of is this:
* Unit A is working on a project.
* Unit B moves onto the tile, using up all its movement points. It joins in
the project; although it will contribute no progress this turn.
* Unit A, which still has its MP, stops the project and uses them to do
* No progress on the original project is lost.
I don't think that's actually a problem though. Think of unit B as just
keeping the rain off until next turn :)
Reply to this item at:
Message sent via/by Gna!
Freeciv-dev mailing list