dedicated menu for resources movement #24
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?
moving resources between the fleet and a building should have a dedicated action button (not inside the specific menu, like ship building or tech tree). this button should open a dedicated menu to move resources between fleet and the current building. mothership should not automatically fetch the fleet resources when touching it. when inside a building, they should all share the same top level bar of available resources, this would unify ui between ship crafter and the skill tree a bit
Implemented.
Dedicated action button. A new transfer button sits in the UI action column, visible whenever the fleet is on any building. It sits alongside the action button rather than being another thing that button turns into — crafting and moving ore are independent choices at the same structure. It opens a dedicated
TransferMenu: both directions, two amounts each (a 25-ore batch, or All).The mothership is no longer a special case.
GameState.building_holdings()returns the bank for a mothership and per-building stock for everything else, so one panel serves every structure — unloading at a mothership banks the ore, loading there draws on it. Newtransfer_to_building/transfer_to_fleetprimitives cap by what is actually at each end, so there is no overdraft in either direction.Mothership auto-fetch removed.
BuildingField._processis gone entirely; arriving at the mothership no longer banks the hold. That edge-triggered move existed to stop ore you had just withdrawn being instantly re-banked. With transfers explicit and bidirectional it was the odd case out, and it silently overrode a player who had loaded the hold in order to carry ore somewhere else.Shared resource bar. New
ResourceBar.gd— BANK / HOLD / HERE in the game's own hexagon-and-segment style — now heads the craft, research, lab and transfer menus. The crafter used to spell those figures into a run-on status string and the research screen printed a bank total inside a button caption; both are gone, along withLoadOreButton(research) andStoreOreButton(crafter).Craft menu reflowed. Removing "Store ore here" freed a button-sized block at the bottom, so the stack moved down into it — without that, the new header squeezed the status line into the shield button. Menu titles were also narrowed so they stop running under the close button; that overlap predated this change but moving the titles up to make room for the bar made it worse.
Tests: 53/53 passing. New
test_resource_transfer.gdcovers the button appearing and binding to the right building, both directions at an ordinary building, the mothership-is-the-bank case, a real tap through the input path, empty-end messages, the bar following the panel, and ore conservation.test_fleet_cargoandtest_manual_supply_routeasserted the old auto-banking, so they now check both halves: parking changes nothing, the explicit transfer moves everything.test_crafter_feedbacklost its store-ore stages.One loose end, not done here:
deliver_cargo,withdraw_to_fleetandunload_into_buildingare now called only from tests, andcargo_deliveredhas no listeners (which predates this change). Folding them into the new primitives means touching two passing tests that are not about this issue, so I left them. Worth its own issue if wanted.Loose end closed in
b6427b0.Removed
withdraw_to_fleet,unload_into_building,deliver_cargoand thecargo_deliveredsignal. Each function was a special case oftransfer_to_building/transfer_to_fleet, none had a caller left outside tests, and the signal had no listeners at all (declared once, emitted twice, connected nowhere).It was not only tidying.
unload_into_buildingrouted throughdeposit_to_building, which does not special-case the mothership - it writesb.stock, whilebuilding_holdings()returnsrocksfor a mothership and ignoresstockentirely. Sounload_into_building(mothership_id)would have parked ore in a field nothing reads: it would have vanished from the player's view with no error. Nothing called it that way, but it is a plausibly-named function sitting there for someone to reach for later.transfer_to_buildinghandles the mothership correctly, which is the whole point of the #24 primitives.The cost estimate in the note above was wrong, in the useful direction. I expected folding this in to be awkward for
test_cargo_readout, which places no buildings and is a pure display test. It is not awkward: the transfer primitives work offGameStaterecords rather than spawned nodes, so oneadd_building()in setup is enough - noBuildingField, no waiting for a node, and it stays a display test.test_manual_supply_routealready had a mothership, so its three call sites moved across mechanically, and its overdraft check still holds becausetransfer_to_fleetcaps bybuilding_holdings(), which is the bank at a mothership.CARGO_LOAD_BATCHstays - the transfer menu's batch buttons use it. Only its role aswithdraw_to_fleet's default argument is gone.Both touched tests still assert what they claim:
Full suite: 53/53.
Implemented and verified in commit
8255246(Add timed craft queue and hangar).The dedicated resource-transfer flow remains covered by
test_resource_transfer.gd, which passes from the tracked checkout. I also fixed the test runner so memory pressure and initialization errors report clearly instead of appearing to hang.Closing #24 as complete.