Reproduction Steps
Currently, as of 12/9/2021, the player corescript module has a serious UX issue. If you call PlayerModule:GetControls():Enable(), the controls are re-enabled, but it does not account for keys that the player is already pressing down, resulting in bad UX.
While holding the W key, click on the button in the bottom left of the screen. Observe that your avatar has stopped moving since the controls were disabled.
While still holding the W key, click the button again to re-enable movement. Observe that your avatar does not continue moving even though you are still holding down the movement input.
Let go of W, and re-press it. Observe that the avatar continues walking like normal.
Expected Behavior
It is expected that the control module will read for already pressed inputs when it gets re-enabled. This is good UX. If a game disables my movement, then re-enables it, I expect to resume moving if I am still holding down my movement key.
Actual Behavior
The player module does not account for already pressed movement keys. It instead requires an explicit re-press when GetControls():Enable() is called. This is bad UX.
Workaround
I forked & patched lines 130-140 in PlayerModule/ControlModule/Keyboard.lua to account for already pressed keys.
In a lot of usecases, developers call GetControls():Disable() in order to prevent the player from moving (because they were stunned, the round hasn’t started yet, etc). In our own specific usecase, we temporarily stun the player when they are hurt (there’s a knockback animation that plays, etc). When a player is hurt, they are often holding down a movement key (or multiple if moving diagonally). When the stun ends, players would expect to continue moving since they are holding down the movement keys.
As stated in my report details above, players expect to continue moving as soon as their controls are re-enabled if they are already holding down movement keys. Basically any platformer game does this (mario games, a hat in time, spyro games, etc). If the game requires you to explicitly re-press movement keys when it re-enables your controls, that results in very clunky behavior and is bad UX.
Furthermore, if a game such as a “hunger games” game locked me in place until a timer finished counting down, if my character didn’t move when the controls are re-enabled even though I’m holding my “move forward” key, I would be confused and think the game is broken.
The movement corescripts should be updated to check for already pressed inputs when controls are re-enabled, since it results in better UX.
Still an issue that causes really bad UX for games that use the PlayerModule to disable controls. Here’s an example in a ghost-catching game:
You have to move towards the “PULL” arrow to suck up the ghost. Inputs get stuck though during the stun process which causes friction as you have to let go and push them again seemingly randomly
For anyone else reading this topic, I’ve forked the PlayerModule to change this behavior when controls are enabled via PlayerModule:
On keyboard, it checks if WASD and Space are already pushed, and handles them properly
On gamepad, it accounts for thumbstick being at a non-zero position, and handles the A button being already held down
Mobile seems to be far too complicated to implement a similar solution in a timely manner sadly.
ForkedPlayerControls.rbxl (165.7 KB)
Here’s my forked version, free to take or modify. Grab the modified PlayerModule from here:
and put it in StarterPlayerScripts in your place to fix this on both keyboard and gamepad
