Not if you use key position and not KeyCode. If you use the objective key position it doesn’t matter what the actual key is. It would be the same way AZERTY/QWERTY movement is coded, where AZERTY = QWERTY.
After some digging, I found this thread:
Hi guys I wasn’t too sure If this was the right place to post about a recent issue that one of my friends brought up on the ROBLOX Discord. His username on ROBLOX is NoCollider and here is an issue he has been experiencing very recently on the ROBLOX client. (Happened once while on ROBLOX Studio) Let me know If you experienced the same issue and If you have a fix for it please post it too
where @darthskrill said:
So this is probably related to a feature I’ve been trying to ship for some time now.
Essentially all key input in a game will be normalized to US QWERTY. This is to give devs an easy way to target physical locations of keys w/o having to account for the myriad number of different keyboard layouts. I also plan to expose a way for devs to query what key the user expects at each of these locations, in case the dev wants to give the user a prompt to press a certain key or whatever.
When you type in a textbox (or if you just listen to the event type ‘Enum.UserInputType.TextInput’ on UserInputService) you will get the correct text input according to your layout however. So, actual key input is normalized for devs, but user input shows up how the user would expect it.
I’m curious what the issue is though, because trying to play roblox right now with a layout different than qwerty should still produce qwerty keycodes (otherwise WASD movement would be very hard).
But despite all, it is such a pain for people who have AZERTY keyboards. Imagine playing every game like this:
2 Likes
