HELP! Why won't InputLockManager lock out the "X" key?

[Dunbaratu]

In the kOS mod, we respond to keypresses when our terminal window is focused. But one frustrating thing is that even when the window is focused, KSP itself still gets first dibs on the 'X' key and it uses it to kill the throttle before allowing the keypress to pass through to our mod. So while someone *can* type a command like "SET X TO 1." in the terminal and it works, doing so will have the side effect of killing the throttle when they get to the "X" key. Currently this only seems to happen with the "X" key and no others. If the user types "SET WASD TO 1.", then the "WASD" part has no effect on the piloting, as we'd prefer, and the spaces don't cause staging, and so on. Only the "X" key has this problem because it seems KSP is doing something different with it than it does with all the other piloting keys.

Until now this has been just slightly annoying. But there's rumors that soon the "Z" key will go full throttle in stock, and if that's true then this same behavior would really screw us up big time there if SQUAD implements the "Z" key the same way they've implemented the "X" key (which seems likely). So we need to find a solution before 0.25 is out.

Any ideas?

Edited October 5, 2014 by Steven Mading
change title to reflect newer information.

[ratchet freak]

unbind the key temporarily?

[Diazo]

I would look at the inputlockmanager class, you can lock parts of the game so they don't accept inputs while locked.

There is a list of which parts can be locked on the forum somethwere but my google skills are failing me at the moment.

D.

edit: Found it here.

So something like:

//on textbox gain focus:
InputLockManager.SetControlLock(ControlTypes.THROTTLE, "YourControlLock");

//on textbox lose focus:
InputLockManager.RemoveControlLock("YourControlLock");

I used to use the unbind key temporarily method in AGX, but switched to inputlock manager because it is so much simpler and have had no problems with it.

Edited October 4, 2014 by Diazo

[Dunbaratu]

Okay, now I've used the ALT-F12 debug menu to view the lock being created by the terminal.

This is the code that does the lock - it's just trying to lock ALL things:

InputLockManager.SetControlLock("kOSTerminal");

And yet, it still doesn't lock the "X" key out. "X" still gets seen by KSP and kills the throttle before KOS ever sees it. No other keys have this problem.

Here's the screenshot showing the input locks - note all the bits are set to 1:

And it still killed the throttle when I typed "X".

If "Z" gets implemented the same way "X" was, then this will ruin our mod when 0.25 comes out. Help! I've seem other mods that allow you to type "X" and it doesn't kill throttle. How?? is there no way to do it unless you use a Unity GUI textbox? That's going to be a problem since we're trying to manipulate the terminal manually and can't let Unity's textbox do the work.

[Dunbaratu]

Well, the Game settings keybindings kludge does seem to work, I'm still trying to figure out why I have to resort to it. It's an ugly hack and it seems like it's a band-aid around something in the API that feels a bit broken.

Specifically, the game settings hack is to change the user's key bindings from the Settings screen temporarily, then put it back to whatever it was later.

Like so:

When the terminal window gains focus:

    rememberThrottleCutoffKey = GameSettings.THROTTLE_CUTOFF;
    GameSettings.THROTTLE_CUTOFF = new KeyBinding(KeyCode.None);

When the terminal window loses focus:

    if (rememberThrottleCutoffKey != null)
        GameSettings.THROTTLE_CUTOFF = rememberThrottleCutoffKey;

This hack works. It just seems like it shouldn't be necessary. All the *other* keys get trapped properly by normal Unity GUI widgetry, just not "X".

[Diazo]

InputLockManager.SetControlLock("kOSTerminal");

does lock everything, including the Throttle. To lock only a part of the interface you need the 2 variable method:

InputLockManager.SetControlLock(ControlTypes.THROTTLE, "kOSTerminalThrottle");

will lock out the throttle.

Which does not explain the X key still being registered while your input lock is in effect, that does feel like an oversight to me.

Well, that's all I have for you on InputManager.

On the keybinding thing, ensure that the losing focus code runs when exiting a non-standard way. (ESC key to bring up menu, leaving Flight scene with focus on the text box, etc.) If the player can make it to the settings screen somehow without the unfocus code running, the key will be unbound in the settings file and the player will have to reassign it. I don't know if the in-flight settings screen is sufficient or you have to go to the Main Menu settings screen to run into this but it was my biggest headache when I was using that method.

I don't know if this will actually be an issue for you, I was using it a lot more then you are (my rebind Key was running in the OnDisable method), but it is something to watch for.

D.

Edited October 5, 2014 by Diazo

[Dunbaratu]

I strongly suspect that the reason the "X" key is handled differently is in some way related to the fact that you can use it from the Map View even when the navball isn't showing. (Normally to use ship controls from the map view, you need to enable the navball tab on the map first. But the "X" key will kill throttle from anywhere, anywhen, as an emergency measure.) To do that SQUAD had to keep the "X" key out of the ControlTypes.THROTTLE set of keys, but then they appear to have forgotten to include some other control flag somewhere that does include it. It seems to be utterly outside of any of the ControlType bitflags.