The bug I am reporting is in regards of the UserInputService.InputBegan event. The KeypadEnter keyCode only works in studio. I don’t know if this would fall under Client bugs or Studio but I would assume it’s Client. It would appear that checking the condition of:
if input.KeyCode.KeypadEnter then
only works in studio, even works while doing a local test. However, when I test this in a live server it will not register at all as if I never pressed it. I found a work around by just using:
if input.KeyCode.Return then
Once I do this, it will begin registering. Meaning that both are the Return key, rendering KeypadEnter useless.
I’ve printed the input.KeyCode in the console and confirmed that they both just revoke the same result.
Binding to the keypad return is poor form unless you’re developing for a specific, known set of users. Even in 2017, there are keyboards without numpads.
It’s not bad practice for all target audiences. Most desktop PC users have keyboards with keypads (and the few that don’t are not the target audience), just like desktop users have a mouse while laptop users don’t. Games are not required to support all platforms. For a game like Brick Bronze, NumpadEnter would not be a good pick, but NumEnter is more than appropriate in an RTS-style game where 1-9 are used to select unit cards, Num1-9 are used to select groups, Enter is used to select each unit, and NumEnter is used to select all groups.
Regardless of target audience though, a game may have user keybinds and a user may want to bind to NumpadEnter. There’s no excuse for KeypadEnter to be intentionally left broken.
