Skip to main content
Extending results to Mac
Source Link
DMGregory
  • 140.8k
  • 23
  • 257
  • 401

Good news! This code:

bool ctrl = Input.GetKey(KeyCode.LeftControl) 
         || Input.GetKey(KeyCode.RightControl);

already respects the user's OS settings for sticky keys and key remapping on Windows and macOS at least. And this works whether you specify the key by KeyCode, by a "Conventional Game Input" string, or by a remappable GetButton("Some Custom Name") alias you've defined in the Input Manager.

That's because Unity isn't talking to the keyboard directly; it's asking Windowsthe OS "Is the left control key pressed?"

WindowsThe OS, knowing that you've remapped your left shift key to act as the left control, and that you've enabled sticky keys and double-tapped that shift key, is then free to lie to Unity and say "why yes it is!" even if the physical key on your keyboard labelled "CTRL" says otherwise.

Give this a try. Set up a script with some public boolean values that you set in Update based on various key states. Or use them to toggle visibility of some rendered objects. Then enable Sticky keys in your OS, or remap some keys in your registry (and log out / back in to use the updated settings). Run your game, and watch how the values change in reaction to your key presses.

I've just done this in both Windows and macOS, and both sticky keys and registry remapping are correctly respected by Unity on Windows, without any changes to my code.

Now of course you can still do one better by allowing players to remap controls within your game, rather than relying on OS-wide/OS-specific settings, but it's good to know that Unity won't disregard those configurations when they're in use on Windows.

Good news! This code:

bool ctrl = Input.GetKey(KeyCode.LeftControl) 
         || Input.GetKey(KeyCode.RightControl);

already respects the user's OS settings for sticky keys and key remapping on Windows at least. And this works whether you specify the key by KeyCode, by a "Conventional Game Input" string, or by a remappable GetButton("Some Custom Name") alias you've defined in the Input Manager.

That's because Unity isn't talking to the keyboard directly; it's asking Windows "Is the left control key pressed?"

Windows, knowing that you've remapped your left shift key to act as the left control, and that you've enabled sticky keys and double-tapped that shift key, is then free to lie to Unity and say "why yes it is!" even if the physical key on your keyboard labelled "CTRL" says otherwise.

Give this a try. Set up a script with some public boolean values that you set in Update based on various key states. Or use them to toggle visibility of some rendered objects. Then enable Sticky keys in your OS, or remap some keys in your registry (and log out / back in to use the updated settings). Run your game, and watch how the values change in reaction to your key presses.

I've just done this and both sticky keys and registry remapping are correctly respected by Unity on Windows, without any changes to my code.

Now of course you can still do one better by allowing players to remap controls within your game, rather than relying on OS-wide/OS-specific settings, but it's good to know that Unity won't disregard those configurations when they're in use on Windows.

Good news! This code:

bool ctrl = Input.GetKey(KeyCode.LeftControl) 
         || Input.GetKey(KeyCode.RightControl);

already respects the user's OS settings for sticky keys and key remapping on Windows and macOS at least. And this works whether you specify the key by KeyCode, by a "Conventional Game Input" string, or by a remappable GetButton("Some Custom Name") alias you've defined in the Input Manager.

That's because Unity isn't talking to the keyboard directly; it's asking the OS "Is the left control key pressed?"

The OS, knowing that you've remapped your left shift key to act as the left control, and that you've enabled sticky keys and double-tapped that shift key, is then free to lie to Unity and say "why yes it is!" even if the physical key on your keyboard labelled "CTRL" says otherwise.

Give this a try. Set up a script with some public boolean values that you set in Update based on various key states. Or use them to toggle visibility of some rendered objects. Then enable Sticky keys in your OS, or remap some keys in your registry (and log out / back in to use the updated settings). Run your game, and watch how the values change in reaction to your key presses.

I've just done this in both Windows and macOS, and both sticky keys and registry remapping are correctly respected by Unity, without any changes to my code.

Now of course you can still do one better by allowing players to remap controls within your game, rather than relying on OS-wide/OS-specific settings, but it's good to know that Unity won't disregard those configurations when they're in use on Windows.

Qualifying this to Windows
Source Link
DMGregory
  • 140.8k
  • 23
  • 257
  • 401

Good news! This code:

bool ctrl = Input.GetKey(KeyCode.LeftControl) 
         || Input.GetKey(KeyCode.RightControl);

already respects the user's OS settings for sticky keys and key remapping on Windows at least. And this works whether you specify the key by KeyCode, by a "Conventional Game Input" string, or by a remappable GetButton("Some Custom Name") alias you've defined in the Input Manager.

That's because Unity isn't talking to the keyboard directly; it's asking the OSWindows "Is the left control key pressed?"

Your OSWindows, knowing that you've remapped your left shift key to act as the left control, and that you've enabled sticky keys and double-tapped that shift key, is then free to lie to Unity and say "why yes it is!" even if the physical key on your keyboard labelled "CTRL" says otherwise.

Give this a try. Set up a script with some public boolean values that you set in Update based on various key states. Or use them to toggle visibility of some rendered objects. Then enable Sticky keys in your OS, or remap some keys in your registry (and log out / back in to use the updated settings). Run your game, and watch how the values change in reaction to your key presses.

I've just done this and both sticky keys and registry remapping are correctly respected by Unity on Windows, without any changes to my code.

Now of course you can still do one better by allowing players to remap controls within your game, rather than relying on OS-wide/OS-specific settings, but it's good to know that Unity won't disregard those configurations when they're in use on Windows.

Good news! This code:

bool ctrl = Input.GetKey(KeyCode.LeftControl) 
         || Input.GetKey(KeyCode.RightControl);

already respects the user's OS settings for sticky keys and key remapping. And this works whether you specify the key by KeyCode, by a "Conventional Game Input" string, or by a remappable GetButton("Some Custom Name") alias you've defined in the Input Manager.

That's because Unity isn't talking to the keyboard directly; it's asking the OS "Is the left control key pressed?"

Your OS, knowing that you've remapped your left shift key to act as the left control, and that you've enabled sticky keys and double-tapped that shift key, is then free to lie to Unity and say "why yes it is!" even if the physical key on your keyboard labelled "CTRL" says otherwise.

Give this a try. Set up a script with some public boolean values that you set in Update based on various key states. Or use them to toggle visibility of some rendered objects. Then enable Sticky keys in your OS, or remap some keys in your registry (and log out / back in to use the updated settings). Run your game, and watch how the values change in reaction to your key presses.

I've just done this and both sticky keys and registry remapping are correctly respected by Unity, without any changes to my code.

Now of course you can still do one better by allowing players to remap controls within your game, rather than relying on OS-wide settings, but it's good to know that Unity won't disregard those configurations when they're in use.

Good news! This code:

bool ctrl = Input.GetKey(KeyCode.LeftControl) 
         || Input.GetKey(KeyCode.RightControl);

already respects the user's OS settings for sticky keys and key remapping on Windows at least. And this works whether you specify the key by KeyCode, by a "Conventional Game Input" string, or by a remappable GetButton("Some Custom Name") alias you've defined in the Input Manager.

That's because Unity isn't talking to the keyboard directly; it's asking Windows "Is the left control key pressed?"

Windows, knowing that you've remapped your left shift key to act as the left control, and that you've enabled sticky keys and double-tapped that shift key, is then free to lie to Unity and say "why yes it is!" even if the physical key on your keyboard labelled "CTRL" says otherwise.

Give this a try. Set up a script with some public boolean values that you set in Update based on various key states. Or use them to toggle visibility of some rendered objects. Then enable Sticky keys in your OS, or remap some keys in your registry (and log out / back in to use the updated settings). Run your game, and watch how the values change in reaction to your key presses.

I've just done this and both sticky keys and registry remapping are correctly respected by Unity on Windows, without any changes to my code.

Now of course you can still do one better by allowing players to remap controls within your game, rather than relying on OS-wide/OS-specific settings, but it's good to know that Unity won't disregard those configurations when they're in use on Windows.

Updating after testing with multiple input mapping modes
Source Link
DMGregory
  • 140.8k
  • 23
  • 257
  • 401

Good news! This code:

bool ctrl = Input.GetKey(KeyCode.LeftControl) 
         || Input.GetKey(KeyCode.RightControl);

already respects the user's OS settings for sticky keys and key remapping. And this works whether you specify the key by KeyCode, by a "Conventional Game Input" string, or by a remappable GetButton("Some Custom Name") alias you've defined in the Input Manager.

That's because Unity isn't talking to the keyboard directly; it's asking the OS "Is the left control key pressed?"

Your OS, knowing that you've remapped your left shift key to act as the left control, and that you've enabled sticky keys and double-tapped that shift key, is then free to lie to Unity and say "why yes it is!" even if the physical key on your keyboard labelled "CTRL" says otherwise.

Give this a try. Set up a script with some public boolean values that you set in Update based on various key states. Or use them to toggle visibility of some rendered objects. Then enable Sticky keys in your OS, or remap some keys in your registry (and log out / back in to use the updated settings). Run your game, and watch how the values change in reaction to your key presses.

I've just done this and both sticky keys and registry remapping are correctly respected by Unity, without any changes to my code.

Now of course you can still do one better by allowing players to remap controls within your game, rather than relying on OS-wide settings, but it's good to know that Unity won't disregard those configurations when they're in use.

Good news! This code:

bool ctrl = Input.GetKey(KeyCode.LeftControl) 
         || Input.GetKey(KeyCode.RightControl);

already respects the user's OS settings for sticky keys and key remapping.

That's because Unity isn't talking to the keyboard directly; it's asking the OS "Is the left control key pressed?"

Your OS, knowing that you've remapped your left shift key to act as the left control, and that you've enabled sticky keys and double-tapped that shift key, is then free to lie to Unity and say "why yes it is!" even if the physical key on your keyboard labelled "CTRL" says otherwise.

Give this a try. Set up a script with some public boolean values that you set in Update based on various key states. Or use them to toggle visibility of some rendered objects. Then enable Sticky keys in your OS, or remap some keys in your registry (and log out / back in to use the updated settings). Run your game, and watch how the values change in reaction to your key presses.

I've just done this and both sticky keys and registry remapping are correctly respected by Unity, without any changes to my code.

Now of course you can still do one better by allowing players to remap controls within your game, rather than relying on OS-wide settings, but it's good to know that Unity won't disregard those configurations when they're in use.

Good news! This code:

bool ctrl = Input.GetKey(KeyCode.LeftControl) 
         || Input.GetKey(KeyCode.RightControl);

already respects the user's OS settings for sticky keys and key remapping. And this works whether you specify the key by KeyCode, by a "Conventional Game Input" string, or by a remappable GetButton("Some Custom Name") alias you've defined in the Input Manager.

That's because Unity isn't talking to the keyboard directly; it's asking the OS "Is the left control key pressed?"

Your OS, knowing that you've remapped your left shift key to act as the left control, and that you've enabled sticky keys and double-tapped that shift key, is then free to lie to Unity and say "why yes it is!" even if the physical key on your keyboard labelled "CTRL" says otherwise.

Give this a try. Set up a script with some public boolean values that you set in Update based on various key states. Or use them to toggle visibility of some rendered objects. Then enable Sticky keys in your OS, or remap some keys in your registry (and log out / back in to use the updated settings). Run your game, and watch how the values change in reaction to your key presses.

I've just done this and both sticky keys and registry remapping are correctly respected by Unity, without any changes to my code.

Now of course you can still do one better by allowing players to remap controls within your game, rather than relying on OS-wide settings, but it's good to know that Unity won't disregard those configurations when they're in use.

Source Link
DMGregory
  • 140.8k
  • 23
  • 257
  • 401
Loading