Transporter vessels: built at the crafter, stationed at a hub, supply buildings automatically #19

Closed
opened 2026-08-11 13:36:44 +00:00 by metaheavens · 1 comment
Owner

Part 6 of #12, and the heart of it. Depends on the Transport Hub and building-stock tickets.

From #12: "as soon as one of the building that crafts something requires resources, a ship goes out of the hub, fetch resources from the mothership and bring that to the needed building" and "transporters needs to be built in the ship crafter, they are then automatically moving to the nearest transport hub, waiting for order".

Scope

  • Transporter vessel built at the ship crafter, which then travels to the nearest hub and waits.
  • On demand: hub -> mothership -> requesting building -> back to hub.
  • Resources leave the bank when loaded and arrive in the building's stock on delivery, so the payout and the visible arrival are the same event. GameState's extractor hauler already works this way (progress drives both the drawn position and the payout, so they cannot drift apart) - worth following.

Acceptance

  • A queued order is fulfilled automatically end to end with no player input.
  • Resources are conserved across the whole route.
  • No unbounded node accumulation as transporters come and go.
Part 6 of #12, and the heart of it. Depends on the Transport Hub and building-stock tickets. From #12: "as soon as one of the building that crafts something requires resources, a ship goes out of the hub, fetch resources from the mothership and bring that to the needed building" and "transporters needs to be built in the ship crafter, they are then automatically moving to the nearest transport hub, waiting for order". **Scope** - Transporter vessel built at the ship crafter, which then travels to the nearest hub and waits. - On demand: hub -> mothership -> requesting building -> back to hub. - Resources leave the bank when loaded and arrive in the building's stock on delivery, so the payout and the visible arrival are the same event. `GameState`'s extractor hauler already works this way (`progress` drives both the drawn position and the payout, so they cannot drift apart) - worth following. **Acceptance** - A queued order is fulfilled automatically end to end with no player input. - Resources are conserved across the whole route. - No unbounded node accumulation as transporters come and go.
Author
Owner

Done in d41128b.

Transporters are built at the ship crafter, fly themselves to the nearest hub and wait. When a building is short of what its queue needs, the nearest idle transporter runs hub -> mothership -> building -> hub. Ore leaves the bank when it is loaded and lands in the building's stock on arrival, so what is drawn and what happens are the same event - the same rule the extractor hauler already follows.

Production orders are now typed (interceptor / transporter) rather than a bare count, since the crafter builds two different things. Only one transporter is dispatched per building at a time: without that, every idle vessel chases the same shortfall and they all arrive carrying ore nobody needs any more.

Test

tests/test_transporter_supply.gd runs an order from queued-and-unaffordable to fulfilled with no player input, and checks conservation on EVERY tick rather than at the end, so a leg that loads without debiting cannot be masked by a later correction.

That check taught me something: "the total never changes" is the wrong invariant, because building a vessel legitimately consumes ore. It now tracks consumption through the order_completed signal and asserts that nothing vanishes in transit. Three mutations caught: loading without debiting the bank, arriving without depositing, and spawning at the hub instead of flying from the crafter.

Play-testing fixes folded in

  • Storing ore into a building is now an explicit button press, not a side effect of opening the menu.
  • The mothership's load-ore label fell off the bottom of shorter screens. Two causes: the controls were positioned from the TOP of the screen (offset_top = 1246), and the label had no explicit font size so it inherited the theme's 78px and wrapped off the edge. Now bottom-anchored at 28px, checked at 720x960 and 720x1280.
  • The craft button looked live and did nothing - reported as possibly caused by this ticket. It was not. BASE_FLEET_SIZE is 5 and a new game starts with exactly 5 ships, so the fleet is at its cap from the first frame and every interceptor order was refused; the ore was being stored correctly all along. The button is now visibly disabled and says why. The balance itself is untouched, since that is a design call - but as it stands the ship crafter is inert on a fresh save until Wing Doctrine is researched.
Done in d41128b. Transporters are built at the ship crafter, fly themselves to the nearest hub and wait. When a building is short of what its queue needs, the nearest idle transporter runs hub -> mothership -> building -> hub. Ore leaves the bank when it is **loaded** and lands in the building's stock **on arrival**, so what is drawn and what happens are the same event - the same rule the extractor hauler already follows. Production orders are now typed (interceptor / transporter) rather than a bare count, since the crafter builds two different things. Only one transporter is dispatched per building at a time: without that, every idle vessel chases the same shortfall and they all arrive carrying ore nobody needs any more. ## Test `tests/test_transporter_supply.gd` runs an order from queued-and-unaffordable to fulfilled with **no player input**, and checks conservation on EVERY tick rather than at the end, so a leg that loads without debiting cannot be masked by a later correction. That check taught me something: "the total never changes" is the wrong invariant, because building a vessel legitimately consumes ore. It now tracks consumption through the `order_completed` signal and asserts that nothing vanishes *in transit*. Three mutations caught: loading without debiting the bank, arriving without depositing, and spawning at the hub instead of flying from the crafter. ## Play-testing fixes folded in - **Storing ore into a building is now an explicit button press**, not a side effect of opening the menu. - **The mothership's load-ore label fell off the bottom of shorter screens.** Two causes: the controls were positioned from the TOP of the screen (`offset_top = 1246`), and the label had no explicit font size so it inherited the theme's 78px and wrapped off the edge. Now bottom-anchored at 28px, checked at 720x960 and 720x1280. - **The craft button looked live and did nothing** - reported as possibly caused by this ticket. It was not. `BASE_FLEET_SIZE` is 5 and a new game starts with exactly 5 ships, so the fleet is at its cap from the first frame and every interceptor order was refused; the ore was being stored correctly all along. The button is now visibly disabled and says why. The balance itself is untouched, since that is a design call - but as it stands the ship crafter is inert on a fresh save until Wing Doctrine is researched.
metaheavens referenced this issue from a commit 2026-08-11 18:31:47 +00:00
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
metaheavens/spaceship#19
No description provided.