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?
"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)."
PLEASE NO! At the very least, do not force this "feature" and make it optional. I am running out of keyboard capacity, even with the use of capital letters. Removing 26 perfectly bindable keys is not the way to go.
PLEASE NO! At the very least, do not force this "feature" and make it optional. I am running out of keyboard capacity, even with the use of capital letters. Removing 26 perfectly bindable keys is not the way to go.
+1 to Infinitis
Generally what we're discussing here are "new defaults", ie for new users and fresh installs.
I have no intention of preventing players from binding whatever button they want to whatever function they want. We've always tried to provide lots of user-configurability and that's not likely to change.
Removing 26 perfectly bindable keys is not the way to go.
Well, is changing the default of *four* of them okay? Just W/A/S/D? Or, maybe Q/E/R/F as well?
What about disabling capslock? Does anyone have a problem with that?
Personally, I don't think I've ever used capslock to intentionally type anything since the beginning of home computing. But, I imagine.. someone, somewhere does..?
I have no intention of preventing players from binding whatever button they want to whatever function they want. We've always tried to provide lots of user-configurability and that's not likely to change.
Removing 26 perfectly bindable keys is not the way to go.
Well, is changing the default of *four* of them okay? Just W/A/S/D? Or, maybe Q/E/R/F as well?
What about disabling capslock? Does anyone have a problem with that?
Personally, I don't think I've ever used capslock to intentionally type anything since the beginning of home computing. But, I imagine.. someone, somewhere does..?
The original suggestion stated "where possible," thus 26 keys were mentioned. I don't have an issue with changing the *default* behaviour of 4 keys or removing the Caps Lock key.
I'm not exactly a fan of removing basic functionalities, but I don't really use the key in the game. If it were possible to bind it, which it probably isn't, people who aren't hitting the key accidentally would also bind and use it.
On the other hand, who knows what other people use? For example, I have mapped the numpad so that when I switch it off temporarily, I can use the numeric keys to switch weapon groups. So, the Num Lock key basically switches keyboard overlays. I can imagine such dual functionality being configured on letters with Caps Lock.
As a side note, I do not use WASD for controlling ship movement. It's arrow keys all the way.
All I want to say is that people use key bindings in countless ways.
I'm not exactly a fan of removing basic functionalities, but I don't really use the key in the game. If it were possible to bind it, which it probably isn't, people who aren't hitting the key accidentally would also bind and use it.
On the other hand, who knows what other people use? For example, I have mapped the numpad so that when I switch it off temporarily, I can use the numeric keys to switch weapon groups. So, the Num Lock key basically switches keyboard overlays. I can imagine such dual functionality being configured on letters with Caps Lock.
As a side note, I do not use WASD for controlling ship movement. It's arrow keys all the way.
All I want to say is that people use key bindings in countless ways.
Just change the default configuration to include all the double keys rebound as both upper and lower, like you said. So WASDRFQE + wasdrfqe do the same thing (by default, like you said, I think people missed that).
This way nobody current loses anything (unless they forget to backup their config). I did use capslock to switch keyboard layout a while ago, but even then the movement keys did the same thing in both modes. It was silly, and I don't really use any plugins anymore, and sometimes I forgot to hit caps at the right time anyway so it made chatting and stuff go to the wrong place.
Anyway, it is useful to have in some situations, so please don't disable the capslock key!
You can fix this problem now by yourself btw kritomas12 by double-binding all your movement keys. Just go add all the upper case letters to your movement binds too and the capslock problem goes away but thank you for bringing up this problem :) when I go distro hopping I usually don't bother keeping old game config files and just play with defaults until I inevitably move on, so having to not do this every time myself would rock!
And no Incarnate, you cannot bind capslock to anything in VO (which is normal on Linux and OSX), which you can in other none native Windows titles and "some" linux native games, but they are few and far between in the Linux world. Most use SDL and treat the keyboard like you do, as a keyboard, MAKE CAPSLOCK GRE... erm, i'll see myself out. It also wouldn't break anything in the Windows config file either if it made it easier to just make them both default there too. You can double-bind a key on Windows, it just treats the key as-one unless asked otherwise.
This way nobody current loses anything (unless they forget to backup their config). I did use capslock to switch keyboard layout a while ago, but even then the movement keys did the same thing in both modes. It was silly, and I don't really use any plugins anymore, and sometimes I forgot to hit caps at the right time anyway so it made chatting and stuff go to the wrong place.
Anyway, it is useful to have in some situations, so please don't disable the capslock key!
You can fix this problem now by yourself btw kritomas12 by double-binding all your movement keys. Just go add all the upper case letters to your movement binds too and the capslock problem goes away but thank you for bringing up this problem :) when I go distro hopping I usually don't bother keeping old game config files and just play with defaults until I inevitably move on, so having to not do this every time myself would rock!
And no Incarnate, you cannot bind capslock to anything in VO (which is normal on Linux and OSX), which you can in other none native Windows titles and "some" linux native games, but they are few and far between in the Linux world. Most use SDL and treat the keyboard like you do, as a keyboard, MAKE CAPSLOCK GRE... erm, i'll see myself out. It also wouldn't break anything in the Windows config file either if it made it easier to just make them both default there too. You can double-bind a key on Windows, it just treats the key as-one unless asked otherwise.
And no Incarnate, you cannot bind capslock to anything in VO (which is normal on Linux and OSX), which you can in other none native Windows titles and "some" linux native games, but they are few and far between in the Linux world. Most use SDL and treat the keyboard like you do, as a keyboard
Interesting. Noted. Yeah, it completely depends on which APIs we're using, on which platform. We predate the existence of SDL, so we don't use that (we wrote our own stuff); but I imagine there are low-level enough APIs to force the nullification of capslock. Although at some point that starts to get into app privilege issues and potentially conflicting further with Wayland and other systems.
Anyway, it is useful to have in some situations, so please don't disable the capslock key!
I wasn't intending to permanently disable anything..
It was my hope that we could just default-bind it to some specialized <null> or something (that we would create), which could then be removed by the end-user if they wanted it to behave normally.. or re-bind it to something else. But, this was just a "hope" without research, and I have no idea how involved that is (or how annoying it might be to try and make it consistent across platform APIs).
Interesting. Noted. Yeah, it completely depends on which APIs we're using, on which platform. We predate the existence of SDL, so we don't use that (we wrote our own stuff); but I imagine there are low-level enough APIs to force the nullification of capslock. Although at some point that starts to get into app privilege issues and potentially conflicting further with Wayland and other systems.
Anyway, it is useful to have in some situations, so please don't disable the capslock key!
I wasn't intending to permanently disable anything..
It was my hope that we could just default-bind it to some specialized <null> or something (that we would create), which could then be removed by the end-user if they wanted it to behave normally.. or re-bind it to something else. But, this was just a "hope" without research, and I have no idea how involved that is (or how annoying it might be to try and make it consistent across platform APIs).
"You can fix this problem now by yourself btw kritomas12 by double-binding all your movement keys."
The most important thing, regarding OP's concerns, in this thread.
The most important thing, regarding OP's concerns, in this thread.
I'm partial to adding WASDQERF to the default config, seems like the best solution from where i'm sitting anyway.
It's not just newbs that fall to the inevitable caps lock activation whilst button mashing their way through some explosions!
It's not just newbs that fall to the inevitable caps lock activation whilst button mashing their way through some explosions!
"You can fix this problem now by yourself btw kritomas12 by double-binding all your movement keys."
The most important thing, regarding OP's concerns, in this thread.
This has no value to the OP's concerns, which are about future new players, and not him.
The most important thing, regarding OP's concerns, in this thread.
This has no value to the OP's concerns, which are about future new players, and not him.
> "You can fix this problem now by yourself btw kritomas12 by double-binding all your movement keys."
Yeah, that would have been useful to know... earlier.
Yeah, that would have been useful to know... earlier.
Well kritomas12, personally I'm glad you didn't know earlier. This is something that could cause headaches for new players and not only that but has potential to cause unnecessary time wasted fending off bug reports (at least you knew it was a capslock issue, your post may have been a lot harder to debug if you thought your keyboard was stopping working randomly, but not the cause).
Older players do just deal with this manually, but it would also be easier not to have to. It is an easy fix but it's easy to forget about once sorted, so it could have gone un-talked about for years more if it hadn't have been raised now; and now is a good time for it, what with more people moving away from Windows towards Linux and Mac!
Older players do just deal with this manually, but it would also be easier not to have to. It is an easy fix but it's easy to forget about once sorted, so it could have gone un-talked about for years more if it hadn't have been raised now; and now is a good time for it, what with more people moving away from Windows towards Linux and Mac!
For me with CAPSLOCK ON, the kb print the Capitalize Key, by example A B C D E F ... X Y Z, with CAPSLOCK OFF the kb print a b c d e f ... x y z, and the SHIFT+KEY print the Capitalize Key.
for me:
a = strafe left,
A = capship attack,
Similar use like:
t = general chat
T = sector chat
Reading ntli ... i think the key issue is a operating system thing, i'm using Debian and all is working fine with Vendetta Online.
for me:
a = strafe left,
A = capship attack,
Similar use like:
t = general chat
T = sector chat
Reading ntli ... i think the key issue is a operating system thing, i'm using Debian and all is working fine with Vendetta Online.
I have many keys with dual use ... and not counting the multiclick functions, Hold-a and Hold-A by example
> i think the key issue is a operating system thing, i'm using Debian and all is working fine with Vendetta Online.
Misunderstanding.
All works fine for me too. What I am trying to say here is that this fine behaviour is not very conventional, as far as other games are concerned. New players, most likely coming from other games, will therefore not expect this fine behaviour, making them think that it's not, in fact, fine.
I am proposing to simply make a few changes to make the behaviour more line up with what new players expect, one of which even allows old players to keep the current behaviour.
Misunderstanding.
All works fine for me too. What I am trying to say here is that this fine behaviour is not very conventional, as far as other games are concerned. New players, most likely coming from other games, will therefore not expect this fine behaviour, making them think that it's not, in fact, fine.
I am proposing to simply make a few changes to make the behaviour more line up with what new players expect, one of which even allows old players to keep the current behaviour.
Since not a single person has commented on it this far into the conversation, I'd like to reraise my suggestion. The issue is entirely down to visibility of how binds apply to uppercase versus lowercase on latin keyboards, so a toggle retains existing capability and doesn't interfere with non-latin setups, right?
i'm using latin keyboard, sure i'm not the only one
Luxen: Most none-latin keyboards still work with latin characters and usually have a key to switch typing modes which is interpreted by software, these keyboards work as standard latin keyboard when no such software support is present. Some support more than 3 typing modes and VO or guild could not possibly support them all. This change would have zero effect on these users as they may need to rebind buttons to make sense already. None latin isn't even the only consideration either, there are latin keyboard layouts already that do not conform to using W A S D at all, including AZERTY and Dvorak to name 2.
The double-bind keys (by default) shouldn't really effect none latin keyboards as they usually have a latin mode (which includes both lower and upper case, with an alpha lock key), which mirrors the US International keyboard standard. When it comes to input devices, broad all around keyboard support is practically impossible. Users of them keyboards are usually punished by most western software out there, so are used to having to change a few keys around. Neither suggestion (toggle or double bind) would break anything anymore than it already is for these users.
I'd be all for a toggle, or even better; for VO to work the same on all PC platforms - treat every key as both UNLESS double bound (like Windows) - and while I am sure this is possible, it would be a hell of a lot more work to implement as it would mean re-writing the way VO handles keyboard input. Hence the double-bind suggestion; it may not be perfect as some layouts still won't conform, but it would solve 99.999999% of problems this causes for users, and there is always going to be the 0.000001% that have issues due to localisation. But most none latin locals had this figured out years ago as western software is prevalent.
The double-bind keys (by default) shouldn't really effect none latin keyboards as they usually have a latin mode (which includes both lower and upper case, with an alpha lock key), which mirrors the US International keyboard standard. When it comes to input devices, broad all around keyboard support is practically impossible. Users of them keyboards are usually punished by most western software out there, so are used to having to change a few keys around. Neither suggestion (toggle or double bind) would break anything anymore than it already is for these users.
I'd be all for a toggle, or even better; for VO to work the same on all PC platforms - treat every key as both UNLESS double bound (like Windows) - and while I am sure this is possible, it would be a hell of a lot more work to implement as it would mean re-writing the way VO handles keyboard input. Hence the double-bind suggestion; it may not be perfect as some layouts still won't conform, but it would solve 99.999999% of problems this causes for users, and there is always going to be the 0.000001% that have issues due to localisation. But most none latin locals had this figured out years ago as western software is prevalent.