Best way to bind to different keyboard layouts

Hi all,

I have a question with regards to setting up binds for different keyboard layouts (AZERTY, QWERTZ, DVORAK) on Win64 builds.

As far as I can tell, there is no way to bind to scan codes in Unreal to have consistent physical layout (e.g. WASD in qwerty, ZQSD in azerty). Additionally, things like numeric keys don’t function out the box as the bindings only listen to the digit value, but the OS maps the key to the shift-modified value by default in azerty.

I have tested Fortnite and as far as I can tell it behaves the same as vanilla Unreal, e.g. there are no specific keyboard layout specific bindings to handle users with different layouts.

Do you have a recommendation on how to handle this? I do have a rough implementation which kind of works:

  • I create an input pre processor (IInputProcessor) to override HandleKeyDownEvent / HandleKeyUpEvent.
  • These events map from the system layout (e.g. user’s defined layout such as azerty), and these get mapped into qwerty land and sent through the engine.
    • This is done by converting from system -> scan code, then from scan code -> querty key.
    • This is done by creating mapping tables using MapVirtualKey win32 api method to create mapping tables from Virtual key to scan code and scan code to virtual key for standard qwerty layout, and the user’s active layout.
  • I also have created a blueprint function library to do the reverse mapping (qwerty to system layout). We can use this in the widget blueprint code to display the key prompts in the user’s current keyboard layout.

This means that we can config our game assuming qwerty. The user’s input is remapped to qwerty, and our qwerty UI prompts are mapped to the user’s layout.

This kind of works, but it all feels like a massive hack. It feels like I’m going against the grain here and fighting with the editor.

Am I missing something here? Is there a way to achieve what I want with vanilla Unreal? If not, are there any plans to support something like binding to scan codes to allow us to specify a physical location on the keyboard for the binding data rather than relying on keyboard layout and OS mappings?

Cheers!

-Steven

[Attachment Removed]

Hi,

We don’t have any sort of vanilla support for this, the closest thing would be the abstraction we do for gamepad face buttons. Doing something similar for physical key locations seems a bit trickier, especially since so many variants exist and prevent us from making many assumptions. Generally, there are two approaches you could take here:

  1. Add robust support for user-defined key mappings, and let players on less common configurations make their own mapping. You could go the extra mile and provide some defaults for different layouts using Enhanced Input’s PMIs.
  2. Your approach of rewiring inputs in a preprocessor makes sense, though there’s some risk of edge cases creating some bugs that you won’t see without testing extensively on those configurations (e.g. an errant blueprint that forgets to use your library to retarget an input).

A benefit of the first approach is that it would be simpler to display proper keys based on the currently applied bindings without having to do the conversion in a blueprint library, so that may be worth exploring if you haven’t already. I suspect users of non-qwerty configurations are used to poking around in the options menu and reconfiguring inputs, so just providing some presets would go further than many titles to support those configurations.

Best,

Cody

[Attachment Removed]