Transport Hub building #18
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?
Part 5 of #12. Depends on the building-stock ticket.
A new placeable building that hosts transport ships. This ticket is only the building itself - placement, cost, art, info popup, map marker, and being gated behind research like the others.
Scope
GameState, buildable viaBuildControllerwith its own info popup (BUILDING_INFO).Building.gdfollowing the draw-once architecture from #10: static geometry drawn ONCE in_draw(), anything that moves is aNeonPiecechild animated through node properties. Do NOT animate with per-framequeue_redraw().Deliberately not here: transporter vessels and any actual hauling.
Acceptance
Done in
823828f. The building only - the vessels that do the hauling are #19.Placeable, costed at 30, gated behind a new Freight Handling research node hanging off Logistics, with its own info popup, build-menu glyph and map marker (per #11).
Drawn as an octagonal dock ring with berth arms and a squared-off freight core - deliberately radial-but-flat, so it does not read as a small mothership, which is the only structure with swept arms. Its stationed transports are
NeonPiecechildren of one rotating holder, per #10: the geometry is rasterised once and only the holder's rotation changes, so the traffic costs no redraws at all. The test confirmsdraw_count == 1after two seconds of animation AND that the transports actually moved, so a frozen hub cannot pass it.A silent failure worth recording
Building._draw()'smatchhas a catch-all that renders anything unrecognised as a ship crafter. So a missing case is not an error - it draws something plausible and almost right.That is exactly what happened: one of my
_ready()patches silently did not apply (wrong indentation, so the string replace matched nothing), and the hub was being built through the crafter branch. The test caught it because it checks for the hub's OWN_hub_trafficholder rather than just "a building appeared". Anything looser would have passed.The build menu needed rebuilding, and the render caught that too
A fifth entry did not fit. The old row occupied 332px against a 372px pitch, and three of those run off the bottom of a 1280px screen.
My first attempt just tightened the pitch to 275 - which is less than the row height, so every price overlapped the buttons in the row below. Nothing in the test suite can see that. The render made it obvious immediately. Rows are now genuinely shorter (128px buttons, 40px price digits) at a 290px pitch, ending at y=1176, and all five buildings show cleanly.
tests/_build_menu_preview.tscnis checked in so the menu can be re-checked whenever it changes again.Full suite: 45/45.