slime wrote: ↑
Thu Nov 09, 2017 12:45 am
You should also present key codes (e.g. getKeyFromScancode) to the user rather than scancodes, generally. Scancodes are best used for internal logic.
Yeah, that's what I am doing at the moment with the keys that have scancodes.
If you want to assign actions/inputs to combinations of keys, you should just present those key combinations to the user. "!" is only shift+1 on some keyboard layouts, so if you want to use shift+1 (or more accurately, shift + the key where '1' is on a US keyboard layout) you should just present it to the user instead of trying to resolve what the text input would be based on the key combination you want.
Ok, I don't want to use key combinations. Logging "shift + whatever key" was just an idea how to approach it. I guess this means I should use scancodes for all "normal" keys and use "text.input"-characters for the rest?
So let's say I bind my help screen to the "?" key, a german keyboard would require "shift + ß" whereas an american keyboard would require "shift + /", but both would produce the "?" character in text.input, right?
Hm ... love.textinput basically just behaves like love.keypressed right? I mean there is no love.textinput released obviously. I mean I could do something like this
Code: Select all
keys[t] = true
then clear that at the end of each frame. How often does textinput trigger if one would hold down the "@" key for example?
The example you have linked does not seem to rely on checking the key combination the way you want it either. It receives and processes character information and acts on that instead of checking each key individually.
I think we are talking about two different things entirely
At least I'm not sure what you are trying to tell me here.