Stage, RCS, SAS and Action Button/Lock Stuck On

[JessieArr]

Hello!

I have encountered an issue while using Remote Tech in which I am unable to launch unmanned vehicles. The stage lock light is stuck on and won't disengage, despite the fact that I have a connection, enough energy to power my probe core, and fuel available. Pressing alt + L also does nothing, and time acceleration is at 1x.

Upon opening the debug menu with alt + F12, I saw the following locks in my Input Lock stack:
RTLockStaging
RTLockSAS
RTLockRCS
RTLockActions

Screenshot below:

Screenshot (note that I said in the image caption that it fixed my problem. It removed the locks the first time I did it, but after reloading and trying it again, the locks no longer get removed by clicking the Clear Locks button.)

Leaving the launch pad and returning to the Space Center while in this state seems to leave the locks in the Input Lock stack:

Screenshot

I believe the issue may be caused by line 109 in RTCore.cs - if vs is non-null, but vs.FlightComputer is null, or vs.FlightComputer.InputAllowed is false, then the ReleaseLocksmethod never gets called.

Sadly I'm not quite sure what action I took ingame that may have triggered this scenario, but I have a feeling that something I did caused my game data to get into a configuration such that the Update method in RTCore.cs is not releasing locks properly. I was able to use probes normally for about a dozen unmanned missions before this began happening. Reinstalling Remote Tech did not help.

I cancelled all my contracts and aborted all my missions except for the one on the launchpad to see if that would help, but still no luck.

Please let me know if there is anything more I can do to help.

PS - Thanks for maintaining the mod! Bugs like this can be a bummer, but Remote Tech is still one of my favorite KSP mods! =D

[JessieArr]

I'm debugging this locally and it appears that my first guess was wrong, each time through the Update method, it is hitting this block of code:

else if (vs.FlightComputer != null && vs.FlightComputer.InputAllowed)
{
   foreach (KSPActionGroup ag in GetActivatedGroup())
   {
        vs.FlightComputer.Enqueue(ActionGroupCommand.WithGroup(ag));
   }
}

I'll continue debugging to see if I can get more info.

[JessieArr]

Adding a ReleaseLocks() call after the foreach loop seems to fix the issue, and still allows ships to become uncontrollable if they lose connection. But I have a feeling that isn't the right solution here. Sadly I don't know enough about the Remote Tech mod to guess what the "right" solution is.

Please let me know if there is anything more I can do to help diagnose this!

[jarrett]

I just updated from 1.7.0 to build-develop-554. 1.7.0 had this issue, but it appears to be resolved in build-develop-554.

[JessieArr]

That's great to know. Thanks for the information, I'll try develop-554 later today.

[JessieArr]

I just tested it, I was able to launch normally with develop-554, huzzah!

The Stage Lock Light is still stuck on, but at least my staging commands seem to be working again at least.

Thanks for the info, jarrett.

[lamont-granquist]

I'm still seeing these symptoms in 1.7.1 on KSP 1.1.3

[neitsa]

Howdy! Fix is planned for RT 2.0 major release.

[KSP-TaxiService]

(this bug is also reported in the issue #1)
Both stage-lock functionality and UI-indicator are independent. It seems the stage-lock (alt + L) keypress works in a remote-controlled probe regardless of the stage-lock indicator. So why disabling the indicator permanently if the stage-lock works?

Given that, I decide to exclude the stage-lock indicator from RemoteTech's InputLockManager controls so that a player can see whether the stage-lock of a RC probe is actually engaged or not. I also fix the other bug of RT locks not removed upon exiting of flight or tracking-station scene.

[KSP-TaxiService]

I found out why the current state of the stage-lock indicator is set up in a particular way. When the staging command triggered by pressing Space button is sent down the KSP's operation chain, it isn't possible to interpret and block this command if InputLockManager is not used to prevent the staging. KSP just directly invokes the staging function when the key is pressed (no ActionListener, no GameEvent or whatever). Therefore, the stage-lock indicator is permanently purple when InputLockManager is used to block for remote-control probes.

I am going to leave this issue open for current and future RT developers for records.

[YamoriYuki]

Two ideas:

1. Would it be possible to override the gui to show the green blinking icon?
2. Do we provide a replacement functionality for the staging lock if we have to hijack the original one? Just in case someone actually wants to use it.

[KSP-TaxiService]

Yes, it is possible to replace KSP's stock KSP.UI.Screens.StageManager class with our own subclass (just like I did with CommNet subclassing in RT 2.0 redevelopment) to new override the ActivateNextStage() method. This method is called by FlightInputHandler.Update() class that listens to all players' key presses

However, I am not sure if this change is trivial or significant. Third-party mods could subclass and replace the StageManager class, leading to a potential class conflict among mods

[YamoriYuki]

Just wanted to have those ideas recorded someplace relevant for the future, in case someone decides it's too anoying.

[ryanwhite1]

OS: Windows 10 Home x64
KSP: 1.7.3
RT: v1.9.2
Problem: As described in OP, input locks on craft. Unfortunately don't have the log file from the time that the controls locked up, but it happened somewhere during the flight (perhaps during an SOI or scene change, as I successfully launched the craft without issue).

Logs:
KSP.log

output_log.txt

Installed Mods
Installed Mods.txt

Persistent save (optional):
persistent.txt