Forums » Suggestions
Don't allow capslock to flip Key and Shift+Key keybinds by default
At the moment, you can flip your Key and Shift+Key keybinds with capslock. This is intended behaviour.
However, virtually no other game does this. Some just straight up ignore capslock altogether, and others treat it like any normal key, allowing you to bind something onto capslock. Key is always Key, and Shift+Key is always Shift+Key, no matter how capslock feels.
The current behaviour can therefore catch new players off guard, which, in a game like this, can easily happen at a very inconvenient time (e.g. battle). It might even have them thinking that the game is broken, in case they hit capslock accidentally, when in reality, it's just the game making a very unconventional UX decision.
I propose one of two solutions:
1. Treat capslock like any other key.
This directly copies how other games do it. Key stays Key, Shift+Key stays Shift+Key, and capslock is just another key you can use. This would disable the whole Key and Shift+Key switching though.
2. Where possible, bind by default Shift+Key onto the same as the according Key (e.g. have Shift+W be just like W, which is go forwards).
This keeps the current behaviour, while not catching new players off guard. Professionals still get to use capslock to flip their bindings.
In either case, I would still treat capslock like capslock for text input.
However, virtually no other game does this. Some just straight up ignore capslock altogether, and others treat it like any normal key, allowing you to bind something onto capslock. Key is always Key, and Shift+Key is always Shift+Key, no matter how capslock feels.
The current behaviour can therefore catch new players off guard, which, in a game like this, can easily happen at a very inconvenient time (e.g. battle). It might even have them thinking that the game is broken, in case they hit capslock accidentally, when in reality, it's just the game making a very unconventional UX decision.
I propose one of two solutions:
1. Treat capslock like any other key.
This directly copies how other games do it. Key stays Key, Shift+Key stays Shift+Key, and capslock is just another key you can use. This would disable the whole Key and Shift+Key switching though.
2. Where possible, bind by default Shift+Key onto the same as the according Key (e.g. have Shift+W be just like W, which is go forwards).
This keeps the current behaviour, while not catching new players off guard. Professionals still get to use capslock to flip their bindings.
In either case, I would still treat capslock like capslock for text input.
At the moment, you can flip your Key and Shift+Key keybinds with capslock. This is intended behaviour.
To be clearer.. the "flipping" is happening because of your particular hardware and OS. The fact that we currently do not mess with capslock is the intended behaviour. As far as I'm aware (?), we aren't doing anything to it at all.
1. Treat capslock like any other key.
I'm guessing what you mean by this is "disable capslock from actually being capslock". I don't know what other games are doing. If it isn't "capslock" by default then.. what is it? My suggestion was to make it some kind of "null" binding that would basically disable the key entirely (although this may be problematic in other regions, as noted later).
I haven't checked on this, but as far as I'm aware you can already bind capslock to be something else? We just don't do that by default. So the "and capslock is just another key you can use" thing should already exist.
2. Where possible, bind by default Shift+Key onto the same as the according Key (e.g. have Shift+W be just like W, which is go forwards).
So, I guess the question here is.. to what extent should we be doing this? "WASD" and "wasd" is easy enough, but beyond that?
Also, while I don't think (?) it'll matter for "game control" cases (where flight controls are active), it is notable that not all keyboards and character input locales have the same concepts for "shift" and "capslock" and so on. For instance, under Windows on Japanese keyboards, Capslock apparently switches from Latin to Japanese? They then use "shift+capslock" to do actual normal Latin capslock (which, again, is a combo that we do not currently intercept either, and could result in the same behaviour we're trying to disable in this thread).
I wouldn't be surprised if there are similar concepts on Chinese and Korean and other keyboards, but they're likely all a bit different due to the linguistic requirements.
(Part of this issue is also what parts of input are done with a given OS's low-level hardware key-scan up/down system versus a UTF-8 input system, and how those respective APIs work on the given OS. For instance, iOS infamously does not have a key-scan API at all and just sends "characters". Anyway, I don't currently recollect the specifics across all the different platforms, but I'm sure we can figure something out to address the overall goals of this thread).
Professionals still get to use capslock to flip their bindings.
Well.. if we disable capslock from being capslock (as mentioned back in #1), then it will no longer function as capslock. So, no, you will not be using it to flip any bindings.
Unless you're asking also for the ability to "unbind the null" and return it to the current default state, and basically saying that experienced users can choose to unbind that?
To be clearer.. the "flipping" is happening because of your particular hardware and OS. The fact that we currently do not mess with capslock is the intended behaviour. As far as I'm aware (?), we aren't doing anything to it at all.
1. Treat capslock like any other key.
I'm guessing what you mean by this is "disable capslock from actually being capslock". I don't know what other games are doing. If it isn't "capslock" by default then.. what is it? My suggestion was to make it some kind of "null" binding that would basically disable the key entirely (although this may be problematic in other regions, as noted later).
I haven't checked on this, but as far as I'm aware you can already bind capslock to be something else? We just don't do that by default. So the "and capslock is just another key you can use" thing should already exist.
2. Where possible, bind by default Shift+Key onto the same as the according Key (e.g. have Shift+W be just like W, which is go forwards).
So, I guess the question here is.. to what extent should we be doing this? "WASD" and "wasd" is easy enough, but beyond that?
Also, while I don't think (?) it'll matter for "game control" cases (where flight controls are active), it is notable that not all keyboards and character input locales have the same concepts for "shift" and "capslock" and so on. For instance, under Windows on Japanese keyboards, Capslock apparently switches from Latin to Japanese? They then use "shift+capslock" to do actual normal Latin capslock (which, again, is a combo that we do not currently intercept either, and could result in the same behaviour we're trying to disable in this thread).
I wouldn't be surprised if there are similar concepts on Chinese and Korean and other keyboards, but they're likely all a bit different due to the linguistic requirements.
(Part of this issue is also what parts of input are done with a given OS's low-level hardware key-scan up/down system versus a UTF-8 input system, and how those respective APIs work on the given OS. For instance, iOS infamously does not have a key-scan API at all and just sends "characters". Anyway, I don't currently recollect the specifics across all the different platforms, but I'm sure we can figure something out to address the overall goals of this thread).
Professionals still get to use capslock to flip their bindings.
Well.. if we disable capslock from being capslock (as mentioned back in #1), then it will no longer function as capslock. So, no, you will not be using it to flip any bindings.
Unless you're asking also for the ability to "unbind the null" and return it to the current default state, and basically saying that experienced users can choose to unbind that?
What about adding a toggle to the control editing interface where, when 'on', any bind to a letter key will automatically also bind to its uppercase companion, if applicable? Would that be simpler, while achieving the same requested result?