Gamepad controls ship after EVA

[DanielKinsman]

After mun landing, i tried to control my EVA kerbal with the gamepad, but instead my lander took off and stranded me there. It was hilarious.

Found the same issue on the original repo but I guess it is being maintained here now? Might fix this myself and submit a PR if I get the time.

[linuxgurugamer]

Yes, this is the active one. If you do fix, I'd appreciate it, I won't have time to get to this for a while
Would also like to see a video of this happening :-)

[voidbeast]

I have the same issue as well. The button commands for things like lights and planting flag and jump and such work properly (the ones specifically labelled as EVA commands when assigning keybinds) but none of the movement axes actually control the EVA kerbal. If I move far enough away, it seems to stop controlling the ship, but still doesn't control the Kerbal no matter what I do. Also as an aside, I find this very bizarre, since I didn't even know it was possible to send button commands to an inactive vessel! If this can be properly tracked down, I could think of some very interesting uses that could turn this bug into a feature, if it is something that can actually be triggered on purpose and used from longer distances, of course...

Anyway, is there any sort of info that might help track this down? I didn't see anything terribly useful in output_log but you might be able to find something. And this problem happened just now, so the end of the log is the relevant section; there will be a scene change to Main Menu, and Settings, and right before that is the game I had loaded when this problem was happening--I was messing with AFBW binding trying to get it to do something different but nothing worked. Reloading the game, trying a different vessel, none of that seems to matter, gamepad always controls the ship (and ONLY the ship, Kerbal doesn't move at all) after going EVA.
output_log.zip

[soltanmm]

This line and the surrounding lines smell; specifically there appears to be a contradiction of intent. Why is the active vessel having its fly-by-wire control listener removed, when it is the m_LastChangedActiveVessel (which gets assigned to the active vessel on a later line, suggesting that they're different vessels at that point in the code) that's getting checked for relevant state? Perhaps every use of FlightGlobals.ActiveVessel between here and here that removes fly-by-wire listeners/disables-SAS-or-whatever should be m_LastChangedActiveVessel.

Alternatively, the choice of events being handled and the associated unwritten assumptions are maybe wonky. Instead of onVesselChange and maintaining m_LastChangedActiveVessel based on what I can only assume is undocumented behavior (specifically I don't see any documentation that the active vessel on the event firing is the changed-to vessel rather than the changed-from vessel), maybe a more explicit pair of events would be onVesselSwitching and onVesselSwitchingToUnloaded, and maybe then avoiding the use of FlightGlobals in favor of the event handler's arguments.

I'm not a C# person and have zero-knowledge of the toolchain or KSP modding (e.g. I don't know who is responsible for stepping this possibly-relevant-coroutine past its yield statement and when), so please take this cursory investigation with a grain of salt.

[kurtu5]

My workaround is just an immersive EVA checklist. Item #1, disable AFBW inputs. Item #2, don't die.