(v0.85,v0.8.4,all tested) Terminal input sent to KSP when used with KMP

[raad287]

Not directly kOS's problem, but still a bug to be noted.

Problem: Keyboard inputs are received in the kOS terminal when selected, and handled fine, but also continue on and are picked up by KSP. Problems immediately arise with things like the spacebar causing staging, movement keys,etc, making kOS unusable.

kOS Versions: -Release version on spaceport 0.8.4 -Commit compiled Oct 25, 2013 https://github.com/Nivekk/KOS/commit/35f5de5c8f44b2ef4829184f9599669351b103ec -(Edit) also had a few previously compiled dll's I tried, same problems with all tests.

KSP Versions -Stock .22 with KMP v0.1.0

[a1270]

KMP == KerbalMultiPlayer(https://github.com/TehGimp/KerbalMultiPlayer). As far as i can figure it's caused by clearing inputlocks set by kOS. Cliph has said intgration with RT2 is forthcoming so i won't dig any deeper. As for KMP i suggest you file a bug report with them as they are the ones clearing the lock.

[a1270]

I got that. I am messing with RT2 and was wondering about the issue myself. Figured you might like to know he's planning on adding support. </end of sidetrack>

[Nivekk]

Locking controls and preventing them from going further is definitely a long standing problem. Part of which the fact that KSP only gives me certain things I'm allowed to lock.

If anybody ever comes up with an idea on how to work around this, please do let me know

[raad287]

I think I found a solution!

Adding the following to the end of the Update() function in TermWindow.cs (//maintain lock) fixed the problem completely for me. It's just a simple check to see if it has a control lock when it's supposed to. I'm not sure how much overhead this causes, but there isn't any noticeable lag.

void Update()
        {
            if (Cpu == null || Cpu.Vessel == null || Cpu.Vessel.parts.Count == 0)
            {
                // Holding onto a vessel instance that no longer exists?
                Close();
            }

            if (!isOpen || !isLocked) return;

            cursorBlinkTime += Time.deltaTime;
            if (cursorBlinkTime > 1) cursorBlinkTime -= 1;

            // maintain lock
            if (!InputLockManager.PrintLockStack().Contains("kOSTerminal") && isLocked)
            {
                InputLockManager.SetControlLock("kOSTerminal");
            }
        }

I looked at the KMP side of the code, and the problem is KMP is calling InputLockManager.ClearControlLocks() every time a new flight is loaded, and every update cycle while labeled "in flight" which for kmp is any time your 40km away from KSC. I don't see a clear reason why it does this, and the obvious fix would seem to be for KMP to stop wiping all of the control locks.

I can try to do a proper pull on this if you want to deal with it in this way, but it's a quick change. I'll also work on it from the KMP side, it might be a quick fix there as well, but in the mean time, this change to kOS does seem to solve the problem.

Edit: After more testing, this does cause a noticeable fps drop. Checking every update cycle works but isn't the best way to handle it.

[raad287]

Moving the maintain lock code into ProcessKeyStrokes() immediately on keydown grabs the control lock back without the overhead. Seems to be working perfectly.

if (Event.current.type == EventType.KeyDown)
            {
                //////////////// maintain lock
                if (!InputLockManager.PrintLockStack().Contains("kOSTerminal") && isLocked)
                {
                           InputLockManager.SetControlLock("kOSTerminal");
                }
                ////////////////////

                if (Event.current.character != 0 && Event.current.character != 13 && Event.current.character != 10)

Edit: This does not prevent "Special Keys" (up,down,left,right) from passing to KSP, not sure why, it stops everything else.

[raad287]

To keep this up to date, the previous fix does not seem to take care of the lock functions in kOS. I have been having problems with lock steering. (IE not working). kOS needs to aggressively resume control lock somewhere, I just haven't found it yet. Again, this is not kOS's problem directly, but in the absence of any kind cleanup for input handling in KMP, which i'm also working on, it's a start in the right direction for sure.

This isn't related to any specific commit, but the commit I tested with as of this comment is https://github.com/Nivekk/KOS/commit/f87b56f0ec27019798ef2ef85451133dd84e137d

Are there no EventHandler's with unity engine? I do not know unity very well, but this seems like an extremely overlooked (full retard) problem, we are not talking about much here.

I've been trying to work both sides of the issue, but to be real, this is the way it goes. Github (kOS): Lol KMP! not our problem! Github (Kmp): Lol what is kOS?

Unrelated: kOS is awesome, kOS + KMP opens an entire realm of possibilities. KMP causes bugs, given, but considering the implications of KMP and my own love for kOS, it can be done, and I'd like to get kOS in full compatibility with KMP.