by default transporter and reparator fleet are not built #216

Closed
opened 2026-09-05 08:49:32 +00:00 by metaheavens · 1 comment
Owner

In the past I asked for the transporter to be available out of the box with their building. I changed my mind. No transporter or reparator should be available in the different building when they are crafted, they should be built by the player in the ship crafter building. In the two related building, menu should let the player assign how many they want to be there. if available the ships automatically moves from the mothership to the assigned buliding.
Both of these vessel types have a limited life span in term of number of travels/reparation. Their status/health should be visible in the respective buliding. this forces the player to keep building some from time to time

In the past I asked for the transporter to be available out of the box with their building. I changed my mind. No transporter or reparator should be available in the different building when they are crafted, they should be built by the player in the ship crafter building. In the two related building, menu should let the player assign how many they want to be there. if available the ships automatically moves from the mothership to the assigned buliding. Both of these vessel types have a limited life span in term of number of travels/reparation. Their status/health should be visible in the respective buliding. this forces the player to keep building some from time to time
Author
Owner

Implemented in commit 265e121 on main. Full suite: 164/164 passed.

What changed
Transport hubs and spacial workshops no longer conjure their crews. _sync_hub_transporters() and _sync_workshop_drones() are gone; a new structure stands empty.

  • Built by the player. Transporters and repair drones are orderable at a ship crafter, with prices and build times. That needed a support_craftable flag separate from fleet_eligible - "the crafter can make it" and "it can take a berth in the fleet" stopped being the same question - and two new rows in the craft menu, appended after the fleet hulls so no existing row moved.
  • Assigned per building. Both structures gained one action, opening a Station menu: +/- for how many to keep here, what is present against what was ordered, and the room available. The order is clamped to the room. A hub gets ONLY this action - its routes stay automatic, and two existing tests assert it offers nothing to hand-carry.
  • They fly themselves out. A structure short of crew takes a vessel from the mothership hangar and sends it, down the same delivery path a finished crafter order already uses. One in the air is counted, so a hub does not order a second hull for the same berth. If the structure is levelled or the order cancelled mid-flight, the vessel lands in the hangar rather than being destroyed - the rule outposts already follow.
  • They wear out. A transporter has 20 runs in it, a drone 12 repairs. Both are spent when the vessel gets HOME, not when it sets off: counting at dispatch would retire one with its cargo still in the air, or a building half repaired behind it. A spent vessel is gone rather than returned to the hangar, so the structure is short again and the player has to build more.
  • Condition is visible. The Station menu draws a bar per vessel showing what it has left, worst first - the number that decides whether another needs building.

A gap worth naming
Nothing gates these behind research, so a hub built before any ship crafter exists cannot be crewed at all. That matches the ticket as written and the crafter is the tree's first unlock, so I do not think it is a trap in practice - but if you would rather a hub arrived with one starter transporter, say so and it is a one-line change.

Verification

  • test_transporter_supply.gd rewritten end to end for the new model: a new hub stands empty, the crafter accepts a transporter order (it used to refuse one), an assigned hub pulls one from the hangar and flies it out, that transporter supplies a queued order with ore conserved, a completed run wears it down, and its last run uses it up.
  • New test_workshop_staffing.gd does the same for drones - their wear path is its own code, not the transporter's.
  • New tests/_staff.gd puts a crew straight at its post for the dozen tests that are about what a crew DOES rather than how it got there.
  • Two failures were real rather than churn: I gave the hub a transfer action it never had (its routes are automatic - that is the point of it), and the workshop doctrine's meaning changed from "provisions a drone" to "buys a berth". I first wrote that second assertion badly, reading capacity after the unlock and comparing it to itself, and rewrote it to capture the value beforehand.
  • Full suite green.
Implemented in commit `265e121` on `main`. Full suite: **164/164 passed**. **What changed** Transport hubs and spacial workshops no longer conjure their crews. `_sync_hub_transporters()` and `_sync_workshop_drones()` are gone; a new structure stands empty. - **Built by the player.** Transporters and repair drones are orderable at a ship crafter, with prices and build times. That needed a `support_craftable` flag separate from `fleet_eligible` - "the crafter can make it" and "it can take a berth in the fleet" stopped being the same question - and two new rows in the craft menu, appended after the fleet hulls so no existing row moved. - **Assigned per building.** Both structures gained one action, opening a Station menu: `+`/`-` for how many to keep here, what is present against what was ordered, and the room available. The order is clamped to the room. A hub gets ONLY this action - its routes stay automatic, and two existing tests assert it offers nothing to hand-carry. - **They fly themselves out.** A structure short of crew takes a vessel from the mothership hangar and sends it, down the same delivery path a finished crafter order already uses. One in the air is counted, so a hub does not order a second hull for the same berth. If the structure is levelled or the order cancelled mid-flight, the vessel lands in the hangar rather than being destroyed - the rule outposts already follow. - **They wear out.** A transporter has 20 runs in it, a drone 12 repairs. Both are spent when the vessel gets HOME, not when it sets off: counting at dispatch would retire one with its cargo still in the air, or a building half repaired behind it. A spent vessel is gone rather than returned to the hangar, so the structure is short again and the player has to build more. - **Condition is visible.** The Station menu draws a bar per vessel showing what it has left, worst first - the number that decides whether another needs building. **A gap worth naming** Nothing gates these behind research, so a hub built before any ship crafter exists cannot be crewed at all. That matches the ticket as written and the crafter is the tree's first unlock, so I do not think it is a trap in practice - but if you would rather a hub arrived with one starter transporter, say so and it is a one-line change. **Verification** - `test_transporter_supply.gd` rewritten end to end for the new model: a new hub stands empty, the crafter accepts a transporter order (it used to refuse one), an assigned hub pulls one from the hangar and flies it out, that transporter supplies a queued order with ore conserved, a completed run wears it down, and its last run uses it up. - New `test_workshop_staffing.gd` does the same for drones - their wear path is its own code, not the transporter's. - New `tests/_staff.gd` puts a crew straight at its post for the dozen tests that are about what a crew DOES rather than how it got there. - Two failures were real rather than churn: I gave the hub a `transfer` action it never had (its routes are automatic - that is the point of it), and the workshop doctrine's meaning changed from "provisions a drone" to "buys a berth". I first wrote that second assertion badly, reading capacity after the unlock and comparing it to itself, and rewrote it to capture the value beforehand. - Full suite green.
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#216
No description provided.