Loading a save fell through to the brand-new-game branch in
PlanetAtmosphereController, which spawns STARTING_SHIP_COUNT interceptors at
the world origin. So resuming stranded the player in empty space with the
wrong ships while their base sat wherever they had left it - thousands of
units away on a charted map.
fleet_position was in the save all along, but nothing ever read it: only
Fleet writes it, as a mirror for payment-range checks.
A resumed run now spawns at get_mothership_position(). That is already the
canonical home - BuildController._check_fleet_wipe rebuilds a wiped fleet
there - so this is the existing answer to "where does the fleet belong",
not a new one. It falls back to the position the save was written at, and
only then to the origin, because a run can have no mothership standing.
resumed_from_save is a one-shot handoff like has_return_position, and is
deliberately NOT saved: it describes this launch, not the run.
Verified by reverting the branch: "resumed at (0.0, -48.0), but the
mothership is at (7400.0, -3100.0)".
One note for whoever writes the next fleet test: asserting a three-ship crew
proves nothing without capacity. Since #219 the fleet holds BASE_FLEET_SIZE
(1) plus one berth per supplied fleet office, so spawn_ships clamps to 1 and
the assertion passes against the wrong number. Case A gives the save two
offices and checks max_fleet_size() first.
176/176 at JOBS=3.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019AJMdB7iuHuLFZM1aBu3GD