Oh PAUSE key where art thou in v0.6.2 F1 help screen still says "None"!
#2
Posted 06 August 2011 - 10:40 AM
Eldorado.Railroad, on 06 August 2011 - 10:21 AM, said:
Eldorado
Don't you have a pause key on your keyboard? Are you on a laptop? Please check the F1 HUD for PAUSE key mapping for your specific system. It works on a normal full keyboard.
#3
Posted 06 August 2011 - 02:11 PM
#4
Posted 07 August 2011 - 01:31 AM
Eldorado.Railroad, on 06 August 2011 - 08:55 PM, said:
Commands[(int)UserCommands.GamePause] = new UserCommandKeyInput(0x11D);
The 0x11D is in fact a multi-byte scancode representation within OR (for "E1 1D"). Values over 0x80 represent "E0 hh" extended codes and values over 0x100 represent "E1 hh" extended codes.
Eldorado.Railroad, on 06 August 2011 - 08:55 PM, said:
The code was rewritten between v645 and v677 to use scancodes so that we didn't have problems with keyboard layouts.
Eldorado.Railroad, on 06 August 2011 - 08:55 PM, said:
You're almost certainly using virtual keys instead of scancodes, though, and I would be shocked if virtual keys didn't get Pause correctly. ;)
There are two possible problems here; either MapVirtualKey() on Windows XP does not support the multi-byte scancodes as well as Vista+, or the keyboard driver is simply producing a completely different scancode for Pause.
Do you have the .NET 4 Framework Client Profile installed? I have a small test app that could potentially shed light on what's different about your system vs those that are working.
#5
Posted 07 August 2011 - 05:55 AM
#6
Posted 07 August 2011 - 12:56 PM
I also have the same problem. Using XP with SP 3, running on a Dell 530. Using an Logitech USA 101 keyboard.
Did a google search for scan codes, came across the following web page:
http://www.dragonblo...ause-break-key/
There is a quote; "The Pause/Break Key can sometimes be Special: NUM_LOCK (00_45) or Unknown:"
When using the shareware they reference SharpKeys, pressing the Pause/Break key see the NUM_LOCK (00_45)
As there are other ways to achieve the same results, via save/resume it's not worth it to me to start hacking
the registry. Also appears to be a XP or Dell specific problem.
Bill
#7
Posted 09 August 2011 - 12:33 AM
Eldorado.Railroad, on 07 August 2011 - 03:40 PM, said:
The "E0 hh" and "E1 hh" extended scancodes are the documented way Windows's API expose all the fun parts of keyboard input (i.e. beyond the basic range); anything outside the base scancodes is a tricky area though and certainly the keyboards themselves return some horrible stuff to Windows.
Eldorado.Railroad, on 07 August 2011 - 03:40 PM, said:
We were using virtual keys, but the main area (letters and numbers) move around depending on keyboard layout, which is problematic. I have been thinking about using a mixture, of virtual keys for the 'fixed' ones and scancodes for the others, but it's more complicated than doing one thing for every key.
Eldorado.Railroad, on 07 August 2011 - 03:40 PM, said:
Attached is the small program; if you run it, it will dump the scancode -> virtual key, and virtual key -> scancode mappings provided by the Windows APIs and then open a window to let you try pressing keys (which will report the virtual key and scancodes it found). The most useful thing would be attaching a copy of the first two tables (you can do this by running the program from the command-line as "KeyboardDump.exe > keyboard.txt" and closing the popup window when it appears).
Attached File(s)
-
KeyboardDump.zip (6.87K)
Number of downloads: 256
#8
Posted 10 August 2011 - 01:08 PM
Eldorado.Railroad, on 09 August 2011 - 01:33 PM, said:
It certainly does go both ways here (Windows 7 64bit), but it might just be that Windows XP doesn't support MapVirtualKeyEx with MAPVK_VK_TO_VSC_EX. OR doesn't use this conversion, it only uses scancode->VK, but it is interesting that it gets nothing out of it.
Looking at the docs for the scancode->VK conversion again, it appears that extended (both "E0" and "E1") scancodes are only supported in the conversion API in Vista and later. Damn. So even if Windows XP knows it is "E1 1D" --> "13", it won't tell us that, which is why OR can't find your Pause key.
I think we can just hard-code that conversion; the input is fixed in OR as "11D" so if a keyboard uses another scancode it'll break everyone anyway and the output is fixed in Windows as "13".
Eldorado.Railroad, on 09 August 2011 - 01:33 PM, said:
In the scancode table, both "9D" and "11D" show up as "Right Ctrl" - this is the same as for me and actually a bit of a bug in the KeyboardDump program [1]. The difference is that they map to VKs "A3" (Right Control) and "13" (Pause) here, but for you just "00" (None/undefined) for both.
[1] The function that gets the key names only supports basic and "E0" extended scancodes and it appears my code is passing the "E1" extended ones in the same as "E0", so the matching "9D" and "11D" names are expected but in reality only "9D" is called "Right Ctrl".
#9
Posted 12 August 2011 - 01:19 PM
OR version 0.6.2
Windows XP SP2
Keyboard layout: Belgian Azerty
Attached is the text file generated by the keyboardDump program, and from the detected keyboard layout it is clear a couple of keys are not correctly detected. You can find the reference layout here: http://en.wikipedia....pc_keyboard.svg I also attached the OR keyboard dump: all keys that include "Ã" do not function in the game.
Anyway, I assume this problem will resolve itself once you include a custom key mapper, since I can imagine it's not trivial to support every possible keyboard layout. :sweatingbullets:
Attached File(s)
-
keyboard.txt (19.01K)
Number of downloads: 211 -
orKeyboard.txt (10.34K)
Number of downloads: 210
#10
Posted 12 August 2011 - 02:41 PM