Bad / Missing Modifier KeyCodes in UWP (Microsoft Store App)

Bug Reports Mobile Bugs
#1

On UWP, some keyboard modifier-keys don’t behave as expected when listening to them through UserInputService / input events on UI objects:

  • Right Shift sends Enum.KeyCode.LeftShift
  • Right Ctrl sends Enum.KeyCode.LeftControl
  • Neither Left Alt nor Right Alt send anything at all.

This issue pertains only to the UWP Roblox Client (as opposed to the Windows Desktop client):

  • v2.369.11775 (MS Store)
  • v2.369.273919 (Help Screen)

I’m not sure if UWP apps in general have this as a limitation, but it creates an inconsistency in my game controls. I’d like to be able to use the same keyboard controls in both the UWP and Desktop apps, as I can use the UWP app on Windows 10 with touchscreen as a convenient substitute for testing on different resolution phones / tablets because its window can be resized.

Thanks.

12 Likes
Uwp roblox is buggy
#4

Just checked that this bug still exists UWP/(MS Store) App on Windows 10:

  • v2.377.26406.0 (MS Store)
  • v2.377.288550 (Help Screen)

I’d like to point out that a lot of people like to use a Shift-to-run feature, as I do–
I put it on Left-Shift, and I keep the Right-Shift working for the ‘Shift-“MouseLock”’ feature.
Something which works fine on the Desktop app.
But I cannot do this with the UWP app because of this bug.

Thanks

1 Like
#5

Additional input bugs with UWP/(MS Store) App on Windows 10:

  • v2.380.32302.0 (MS Store)
  • v2.380.0.293626 (Help Screen)

(Again these issues DO NOT apply to the default desktop app…)

  1. The Open/Close Backpack key does not work because it is set to detect Enum.KeyCode.Backquote
    (Which typically is on the same key as the Tilde; ‘~’) And indeed the Help menu shows a ‘~’ as the key
    to use, which you might assume to be okay, but when that key is pressed, the UWP App DOES NOT
    send Enum.KeyCode.Backquote, it sends Enum.KeyCode.Tilde (And doesn’t care if SHIFT is pressed.)
    I first attempted to see if I could work around this, but due to CoreScript security, and no apparent exposure
    of the BackpackScript Module, I cannot even simply call OpenClose() on it if I detect the tilde myself.

  2. When using a game controller, when there is a release of any control (or joystick direction change)
    it acts like a cancel is sent out and ends other game controller input, so for instance if your character
    is moving and you try to jump, as soon as you release the jump button the character will STOP.
    There is a telltale way to detect when this happens, however no workaround seems available;
    A UserInputService.InputEnded event is fired with UserInputType.Keyboard AND KeyCode.Unknown.
    This bug prevents all game controller simultaneous actions / chording from working properly.

Thanks.

2 Likes
Xbox One controller does not work properly on mobile
#6

Even more input bugs with UWP/(MS Store) App on Windows 10:

  • v2.385 (all other input bugs mentioned earlier in this thread still exist.)

(Once again these issues DO NOT apply to the default desktop app…)

When in First Person mode, ie:
game.Players.LocalPlayer.CameraMode = Enum.CameraMode.LockFirstPerson

Mouse buttons often do not work at all; UserInputService event callbacks are never called.

When exiting First Person mode, ie:
game.Players.LocalPlayer.CameraMode = Enum.CameraMode.Classic

Mouse buttons magically work again [but game might get stuck in MouseLock-like mode.]

Anyway, once in FP mode, typically the mouse buttons seem to all always work or not at all–
So for instance you could go into FP, and the mouse buttons don’t work, then exit FP, then re-enter
FP, and the mouse buttons might work, exit again, re-enter and then not work.

Thanks.

2 Likes
#7

An input inconsistency with UWP/(MS Store) App on Windows 10:

Background:
In the Desktop App, during gameplay, whatever the state of NumLock is, the keypad
will send the same codes–This is a feature in the sense that a player won’t be surprised/confused/delayed
by having to hit NumLock for a keypad feature to work correctly–That’s fine as a feature choice, and in
fact the system overrides this feature during chat (from a bug report years ago, so NumLock works
correctly during chat)–Again, a perfectly reasonable choice.

However, in the UWP App, during gameplay, NumLock DOES change what keycodes are sent,
eg. Enum.KeyCode.KeypadFour vs. Enum.KeyCode.Left. This is an INCONSISTENCY between
the apps, and therefore can be a problem unwittingly for both developers and players.

Thanks.

2 Likes