Closed hsandt closed 4 weeks ago
OK I found two side effects of this:
So maybe we should add a condition to verify the type of input stored to display it properly for each case?
OK so I found the solution to both issues thx to https://github.com/godotengine/godot/issues/84731 which mentions the doc: https://docs.godotengine.org/en/latest/classes/class_inputeventkey.html#class-inputeventkey-property-physical-keycode
Applying this to the get_text
function:
elif event is InputEventKey:
var keycode := DisplayServer.keyboard_get_keycode_from_physical(event.physical_keycode)
return OS.get_keycode_string(keycode)
We can now get the physical keys properly, and also display them according to current keyboard layout.
This means that whenever main menu scene is loaded, it will be filled with the correct key display. Now it's just a matter of refreshing the controls displayed more often than scene loading, e.g. each time the Controls tab is displayed, and users shouldn't have any issue seeing the correct mapping even if they switch layout mid-game! (and of course we can even detect layout change at arbitrary times but that's a bit more complex)
And for the blank entries, we should always define special keys like Space and Escape as physical keys, so they are displayed properly with the code above (but it also works with the current event.get_physical_keycode_with_modifiers()
, so it was a separate issue after all).
Still not fully fixed:
DisplayServer.keyboard_get_keycode_from_physical
fails to see modifiers completely
OS.get_keycode_string
+ event.get_physical_keycode_with_modifiers
sees modifier but not non-physical letter key
So I have yet to find a solution to display Ctrl+Cmd+F (non-physical) or Cmd+Q (non-physical), common shortcuts on macOS for toggle fullscreen and exit app, properly. I suppose F won't move much so I can make it physical, but even then I need to adapt DisplayServer.keyboard_get_keycode_from_physical
+ OS.get_keycode_string
to work with modifiers. Doc says OS.get_keycode_string
supports modifiers so I'm not sure what's missing.
Also, it's hard for user to add a modifier themselves because they must hold the modifier while clicking OK, but that's another issue.
Thanks for looking into this in-depth and documenting it. This issue can affect more users since I've added default input editing in https://github.com/Maaack/Godot-Game-Template/pull/101 (which closed https://github.com/Maaack/Godot-Game-Template/pull/98). I'm not sure the best course of action and will try to research other solutions.
I also found this function: InputOptionsMenu.gd But it's never called.
I think that is legacy code from the Godot 3 version and should be removed. I was probably hoping it'd be useful again someday.
Also, it's hard for user to add a modifier themselves beause they must hold the modifier while clicking OK, but that's another issue.
Yeah, I do want to iterate on that system again, and mimic the design of Godot's input action editor.
Thanks, I manually copied the new get_text
implementation and it works great!
EDIT: Label keys are displayed properly, but Unicode keys are still invisible...
Thanks for testing it out. I started a new ticket for it.
I'm using an international US keyboard myself I didn't notice this at first, but when I tried to switch to Azerty to register the Q key, it was still displayed as Q, in both the prompt and registered key. I verified that it was also bound to physical Q = A on Azerty indeed.
While this allows stable display, it's confusing when using an actual Azerty keyboard, or other.
I see the complexity of displaying the right key at all times though: you'd have to detect system layout change at runtime, and I'm not sure there is a signal for that.
However, it should at least work when the layout doesn't change mid-game.
I found the culprit line:
InputHelper.gd
Maybe it could use
get_keycode_with_modifiers
instead. In fact, I just tried it and it works. Can you think of any side effect of doing this?Ideally it would allow the user to choose a physical mapping like Godot editor itself, but I understand it would be extra work and few people would need to do that.
I also found this function:
InputOptionsMenu.gd
But it's never called.