Hi everyone,
I have two questions about the new InputSystem.
- I have a german Windows10 with a german keyboard-layout. If I add a binding and use “Listen” in the Action type to catch the selected key I get a “Y” if I press a “Z” and vice versa. Is this the behaviour by design?
- In the screenshot above, you can see an Action named “BackToSettings”. It has two keys defined, “b” as shortcut for “Back” to return to the main menu if the game language is set to english, and “y” (Z in german, see question 1) for “Zurück” if the game language is set to german.
In my MenuManager I have these lines of code to react on keypress:
controls.UISettingsVideoMenu.Enable();
controls.UISettingsVideoMenu.Camera.performed += VideoCamera_performed;
controls.UISettingsVideoMenu.BackToSettings.performed += BackToSettings_performed;
This is the code from the method:
private void BackToSettings_performed(InputAction.CallbackContext ctx)
{
bool backToSettings = ((KeyControl)ctx.control).keyCode == Key.Escape;
if (!backToSettings)
{
LocalizationManager.Read();
switch (LocalizationManager.LCID)
{
case LCIDs.German:
if (((KeyControl)ctx.control).keyCode == Key.Y)
{
backToSettings = true;
}
break;
default:
if (((KeyControl)ctx.control).keyCode == Key.B)
{
backToSettings = true;
}
break;
}
}
if (backToSettings)
{
DisableControls();
CurrentMenuState = MenuState.Settings;
SceneManager.LoadScene("Settings");
}
}
It doesn’t feels right that I have to differentiate between the languages on the one side. And on the other, I don’t like that I have to check for a specific keyCode. On that way I have two places where I have to define the keys to use. Not to speak for that Y/Z-thing… 
This can’t be the best practice, can it?
Greetings
Lone
Yes. Albeit at the same time something that we should make more obvious in the UI.
The way this works is that all the bindings deal in control names. These names are immutable. The control names for keys on a keyboard are layout-agnostic and fixed to the US keyboard layout for reference (could really be any layout but this one seemed an obvious default choice).
Put another way, if you bind to the “Y” key, on a German keyboard, this will be the key with “Z” printed on it.
However, all controls also have display names and these can change around. For a keyboard, the display name is the fully mapped key.
You can bind to keys by their display name using the “By Character Mapped to Key” group under “Keyboard”.
If you bind to “Y” in this way, the key will always be the one generating the “Y” character regardless of where on the keyboard the key is (including not being on the keyboard at all).
The above thing solves that.
There’s no support ATM to have bindings become active based on locale. However, it’s possible to set up something to that end using control schemes. You could have a “Keyboard (English)” and a “Keyboard (German)” control scheme and then bind them differently and select the control scheme to use in code based on the current locale.
Ah okay, I didn’t ever have seen this, thanks for the hint.
For my other problem, if I understood you correctly, you would suggest the following approach?
I splitted up the control schemes into two separate ones:
And the code-line have been reduced to the following as update from my previous posted code:
Registering the callback-methodx:
controls.UISettingsVideoMenu.Enable();
controls.UISettingsVideoMenu.Camera.performed += VideoCamera_performed;
LocalizationManager.Read();
switch (LocalizationManager.LCID)
{
case LCIDs.German:
controls.UISettingsVideoMenu.BackToSettingsDE.performed += BackToSettings_performed;
break;
default:
controls.UISettingsVideoMenu.BackToSettingsEN.performed += BackToSettings_performed;
break;
}
The callback-method has reduced to this few lines without any check for pressed keyCodes or language-differentiation:
private void BackToSettings_performed(InputAction.CallbackContext ctx)
{
DisableControls();
CurrentMenuState = MenuState.Settings;
SceneManager.LoadScene("Settings");
}
I like this approach very much, I hope this implementation was your intention 
If it works for you, good What I meant was doing it with control schemes.
1 Like
Wow, that’s even better!
But how do I set in code, which Control Scheme to use?
For code generated from .inputactions with “Generate C# Class”, this is currently a bit of a manual process. I previously posted some details about this here .
The key property here is bindingMask which controls which bindings to use and which to ignore. Each control scheme has an associated “binding group” that bindings in the control scheme are associated with.
var bindingGroup = myControls.controlSchemes.First(x => x.name == "Keyboard (EN)").bindingGroup;
myControls.bindingMask = InputBinding.MaskByGroup(bindingGroup);
1 Like
Fantastic! This is exactly what I was looking for. Thank you very much
1 Like
One last question:
The middle mouse button (pressing the mouse wheel to the left/right) some kind acts as cursor left/right keypress.
Is there a way to deactivate the mouse completely with the InputBinding-methods or ignore its input-signals?
I tried it with this codeline but it doesn’t work:
_controls.devices = new [ ] {Keyboard.current};
Is there a way to convert a KeyCode to a char, so that the correct character appears in (for example) an on-screen tutorial popup?
KeyCodes, as mentioned before, are language agnostic and are meant to refer to physical locations on the keyboard, using a US-keyboard as a reference point. That is, KeyCode.Equals will always refer to the key directly left of the backspace key, even though a different symbol might be there for different languages. For example, on German keyboards, little tick marks are next to the backspace key.
However, what I’d want is a way to, given the KeyCode and the keyboard layout used (as determined by their OS) return what character is printed on that key. That way, Americans who are prompted with “Press [=]” and Germans who are prompted with “Press [`]” are reaching for the same place on their keyboard.
There appears to be a class that does this:
It’s in the namespace System.Windows.Forms which we can’t access. 
