liamjd/UntitledColonyBuilder

Fork 0

ConstructionTask: placing a building enqueues construction #70

New issue

Closed

opened 2026-09-07 20:37:20 +01:00 by liamjd · 1 comment

liamjd commented

2026-09-07 20:37:20 +01:00

Owner

Part of milestone #5. Depends on #66 and #67.

The first concrete task type. Buildings.place() already carries the comment that status will become PLANNED once task management exists.

AC:

Buildings.place() creates the building with status PLANNED and enqueues a ConstructionTask targeting the building's entrance cell
Starting work moves the building to UNDER_CONSTRUCTION; work_remaining starts at type.build_time ticks
Completion moves the building to BUILT and emits a signal (building_built or a status-changed signal; decide and note in the PR)
Buildings receives its TaskManager by injection from game.gd, the same way it receives map, so the registry still works standalone in tests
Cancelling the task while PLANNED removes the building record (the deconstruction issue defines the UI that triggers this)
Unit tests through the registry: place enqueues one task; completing it flips status; count_of and at_limit still count PLANNED buildings toward the limit

Part of milestone #5. Depends on #66 and #67. The first concrete task type. `Buildings.place()` already carries the comment that status will become PLANNED once task management exists. AC: - `Buildings.place()` creates the building with status PLANNED and enqueues a `ConstructionTask` targeting the building's entrance cell - Starting work moves the building to UNDER_CONSTRUCTION; `work_remaining` starts at `type.build_time` ticks - Completion moves the building to BUILT and emits a signal (`building_built` or a status-changed signal; decide and note in the PR) - `Buildings` receives its `TaskManager` by injection from game.gd, the same way it receives `map`, so the registry still works standalone in tests - Cancelling the task while PLANNED removes the building record (the deconstruction issue defines the UI that triggers this) - Unit tests through the registry: place enqueues one task; completing it flips status; count_of and at_limit still count PLANNED buildings toward the limit

liamjd added this to the Task management for pawns milestone

2026-09-07 20:37:20 +01:00

liamjd added the

enhancement

label

2026-09-07 20:37:20 +01:00

liamjd referenced this issue

2026-09-07 20:37:21 +01:00

Render PLANNED and UNDER_CONSTRUCTION buildings distinctly from BUILT #71

liamjd referenced this issue

2026-09-07 20:37:22 +01:00

Demolish mode and DeconstructionTask #72

liamjd referenced this issue

2026-09-07 20:37:23 +01:00

HaulTask as a child of ConstructionTask #73

liamjd referenced this issue

2026-09-07 20:37:24 +01:00

Pawn work loop: claim, navigate, work, complete #75

liamjd referenced this issue

2026-09-12 08:21:05 +01:00

Decide and apply the unit of BuildingType.build_time #88

liamjd referenced this issue

2026-09-17 08:52:09 +01:00

Denominate build effort in pawn-days #107

liamjd referenced this issue from a commit

2026-09-17 08:52:10 +01:00

Denominate build effort in pawn-days, not bare integers

liamjd commented

2026-09-17 08:52:22 +01:00

Author

Owner

AC correction, from #88 (PR #107).

This issue's second AC reads:

work_remaining starts at type.build_time ticks

All three parts of that are now stale:

The field is build_days, not build_time.
It is days, not ticks — convert with type.build_work_ticks(), which is the single conversion site. Do not call GameCalendar.days_to_ticks() here directly, or the conversion exists twice.
The unit is pawn-days, i.e. labour, not elapsed time. A 10 pawn-day mine is 10 days for one pawn and 3.3 for three. work_remaining counts work actually performed, so walking to the site and hauling do not decrement it.

So the line should read: work_remaining starts at type.build_work_ticks().

One AC was also deferred from #88 to here, because it needs a task type to assert against: a BuildingType authored at N days yields the matching work_remaining on the ConstructionTask it produces. Worth adding to this issue's test list. The deferral is recorded in test/unit/test_building_type.gd's docstring.

Note also that colony_rocket.tres has build_days = 0.0 deliberately — the Colony Centre lands already built. Whatever creates construction tasks should decide what a zero means: no task at all, or a task that completes on its first work tick.

**AC correction, from #88 (PR #107).** This issue's second AC reads: > `work_remaining` starts at `type.build_time` ticks All three parts of that are now stale: - The field is **`build_days`**, not `build_time`. - It is **days**, not ticks — convert with `type.build_work_ticks()`, which is the single conversion site. Do not call `GameCalendar.days_to_ticks()` here directly, or the conversion exists twice. - The unit is **pawn-days**, i.e. labour, not elapsed time. A 10 pawn-day mine is 10 days for one pawn and 3.3 for three. `work_remaining` counts work actually performed, so walking to the site and hauling do not decrement it. So the line should read: *`work_remaining` starts at `type.build_work_ticks()`*. One AC was also deferred from #88 to here, because it needs a task type to assert against: **a `BuildingType` authored at N days yields the matching `work_remaining` on the `ConstructionTask` it produces.** Worth adding to this issue's test list. The deferral is recorded in `test/unit/test_building_type.gd`'s docstring. Note also that `colony_rocket.tres` has `build_days = 0.0` deliberately — the Colony Centre lands already built. Whatever creates construction tasks should decide what a zero means: no task at all, or a task that completes on its first work tick.

liamjd referenced this issue from a commit

2026-09-18 13:11:30 +01:00

ConstructionTask: placing a building enqueues construction

liamjd referenced this issue from a pull request that will close it,

2026-09-18 13:11:51 +01:00

ConstructionTask: placing a building enqueues construction #109

liamjd closed this issue

2026-09-18 13:22:22 +01:00

liamjd referenced this issue

2026-09-18 13:39:49 +01:00

Pawn needs to know which task it is walking to #112

liamjd referenced this issue