Camera switches to "vessel locked" mode when focusing the terminal window when in map-mode

[ozin370]

Pretty odd bug. I only tested this during atmospheric flight.

To replicate, simply enter mapmode, have the vessel perform some sort of rotation (leaving sas off for example) while focusing a kos terminal window. It doesn't need to be running any scripts.

[hvacengi]

This is a long standing issue that I can't seem to figure out. It used to be a bug with all windows. If you go back a few versions KSPedia had the same issue. But they somehow fixed it, and I haven't figured out how. I believe that the same issue at least used to happen if the game window was out of focus (I found out by recording long missions while doing other things on the computer at the same time). Definitely a bug, just one I don't know how to fix.

[Dunbaratu]

This old bug has bothered me more and more lately so I decided to start looking at it again and experiment.

I found the exact set of circumstances that trigger the bug in KSP!!
It's clearly a KSP bug given what I'm about to describe, but now I know the consistent cause, or at least I know the steps that cause it now so we might be able to work around it.

To get the bug to happen you need the exact input lock bitmask the kOS Terminal happens to use,

If you use ControlTypes.All, which is the following mask, the map rotation bug does not happen:

0000111111111111111111111111111111111111111111111111111111111111

But when you add in the fact that we want to make an exception for the ControlTypes.TARGETING bit, as shown below, then the map rotation bug occurs:

0000111101111111111111111111111111111111111111111111111111111111
        ^
        |
  This is the TARGETING bit.

(This is the mask that we use in TermWindow.Lock().)

It is explicitly ControlTypes.TARGETING that causes the bug to manifest. I have no clue why as this seems like there is no logical reason why, but there you have it - zero that bit from the mask and the view spins. Leave that bit as a 1 and the view won't spin.

Note, I googled and found that other modders who had this problem and fixed it said that the fix was to use ControlTypes.ALLBUTCAMERAS, which turns off a few other flags too (TARGETING among them). But that wasn't acceptable to me because using that means the cursor-arrow keys will pass through to make the game rotate the camera when you edit the command line in the terminal. So I looked at which bits ALLBUTCAMERAS was zeroing out and tried them one at a time until I found the culprit, and it just so happens to be the one we need to use - the TARGETING one.

I don't yet know the fix, but I imagine it's going to have to be this: We leave TARGETING locked out most of the time, using the simple ControlType.All flag that just suppresses everything. Then when we detect the script is trying to SET TARGET TO...., then we temporarily remove the input focus from whichever kOSTerminal has the focus (if any), set the target, then put the focus back on that terminal after the target is set.

[Dunbaratu]

The ugly part about the fix of "temporarily de-focus the terminal, do the target change, then re-focus the terminal" is that it might not be the current CPU's terminal that is focused. It could be the terminal from a second CPU on the vessel that is focused. So simply affecting the Shared.Window of the CPU executing the SET TARGET TO ... code isn't enough. We have to search for which kOS window happens to be the focused one right now.

[Dunbaratu]

Actually only one kOS window will have the input lock set at the moment, so I can just ask the InputLockManager to find that lock we set, regardless of which window set it.