the transporters should only fill the fleet office up to a certain amount, it should not be infinite but ensure that the tax will always be paid if resources are available #223

Closed
opened 2026-09-06 08:12:32 +00:00 by metaheavens · 1 comment
Owner
No description provided.
Author
Owner

Implemented in commit fe3ae97 on main. Full suite: 167/167 passed.

What was wrong
An office declared a flat buffer - 60 ore, 30 gas, 30 energy - whatever sat in its berth. Two faults, and the ticket names both:

  • Not bounded to anything meaningful. An office keeping an interceptor had transporters haul it gas and energy it can never spend, sitting on cargo the rest of the base wanted.
  • Nothing tied the buffer to the charge. Since #220 the charge depends on the berth's occupant AND on how far down the fleet that berth sits - neither of which a static definition can know.

What it does now
It asks for exactly what its own berth is charged, four charge intervals deep. Enough that the tax is payable whenever the bank has anything - a transporter round trip fits comfortably inside four intervals - and no more, so an office cannot become a hoard. This uses the idiom already in the codebase for outposts and workshops, which compute world-dependent demand the same way rather than declaring it.

An office whose berth is empty asks for nothing dynamic. A small floor stays in the definition (10 ore, 6 gas, 6 energy) deliberately: without it a newly crewed berth would start from zero and could starve before its first delivery landed.

Verification
New test_fleet_office_stock.gd: an office asks for at least its own charges rather than a flat figure; asks for far less of a resource its berth never spends; stops asking once stocked, and does not ask again when over-stocked; and a deeper berth - dearer under #220 - asks for more ore and for energy where an interceptor berth asks for neither.

One correction worth recording: I first asserted the request equals exactly four charges, which failed - an interceptor's charge is 1 ore, so four of them come to less than the floor, and the floor correctly wins. The assertion now checks the request covers four charges, with the scaling proven at the deeper berth where the dynamic term dominates.

Implemented in commit `fe3ae97` on `main`. Full suite: **167/167 passed**. **What was wrong** An office declared a flat buffer - 60 ore, 30 gas, 30 energy - whatever sat in its berth. Two faults, and the ticket names both: - Not bounded to anything meaningful. An office keeping an interceptor had transporters haul it gas and energy it can never spend, sitting on cargo the rest of the base wanted. - Nothing tied the buffer to the charge. Since #220 the charge depends on the berth's occupant AND on how far down the fleet that berth sits - neither of which a static definition can know. **What it does now** It asks for exactly what its own berth is charged, four charge intervals deep. Enough that the tax is payable whenever the bank has anything - a transporter round trip fits comfortably inside four intervals - and no more, so an office cannot become a hoard. This uses the idiom already in the codebase for outposts and workshops, which compute world-dependent demand the same way rather than declaring it. An office whose berth is empty asks for nothing dynamic. A small floor stays in the definition (10 ore, 6 gas, 6 energy) deliberately: without it a newly crewed berth would start from zero and could starve before its first delivery landed. **Verification** New `test_fleet_office_stock.gd`: an office asks for at least its own charges rather than a flat figure; asks for far less of a resource its berth never spends; stops asking once stocked, and does not ask again when over-stocked; and a deeper berth - dearer under #220 - asks for more ore and for energy where an interceptor berth asks for neither. One correction worth recording: I first asserted the request equals exactly four charges, which failed - an interceptor's charge is 1 ore, so four of them come to less than the floor, and the floor correctly wins. The assertion now checks the request covers four charges, with the scaling proven at the deeper berth where the dynamic term dominates.
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#223
No description provided.