Question XR vessels : keymap for APU

[ganlhi]

Hi,

I'm french, so on my keyboard A key replaces Q key of US keyboards. But the keymap for APU on/off on XR vessels is Ctrl+A, which means Ctrl+Q on my keyboard : Orbiter quits !

Is there a mean to :
- change this mapping for XR vessels ?
or
- change/disable the keymap used to quit Orbiter ?

Thank you in advance.

 

[RisingFury]

Try your Ctrl+A, not Ctrl+Q.

I don't think the keys are replaced, just switched.

 

[ganlhi]

It doesn't work, that's why I posted here. In fact, if I switch my keyboard in english, I have APU on my Ctrl+Q and Orbiter quit on my Ctrl+A.
But switching my keyboard when I play Orbiter is not a solution for me...

 

[dbeachy1]

Worst-case you can always click the APU button on the panel. This is an odd one, sorry, I don't know what to tell you.

 

[ganlhi]

Yes, that's what I do, but I wanted to map it on my X52 :huh:

I guess the keymap is hard-coded ?

 

[Scarecrow]

Custom keymapping sounds like a good thing for the config file in the next revision of the XR vessels. Not that I would make much use of it, but it sounds like a good idea for those with non-english keyboards.

As an aside, my spell checker doesn't like "keymapping", and suggested "kneecapping" as a possible replacement! That also sounds like an intriuging feature for XR vessels: If you crash, but aren't seriously injured or dead, the vessel kneecaps you automatically as punishment.:lol:

 

[dbeachy1]

The XR code always looks for CTRL-A from the keyboard as the APU shortcut key, so yes, that is hard-coded. Internally, the Orbiter core reads the key code from the system, processes any codes it recognizes, and then sends the keycode down to the focus vessel for processing. The odd thing is that there appears to be no way to send a CTRL-A keycode from your keyboard to Orbiter without the Orbiter core treating it like CTRL-Q first (i.e., before the XR code gets it). But that doesn't make sense -- that would mean that the Orbiter core is using a different method to read CTRL-Q than it uses to read all other keys (which I'm almost certain is not the case).

Sorry, I'm stumped on this one. I'll ping Martin about this in the beta forum to be sure he notices the question -- he'll probably know something off the top of his head.

 

[agentgonzo]

I have the same problem (as I use a Dvorak keyboard). I've just had to get used to training my brain to use the keys that Orbiter is expecting, rather than what it says on the desk in front of me (so, for example, I have to press 'i' to raise the landing gear). You may have to get used to it I'm afraid.

I can't see why your Ctrl-Q should quit orbiter for you though.

Off the top of my head, I would imagine that Orbiter is reading the scan code from the keyboard via DirectInput which doesn't the standard keyboard mapping in Windows (I've seen this in many games - some recognise my dvorak layout and some don't, but ALL of them use the normal WASD keys (on QWERTY keyboard) for movement as default). Hope that made sense

 

[TSPenguin]

If everything else fails (which it seems), you could try using something like AutoHotKey and map the desired combo to an unused key.

 

[Face]

I'm french, so on my keyboard A key replaces Q key of US keyboards. But the keymap for APU on/off on XR vessels is Ctrl+A, which means Ctrl+Q on my keyboard : Orbiter quits !

Sorry to ask the obvious, but did you test this without any addon installed, too? Just to be sure it's in the core and not somewhere else...

regards,
Face

 

[ganlhi]

Yes, I tested on an install with only OrbiterSound and XR2/XR5.

 

[Face]

Yes, I tested on an install with only OrbiterSound and XR2/XR5.

So this is a "No" then. OrbiterSound and XRs are addons.

Could you - or someone with the same problem - test it without any addons, please? I'm sure it will make bug-hunting faster if we know it to be in connection with OS or XR2/XR5 - or to be present in the core already.

If you fire up a vanilla Orbiter install with a stock vessel scenario and leave Orbiter with your Ctrl-Q and Ctrl-A respectively, we'd have found a core bug for certain.
If not, install OS. Test again.
If it happens there, it may be something OS is doing (not very probable, but possible).
If not, install XR2. Now test it with a XR scenario. And so on.

I know it sounds silly to do this so restrictive, but this simple procedure saved me from many misleading assumptions regarding bug-reporting.

If you can rule out direct core (or OrbiterSound) bugs this way, dbeachy1 can focus on the keyboard routines inside XRx-code without keeping a weird core behavior in mind.

regards,
Face

P.S.: I may look like arbitrary nitpicking here, but I'm very interested in all bugs related to Orbiter's HMI. This is due to weird behavior I get with it from time to time in OMP (vanishing keyboard control, mouse got stuck in rotate-view mode, force-feedback joystick suddenly stuck). I was unable to reproduce them in vanilla installs, so I'm still convinced my addon is doing something wrong, but who knows....

 

[ganlhi]

Ok, I do it when I come back home, and I tell you.

---------- Post added at 09:12 PM ---------- Previous post was at 12:29 PM ----------

Here are the results of my tests :

• Base Orbiter : Ctrl+A doesn't quit, Ctrl+Q quits
• Orbiter + OS : Ctrl+A doesn't quit, Ctrl+Q quits
• Orbiter + OS + XR2 : Ctrl+A doesn't quit and doesn't toggle APU, Ctrl+Q quits

 

[dbeachy1]

Based on that, the root problem here is that the keyboard is not sending an English CTRL-A keycode to the Orbiter core (since the layout is French). Remember that since the XR vessels are designed for English keyboard layouts the code expects a "real" CTRL-A for the APU -- since the keyboard layout is French, CTRL-A on that keyboard will not send the same keycode as English keyboards do. Since there is no way for the XR2 to know what keyboard the user is using (it only receives keycodes propagated down from the Orbiter core), there is no way for it to treat the French CTRL-A code the same as the English CTRL-A code.

So the question is this: are you absolutely sure that CTRL-Q on your French keyboard sends what is a CTRL-A keycode on English keyboards? i.e., how do you know that French CTRL-Q is the actual CTRL-A English code?

EDIT:
In any case, since it appears that CTRL-Q quits Orbiter on your French keyboard, it does indeed appear that the Orbiter core is using a different method to check for CTRL-Q than it uses to read other keys. If CTRL-Q on the French keyboard really does send the equivalent of the CTRL-A English keycode and CTRL-Q still quits the sim even on French keyboards, that would unfortunately mean there is no way to send a CTRL-A to the sim without closing it since something in the Orbiter core (or an OS API call made by the core) is remapping the CTRL-A keycode to mean "quit the sim."

 

[Redburne]

Anyone can change the Windows keyboard layout to French and test this, by the way.
Bonus points for style, if you switch the physical keys as well ...

Looks like Orbiter does indeed switch CTRL-Q around to whichever key happens to function as "Q" at the moment.

This is clearly contradicting the information in Chapter 6 of the manual, and also the behaviour of other keys (like the zoom keys or the "altitude hold" AP).

My best guess: CTRL-Q is not really an Orbiter key code, but Windows/GUI stuff outside the core, and thus not processed by Orbiter itself but intercepted by Windows and converted into a WM_CLOSE message for Orbiter.

 

[ganlhi]

I don't think so : the default Windows key to close a window is Alt+F4, not Ctrl+Q. I think it has been hard-coded by Martin...

I don't know what to do... except asking dbeachy to add config file support for key mapping ^^

 

[dbeachy1]

Isn't there some third-party application that can capture keycodes sent to a program and remap them? That would also let other Orbiter add-ons works correctly with non-English keyboards. After all, this is not XR-specific, but an issue that affects Orbiter and all its add-ons.

 

[yagni01]

Isn't there some third-party application that can capture keycodes sent to a program and remap them? That would also let other Orbiter add-ons works correctly with non-English keyboards. After all, this is not XR-specific, but an issue that affects Orbiter and all its add-ons.

Its a little overkill, but AutoHotkey should be able to do it.

 

[ganlhi]

I guess I could use AutoHotKey to perform a mouse click on the APU button on the panel when I hit Ctrl+A, but I need to be on the central panel to do this.
If there is no other solution, I'll try that

 

[Face]

Here are the results of my tests :

• Base Orbiter : Ctrl+A doesn't quit, Ctrl+Q quits
• Orbiter + OS : Ctrl+A doesn't quit, Ctrl+Q quits
• Orbiter + OS + XR2 : Ctrl+A doesn't quit and doesn't toggle APU, Ctrl+Q quits

Thanks for testing. It shows to me that the first assumption made here (both french-layouted Ctrl-A and Ctrl-Q are quitting Orbiter) is wrong. Good.
So on your machine french-layouted Ctrl+Q (english/german-layouted Ctrl-A) is quitting Orbiter while it shouldn't be the case...

Anyone can change the Windows keyboard layout to French and test this, by the way.
Bonus points for style, if you switch the physical keys as well ...

Looks like Orbiter does indeed switch CTRL-Q around to whichever key happens to function as "Q" at the moment.

This is clearly contradicting the information in Chapter 6 of the manual, and also the behaviour of other keys (like the zoom keys or the "altitude hold" AP).

My best guess: CTRL-Q is not really an Orbiter key code, but Windows/GUI stuff outside the core, and thus not processed by Orbiter itself but intercepted by Windows and converted into a WM_CLOSE message for Orbiter.

Ok. I've done that now. On my machine with french layout - french (France) - it is NOT showing this weired behavior. I have a german Windows XP installation. Like stated in Chapter 6 of the manual, the meaning of the keys is fixed. French Ctrl-A is quitting Orbiter here, not french Ctrl-Q...

ganlhi, can you please tell us your OS installation language and the exact language-settings you are using (at least in my XP, there are about 6 different "french")? Also, did you have any keyboard-related services running while experiencing this? Like shortcut-handlers, layout-switchers, screenshot tools or the like...

If we can't nail it down, the only reliable way to detect the problem would be to install ganlhi's OS flavor - maybe in a VPC - and try to reproduce it there.

regards,
Face