by default transporter and reparator fleet are not built #216
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
Implemented in commit
265e121onmain. 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.support_craftableflag separate fromfleet_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.+/-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.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.gdrewritten 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.test_workshop_staffing.gddoes the same for drones - their wear path is its own code, not the transporter's.tests/_staff.gdputs a crew straight at its post for the dozen tests that are about what a crew DOES rather than how it got there.transferaction 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.