Question XR vessels : keymap for APU

My Orbiter is installed on a Macbook Pro running XP Pro SP3. About my keyboard layout, I'll check it tonight when I'm at home.

I'll also try to run Orbiter on my girlfriend PC to see if the behavior is different from a Mac keyboard.
 
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 :)
You can also map one key to another.
 
Yes ? How does it work exactly ? Because my problem is that 2 features use the same key on my keyboard, and one is prioritary...
Must be missing something. From your post below it didn't look like you have 2 features/1 key so much as
(French) Ctrl-Q generates (English) Ctrl-Q
(French) Ctrl-A does not generate (English) Ctrl-A

Any idea what key equivalent it does generate? Doesn't generate Ctrl-Q since it doesn't quit. I think there's a keymapper that comes with AutoHotkey that provides the code for a key pressed.With that I think you can then map it to Ctrl-A. (Its been a while)

Probably silly suggestion, but I assume you tried brute force approach of trying all Ctrl-key combinations and see if any turned the APU on.
 
Don't know if I already mentioned that : if I switch my keyboard layout to english, Ctrl-A works for APU ! On french keyboards, A and Q are inverted compared with english keyboards.
 
Don't know if I already mentioned that : if I switch my keyboard layout to english, Ctrl-A works for APU ! On french keyboards, A and Q are inverted compared with english keyboards.
Right. What happens if you use something to map another key (i.e. tilde) to Ctrl-A?
 
Just to make sure, does your a key produce an A when typed within orbiter core functions? (Target selection box would be best to test afaik)
 
TSPenguin > Yes !

yagni01 > I'll try that, but I don't have enough time tonight, unfortunately. Maybe tomorrow.

---------- Post added at 02:20 PM ---------- Previous post was Yesterday at 07:24 PM ----------

Right. What happens if you use something to map another key (i.e. tilde) to Ctrl-A?

Just to be sure... You mean "map another key to Ctrl-A (english, so Ctrl-Q french)" ?
 
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.

Strange, as I have the same configuration as you.
Did you make sure (by entering text in a MFD) that Q and A are really switched?

Please be aware that switching keyboard layouts is a bit tricky in WinXP.
I've enabled multiple layouts (DE, EN, FR) and can switch them in the Windows task bar (in the "Eingabegebietsschemaleiste"... lovely name).

It took me a while to figure out that
a) this setting is "per application" (you have to start Orbiter and then switch the keyboard layout while the launch pad is active)
b) Orbiter kills itself on CTRL-Q and starts a new process, resetting the layout to your default (probably DE) each time you leave the simulation and go back to the launch pad
 
b) Orbiter kills itself on CTRL-Q and starts a new process, resetting the layout to your default (probably DE) each time you leave the simulation and go back to the launch pad

You can change the way orbiter does this. Under extras->debugging options->Orbiter shutdown options select "De-allocate memory and display launchpad dialog".
This should prevent the process from restarting and keep your keyboard layout. Of course this will also exiting to launchpad slower.
 
My current understanding of the situation:

  • All physical keyboards, wether they are showing French, English or German layouts, are identical. They just differ in the labels on the keys.
  • If you press the key to the right of the CAPS_LOCK key (which is labled Q on some keyboards, A on others), the keyboard will send the scan code 31 to your computer.
  • Usually, Windows uses the selected keyboard layout to translate this scan code to a letter (Q for French, A for German and English layouts).
  • The Orbiter simulation core either directly queries the scan codes or forces the English layout when checking for pressed keys, to be layout independent.
  • There are two exceptions to this rule: CTRL-Q (our problem) and text entry boxes (probably by design).
And a possible workaround (untested, of course ...) for add-on developers:

Treat CTRL-Q just like CTRL-A. This should fix it for French users, and should not affect others, as their CTRL-Q causes Orbiter to exit to the launch pad (hopefully) before the add-on receives the key.

This is not a clean fix (if it works at all), as there may be exotic layouts exchanging yet another key for Q, but short of changing Orbiter itself, I don't see a better solution.
 
In my opinion, the best solution would be addon developpers provide config file to let users modify the mapping. But as a profesionnal developper I know adding such a feature to an already released program is quite boring...
 
Strange, as I have the same configuration as you.
Did you make sure (by entering text in a MFD) that Q and A are really switched?

Please be aware that switching keyboard layouts is a bit tricky in WinXP.
I've enabled multiple layouts (DE, EN, FR) and can switch them in the Windows task bar (in the "Eingabegebietsschemaleiste"... lovely name).

It took me a while to figure out that
a) this setting is "per application" (you have to start Orbiter and then switch the keyboard layout while the launch pad is active)
b) Orbiter kills itself on CTRL-Q and starts a new process, resetting the layout to your default (probably DE) each time you leave the simulation and go back to the launch pad

Yes, thanks for the hint. Catch a) did it for me. I just switched it, tested with notepad and thought it will be switched for Orbiter (started afterwards), too. Mea culpa.

After switching it with Orbiter started, it showed the same behavior as described, i.e. "french" Ctrl-Q quitting Orbiter instead of "french" Ctrl-A as it should be.

You can change the way orbiter does this. Under extras->debugging options->Orbiter shutdown options select "De-allocate memory and display launchpad dialog".
This should prevent the process from restarting and keep your keyboard layout. Of course this will also exiting to launchpad slower.

Yeah, I've disabled the fast-shutdown anyway due to incompatibility with OMP's logging system.

In my opinion, the best solution would be addon developpers provide config file to let users modify the mapping. But as a profesionnal developper I know adding such a feature to an already released program is quite boring...

IMHO, the best solution would be to fix that in Orbiter's core. It is obviously a bug, because it contradicts the documentation AND causes troubles due to key collisions.

regards,
Face
 
IMHO, the best solution would be to fix that in Orbiter's core. It is obviously a bug, because it contradicts the documentation AND causes troubles due to key collisions.

I concur with Face: it is much more elegant to fix it in one place (a simple fix in the Orbiter core) rather than requiring each add-on to reinvent the wheel each time and implement its own key remapping.
 
Back
Top