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: 332
#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: 271 -
orKeyboard.txt (10.34K)
Number of downloads: 271
#10
Posted 12 August 2011 - 02:41 PM
#11
Posted 15 August 2011 - 02:18 PM
James Ross, on 12 August 2011 - 02:41 PM, said:
Look, I posted some feedback on the OR website about another subject, only mentioning this keyboard issue and I've been urged twice to post in this thread since it is clearly related. Now what you do with the information I supplied is up to you, I'm only trying to contribute a little.
#12
Posted 28 August 2011 - 10:20 AM
Eldorado.Railroad, on 14 August 2011 - 10:30 AM, said:
I'd prefer not to support XP from a purely technical position, but practically we'll have to support it for years yet. :sweatingbullets:
Sorry I didn't get back to you sooner about testing, I do have a version to try. Please extract the current 0.6.2 release from the website in to an empty directory and then extract the attached file (containing 2 files) over the top (overwriting those two files from the release). This is a patched version which only changes the behaviour for the pause button.
Attached File(s)
-
Open Rails 0.6.2-vki1.zip (322.48K)
Number of downloads: 304
#13
Posted 28 August 2011 - 12:49 PM
downloaded your patch and installed in my XP system. Works beautifully, thank you very much now if I can just break the MSTS habit of hitting Esc to pause all will be right in the world!
:sweatingbullets:
#14
Posted 28 August 2011 - 01:08 PM
spud, on 28 August 2011 - 12:49 PM, said:
Excellent. I should get around to implementing that esc dialog I guess. :sweatingbullets:
#15
Posted 31 August 2011 - 09:58 AM
Eldorado.Railroad, on 31 August 2011 - 08:05 AM, said:
Great; thanks for testing.
With two confirmations, I think is good to go in the code, so you guys can expect this to all work in the next release too. :rotfl: