I fond a bug in custom (sprite editor) concerning keyboard shortcuts on non US keyboard layouts.
On my German keyboard for example I cannot access the brackets"[", "]", tilde "~" and greater than ">" shortcuts in the sprite editor.
I guess it has to do with the need to press modifier keys in order to get the symbol.
Thanks for the report. This is something I've been wondering for a long time, because I'm not able to test it myself. When I set a foreign keyboard layout on my computer, it only changes the results while typing text, but the scancodes reported to the OHR, which it uses for everything except for text input, remain the same.
Which operating system are you using? I'm on Linux; I suspect that other OSes will handle layouts differently.
Is it even appropriate to use keys like < and >, typed in the normal way (e.g. Shift + <)? The reason we use < and > is because they are next to each other, but I guess people will be used to typing them in pairs anyway. However it looks like [ and ] are quite annoying to type for you?
Another possibility would be remappable keys for each menu, or just globally, which would be nice but a lot of work.
If you're using Windows, then can you try temporarily removing or renaming gfx_directx.dll, which will cause the gfx_sdl graphics/IO backend to be used instead. Then try that to see if it makes any difference.
I don't actually expect it will make a difference. But once you are using gfx_sdl then you can pass the --input-debug option to Custom on the commandline, which will cause it to log every keystroke to c_debug.txt. That would be very useful to me to understand what the engine sees while typing certain keys.
Hi TMC,
yes programming in C-style languages is a real pain with a german keyboard. Thats why I prefer visual basic and python. ^^
Having re-mappable keyboard shortcuts would be very handy in the long run.
I'm also running Linux (Mint 17.3 64Bit Cinnamon) with the official 32bit version of ohr so sdl backend should be default.
I tried running custom with "--input-debug" but it didn't create any debug file named "c_debug.txt" or "d_debug.txt". According to the help there is a "-recordinput" parameter which created a binary file (see attchment). Maybe it is of help for you, I can't read it.
I used the arrow keys + enter to move into the tileset sprite editor. Then 10 times the right arrow key until I reached an empty tile. There I pushed "[" -> "]" -> "~" -> ">" (in that order) and exited by hitting "ESC" multiple times.
If you need someone to test I'll be happy to assist you. I managed to compile the code myself but am not quite familiar with Freebasic.
Ah, actually we're designing some extensions to Hamsterspeak right now, and I'm trying to use characters which are easy to type on most keyboards. It's too bad [ and ] are difficult; I wouldn't consider anything else for array indexing.
Thanks, I had a look at that file. But it just shows you typed 8 9 = and <. --recordinput provides far less information than --input-debug.
The location of the c_debug.txt/g_debug.txt log file is a bit complicated, and Game and Custom place it in different locations... I don't even know the rules off the top of my head. If you're playing/editing a game it'll be next to the .rpg file, if possible. Otherwise Game puts it in the current directory, and Custom puts it next to ohrrpgce-custom or ~/Documents... gosh we need to simplify this. You can override the location with --log .
Anyway, it turns out that these --input-debug messages aren't marked as errors, and the g/c_debug.txt file is automatically deleted when you quit if there are no errors. So you need to copy/upload the file before quitting.
You might have noticed that there is also a --native-kbd option. Passing this should cause keys to work correctly while you are typing text like textboxes (let me know if that's not the case!), but I don't think affects the scancodes reported, which are used for shortcut keys. --native-kbd isn't the default on Linux because James had problems with stuck keys with it.
Could you please use --input-debug to record yourself pressing those keys, once with --native-kbd and once without, after entering the file browser ("Load Existing Game" in Custom, or just start ohrrpgce-game instead)? Text input is disabled on Custom's initial menu but enabled in the file browser.
Last edited by TMC on Tue Mar 14, 2017 3:21 pm, edited 1 time in total.
(I tried to use the short cuts in the sprite editor too but none of the parameters gave the desired result.)
Using "[" and "]" for arrays is pretty standard in most programming languages. I think it is OK.
The German keyboard layout is nothing against the French though, you need two hands for typing brackets there.
But I guess it can't be helped.
Last edited by Wendigo on Tue Mar 14, 2017 7:19 pm, edited 2 times in total.
Thanks! Very helpful. I think I can see what we can do about this; we'll have to use --native-kbd and try to work around the stuck keys problem (which is an SDL bug) some other way.
One thing I notice is that the OHR doesn't treat AltGr as an Alt key. So for example you won't be able to use alt+arrow keys to select a colour in the sprite. Probably it should be usable for that, just as long as we don't combine it with anything aside from arrow keys, space, tab, and a couple others.
In fact... Alt Gr isn't responding on my computer either! Even though I have the layout set to US! It used to work.
Ah ha, I figured out that xkb (the X11 KeyBoard extension) uses the first keyboard layout to determine the scancodes and actual, you know, keyboard layout. Changing the active keyboard layout to another one only changes the way that keypresses are translated to text, not what the keys are reported as! So, now I'm able to do further testing myself. (This explains why my Alt had morphed into an AltGr).
I have been thinking more about how to deal with this, and might try to do something for the next release (there aren't that many menus that use punctuation/symbol hotkeys). Argh; I should work on animations first though.
Last edited by TMC on Fri Mar 17, 2017 11:40 am, edited 2 times in total.
