Fix the auto-pilot breaking after revert to launch#958
Merged
Conversation
AutoPilot cached its controller instead of resolving it live by vessel id, so a client that kept the object across a revert was left driving a controller orphaned from the registry the reload recreates — it read as engaged but no longer flew the vessel until a game restart. Resolve the controller live on each access, and tear down per-vessel pilot state on vessel destruction.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The auto-pilot stopped working after a "Revert to Launch": with it engaged, reverting left it unable to drive the vessel, and it would not re-engage (shown greyed out) when the script was re-run, until the game was restarted.
Root cause.
AutoPilotcached itsAttitudeControllerat construction — the only piece of its state not resolved live by vessel id (everything else goes throughInternalVessel). The controllers live in a static per-vessel registry that is recreated when the flight scene reloads. A client that keeps its auto-pilot object across the revert — the usual pattern, set once at the top of a script — keeps reusing the same server-side object, now pointing at a controller orphaned from the recreated registry:Engagedis set on the orphan, but the per-tick pilot loop consults the live registry and never drives the vessel. Only restarting the game, which drops the connection and its cached objects, recovered it.Fix. Resolve the controller live from the registry on each access, like
InternalVessel, so an auto-pilot object re-binds to the current controller after a reload. Also tear down per-vessel pilot state ononVesselDestroy— detach the fly-by-wire callback, revoke any RemoteTech sanctioned pilot, and drop the vessel's registry entries — instead of relying only on the wholesale clear at scene teardown, which left delegates bound to dead vessels.Testing. Adds
TestAutoPilotRevertToLaunch: it engages the auto-pilot, reverts to launch, and reuses the same auto-pilot object to confirm the pilot loop drives the recreated vessel. A reverted craft sits on the launch pad and cannot be slewed to a target, so the test relies on a driven auto-pilot forcing the SAS action group off every tick. Verified failing before the fix and passing after, with the existing auto-pilot tests still passing.