RT windows don't block keyboard input on Linux

[Starstrider42]

Any keystrokes typed into e.g. the flight computer window also get parsed by KSP for Linux (whatever you do, don't hit backspace). Appears to be common to 32- and 64-bit games, and does not require any third-party mods or special circumstances to reproduce. KSP logs show no exceptions or diagnostic messages.

See forum discussion starting at http://forum.kerbalspaceprogram.com/threads/83305?p=1451609#post1451609.

[Baughn]

One more point of data.

Whenever I press enter in a textbox in KSP--yours, or the stock ship naming box, doesn't even matter if there are any mods installed--I get a strange horizontal line that looks somewhat like an M-dash. That does include the delay textbox, though it keeps working even though the contents ends up being something like "20--" .

[Peppie84]

@Baughn can you please take a screenshot of these "strange horizontal lines"

[Baughn]

http://brage.info/ksp_hlines.png

[Peppie84]

hmm i can't see any relation between your error and RT.

[Starstrider42]

I think what's happening is that KSP and Unity have several GUI systems between them, and we're using one that's poorly supported. This is likely also the root cause of #49.

[Peppie84]

You are meaning 'EzGui'?

I think #49 can be fixed by a redesign of our window handling and switching to the RenderingManager.AddToPostDrawQueue(). If i open a new window with this method it would be disappear by using F2.

@Baughn Can you please try this dll.
https://www.dropbox.com/s/e2v8yjjl4segd6p/debug_plugin_for_baughn.zip?dl=0

Put this dll into your gamedata folder. This will open a small window on the main menue.

Click into the text box and write some text + your backspace.

[Baughn]

Result: Keypresses still get passed through to the underlying game. I got a stayputnik to roll off the launchpad by holding q.

[erendrake]

we are dealing with the same issue in kOS, its a bummer :P

backspace and the X/Z buttons are the biggest problems, the rest i am hoping users can deal with.

[Starstrider42]

I've asked on the forums if any other mods have found a solution: http://forum.kerbalspaceprogram.com/threads/83305?p=1454952#post1454952. If not, we may have to tag this one as "Won't Fix". 😦

[erendrake]

It looks like DarkMultiplayer's chat works correctly

[Starstrider42]

The latest dev build of MechJeb also seems to work, though if I understand the release notes correctly they do it by locking spacecraft input whenever a window is in focus (MuMech/MechJeb2@a4a4744). Sounds messy when combined with RT's comm-based input locking.

EDIT: To clarify, by "messy" I meant that there's a lot of room for bugs where e.g. a ship gets unlocked when it should be out of contact, or stays locked while in contact. I agree that if we could actually get things to work as advertised (unlocked if, and only if, both in contact and not using a window) that would be an adequate solution.

[Baughn]

I'd take that. Seriously, that'd be so much better than the way it works right now.

[ddproxy]

Lurker here,

What if the ship inputs were locked on key press when the window is in
focus? Little more complex but more of a middle ground solution.
On Oct 7, 2014 10:48 AM, "Svein Ove Aas" [email protected] wrote:

I'd take that. Seriously, that'd be so much better than the way it
works right now.

—
Reply to this email directly or view it on GitHub
#197 (comment)
.

[FloFri]

Just to bring this back up. I run the latest release on 0.9. Still a problem here. Bit it looks like kOS at least found a solution, because there are no problems anymore, when typing in their terminal.

[Peppie84]

@erendrake can you help here? 😊

[Peppie84]

a wait. I thought it's issue #228

@FloFri can you try with this dll: https://www.dropbox.com/s/f9fvhijzjf22lkx/RemoteTech_v1.6-alpha-alpha.zip?dl=0 (but not on your career saves ) ^^ and give me a feedback

[FloFri]

@Peppie23 The new dll fixes half of the problem. Modifier keys like shift and ctrl are now blocked while in the flight computer, but normal keys (for example m or x) still are not blocked.

[Peppie84]

@FloFri thanks for testing. I'll make a new version today.

[Peppie84]

@FloFri can you please use the same dll and try to keep your mouse over the window and tell me if this would work

[erendrake]

@Peppie23 this is a PITA. I was not involved with the fix for this bug but as you can see we ended up having to build a glue table to get everything mapped correctly. Moving the fix over from kOS should work for most of these jeys

[Peppie84]

https://www.dropbox.com/s/yr98097pa3xj3fd/RemoteTech_v1.6-alpha-alpha-2.zip?dl=1

ok i think i'm done with that issue. I insert a stackLock for ControlTypes.ALL_SHIP_CONTROLS if one remotetech input is focused.

btw: what is a PITA? ☺️

[erendrake]

Pain in the ass ☺

On Fri, Jan 9, 2015, 17:11 Dennis [email protected] wrote:

https://www.dropbox.com/s/yr98097pa3xj3fd/RemoteTech_v1.6-alpha-alpha-2.zip?dl=1

ok i think i'm done with that issue. I insert a stackLock for
ControlTypes.ALL_SHIP_CONTROLS if one remotetech input is focused.

btw: what is a PITA? [image: ☺️]

—
Reply to this email directly or view it on GitHub
#197 (comment)
.

[FloFri]

@Peppie23 have tested this latest Version. But problem still exists with some keys (for example y, z and m), even when the flight computer has the focus and the mouse is in the text field. But other keys (Shift, wasg) work now, when the flight computer has the focus.

[Peppie84]

ok this is my last try otherwise i'll give up.

I found a way to simulate this problem on windows, so maybe a good sign to fix that issue already. Adding a Lock for ALL_SHIP_CONTROLS will only lock the ship controls like w,a,s,d,shift etc.., good 👍 i also tried to use the ALL lock but no change to the Z or X key. This is why i also changed the OnFlyByWirePost to neutralize the FlightCtrlState if our input lock is active.

@FloFri btw thanks for helping to debug this issue. Here is my last update:
https://www.dropbox.com/s/i9all5lzlenlwvh/RemoteTech_v1.6_alpha-alpha-3.zip?dl=1

[Peppie84]

hmm ok it doesn't work. Neutralize the FlightCtrlState also cuts the engine every time you focus an input 😩

[pjf]

I'm hugely appreciating all the work being done here; I also play under Linux, and any improvement is a wonderful thing.

As an aside, one terrible work-around that I use under Linux is to manually pause the game, do my typing in RemoteTech and/or other input windows, and then resume. It's not ideal, but it used to be the only way to make sure numeric inputs didn't trigger action groups (oh, the !!fun!! I used to have entering numbers into MechJeb before switching to AGExt for my action group controls...).

[erendrake]

X and Z are special cases in the code that squad has made exempt from all
locking. in kos we have to get pretty aggressive with both keys by
unbinding them from their tasks and then rebinding on blur. it is not an
ideal situation

On Sat, Jan 10, 2015, 08:55 Dennis [email protected] wrote:

hmm ok it doesn't work. Neutralize the FlightCtrlState also cuts the
engine every time you focus an input [image: 😩]

—
Reply to this email directly or view it on GitHub
#197 (comment)
.

[Peppie84]

I saved the current throttle before neutralize the FlightCtrlState and it looks ok for me. It can also resolve #245 but i'm not sure :/ here my branche: Peppie84@53d652f if someone wants to fight with that issue

[henrybauer]

FYI a workaround is to go into the settings in the main menu and change the action groups to be fired by the numeric keypad. Then you use the number keys above QWERTY to type numbers, and the numeric keypad to fire action groups.

Since there's also a bug on Linux that the numeric keypad doesn't work as numbers, the two bugs sort of cancel each other out. :)

[pjf]

FYI a workaround is to go into the settings in the main menu and change the action groups to be fired by the numeric keypad. Then you use the number keys above QWERTY to type numbers, and the numeric keypad to fire action groups.

I love you so much right now.

[SirDiazo]

Okay, I had this issue pointed out to me and I had something of a brain wave that I hope works.

The base issue is that KSP doesn't lock everything with InputControlLock so that is the issue to actually fix rather then every mod getting it's own workaround.

So, I did that and it can be found here.
http://forum.kerbalspaceprogram.com/threads/108561

A simple mod that unbinds/rebinds keys on request from your mod to enforce a control lock.

It also includes a backup feature so that if a crash (or Alt-F4) happens with the lock engaged (and the keys unbound) it rebinds the keys on the next start of KSP.

As I envision it, that should solve everyone's issues with this problem.

To make sure developers who use this aren't tying themselves down, I release the code into the public domain so that it can be maintained by people other then me.

[Baughn]

Great idea!

But please don't just release it into the public domain. Apart from issues of safety (you're missing an indemnifying clause, or indeed any clauses at all), it isn't legal for you to release code into PD in all jurisdictions, so not all people can legally use your code at all. Instead, just use a highly permissive license such as MIT.

[Peppie84]

Merged into 1.7