Forums » Bugs
Capslock doesn't really work
STEPS TO REPRODUCE:
1. Enable Capslock
2. Try to move forwards by pressing W
3. Try to move forwards by pressing Shift+W
OBSERVATION:
The ship only moves forward when pressing Shift+W.
EXPECTATION:
The ship should only move forward when pressing W, regardless of capslock.
ADDITIONAL NOTES:
Asked around ingame, others are having the same issue, so probably not Linux specific.
Fastfetch:
kritomas@KRITOS-LEGION
----------------------
OS: Debian GNU/Linux forky/sid (forky) x86_64
Host: 82NW (Legion 5 15ACH6A)
Kernel: Linux 6.17.13+deb14-amd64
Uptime: 3 hours, 50 mins
Packages: 5031 (dpkg), 18 (flatpak)
Shell: bash 5.3.3
Display (eDP-2): 1920x1080 @ 1.09x in 16", 60 Hz [Built-in]
DE: KDE Plasma 6.5.4
WM: KWin (Wayland)
WM Theme: Breeze
Theme: Breeze (Dark) [Qt], Breeze-Dark [GTK2], Breeze [GTK3/4]
Icons: breeze-dark [Qt], breeze-dark [GTK2/3/4]
Font: Ubuntu (11pt) [Qt], Ubuntu (11pt) [GTK2/3/4]
Cursor: breeze (24px)
Terminal: konsole 25.4.2
CPU: AMD Ryzen 7 5800H (16) @ 4.46 GHz
GPU 1: AMD Radeon RX 6600M [Discrete]
GPU 2: AMD Radeon Vega Series / Radeon Vega Mobile Series [Integrated]
Memory: 6.42 GiB / 13.51 GiB (47%)
Swap: 2.19 GiB / 14.90 GiB (15%)
Disk (/): 100.40 GiB / 139.70 GiB (72%) - btrfs
Disk (/media/localdisk): 631.80 GiB / 776.91 GiB (81%) - btrfs
Local IP (wlp6s0): 10.0.1.37/24
Battery (L20C4PC1): 60% [AC Connected]
Locale: en_GB.UTF-8
1. Enable Capslock
2. Try to move forwards by pressing W
3. Try to move forwards by pressing Shift+W
OBSERVATION:
The ship only moves forward when pressing Shift+W.
EXPECTATION:
The ship should only move forward when pressing W, regardless of capslock.
ADDITIONAL NOTES:
Asked around ingame, others are having the same issue, so probably not Linux specific.
Fastfetch:
kritomas@KRITOS-LEGION
----------------------
OS: Debian GNU/Linux forky/sid (forky) x86_64
Host: 82NW (Legion 5 15ACH6A)
Kernel: Linux 6.17.13+deb14-amd64
Uptime: 3 hours, 50 mins
Packages: 5031 (dpkg), 18 (flatpak)
Shell: bash 5.3.3
Display (eDP-2): 1920x1080 @ 1.09x in 16", 60 Hz [Built-in]
DE: KDE Plasma 6.5.4
WM: KWin (Wayland)
WM Theme: Breeze
Theme: Breeze (Dark) [Qt], Breeze-Dark [GTK2], Breeze [GTK3/4]
Icons: breeze-dark [Qt], breeze-dark [GTK2/3/4]
Font: Ubuntu (11pt) [Qt], Ubuntu (11pt) [GTK2/3/4]
Cursor: breeze (24px)
Terminal: konsole 25.4.2
CPU: AMD Ryzen 7 5800H (16) @ 4.46 GHz
GPU 1: AMD Radeon RX 6600M [Discrete]
GPU 2: AMD Radeon Vega Series / Radeon Vega Mobile Series [Integrated]
Memory: 6.42 GiB / 13.51 GiB (47%)
Swap: 2.19 GiB / 14.90 GiB (15%)
Disk (/): 100.40 GiB / 139.70 GiB (72%) - btrfs
Disk (/media/localdisk): 631.80 GiB / 776.91 GiB (81%) - btrfs
Local IP (wlp6s0): 10.0.1.37/24
Battery (L20C4PC1): 60% [AC Connected]
Locale: en_GB.UTF-8
I'm a little perplexed by this. Maybe I'm misunderstanding something, but..
- The game has controls, which are bound to particular keys.
- Capital and lower-case keys are handled separately, and can do different things.
- The game does not bind "W" by default, it only binds "w".
So, if you create a situation in which you are sending "W" instead of "w", you will not go forward. This is the expected behaviour.
(I would surmise that pressing "shift" while capslock is engaged is basically reversing the capslock status and giving you a lowercase "w", causing the correct key to be triggered).
If you want both "W" and "w" to *both* be bound to +Accelerate, you can either add them in Options, or directly edit the wgaf.cfg.
If you think they should default to both being bound, that's a reasonable subject for a Suggestions thread, but it isn't a Bug..?
I don't see anything here that is not behaving as intended.
- The game has controls, which are bound to particular keys.
- Capital and lower-case keys are handled separately, and can do different things.
- The game does not bind "W" by default, it only binds "w".
So, if you create a situation in which you are sending "W" instead of "w", you will not go forward. This is the expected behaviour.
(I would surmise that pressing "shift" while capslock is engaged is basically reversing the capslock status and giving you a lowercase "w", causing the correct key to be triggered).
If you want both "W" and "w" to *both* be bound to +Accelerate, you can either add them in Options, or directly edit the wgaf.cfg.
If you think they should default to both being bound, that's a reasonable subject for a Suggestions thread, but it isn't a Bug..?
I don't see anything here that is not behaving as intended.
If I bind something onto Shift-W (so uppercase W), I expect it to always be on Shift-W, regardless of what some other key on the keyboard thinks.
I tend to hit capslock accidentally, which isn't a problem in other games (which don't parse capslock at all), but here, the unexpected sticky shift behaviour took me by surprise.
The last thing I want is for my keybinds to require shift all of a sudden in the middle of a battle, because i missed the tab key and hit capslock instead.
I wouldn't treat capslock at all (except for actual text input), or at least bind by defeault all shift combinations for keys that don't have any (like your suggestion suggestion said).
Do keep the separate Key vs Shift-Key binding though. Just don't allow capslock to flip them.
I tend to hit capslock accidentally, which isn't a problem in other games (which don't parse capslock at all), but here, the unexpected sticky shift behaviour took me by surprise.
The last thing I want is for my keybinds to require shift all of a sudden in the middle of a battle, because i missed the tab key and hit capslock instead.
I wouldn't treat capslock at all (except for actual text input), or at least bind by defeault all shift combinations for keys that don't have any (like your suggestion suggestion said).
Do keep the separate Key vs Shift-Key binding though. Just don't allow capslock to flip them.
If I bind something onto Shift-W (so uppercase W), I expect it to always be on Shift-W, regardless of what some other key on the keyboard thinks.
Well.. I mean, that's a function of the hardware and the OS. Your keyboard happens to have a caplock key, and it's not uncommon for it to "reverse" the shift behaviour. But, the game itself isn't doing that; your complaint has nothing to do with the game, or the state of the "bind".
The game function is still bound to the given key-code. You just reconfigured your input device such that you're no longer sending that keycode.
Contrary to the OP subject of the thread (and as far as I can tell from your description).. Capslock is functioning exactly correctly.
Anyway.. sure, I have no problem with default-binding capital "WASD" in addition to "wasd".
We could probably also default-bind "capslock" to some kind of "null" state.
While I understand the UX here might not be ideal (for accidental capslock-hitters), and particularly might not be to your taste, it is not an example of a system working other than intended. Players have been simply "avoiding capslock" for the last quarter-century.
The feedback is appreciated, regardless.
Well.. I mean, that's a function of the hardware and the OS. Your keyboard happens to have a caplock key, and it's not uncommon for it to "reverse" the shift behaviour. But, the game itself isn't doing that; your complaint has nothing to do with the game, or the state of the "bind".
The game function is still bound to the given key-code. You just reconfigured your input device such that you're no longer sending that keycode.
Contrary to the OP subject of the thread (and as far as I can tell from your description).. Capslock is functioning exactly correctly.
Anyway.. sure, I have no problem with default-binding capital "WASD" in addition to "wasd".
We could probably also default-bind "capslock" to some kind of "null" state.
While I understand the UX here might not be ideal (for accidental capslock-hitters), and particularly might not be to your taste, it is not an example of a system working other than intended. Players have been simply "avoiding capslock" for the last quarter-century.
The feedback is appreciated, regardless.
So should I copy this into suggestions, or?
I Posted this here because i genuinely thought it was undesired behaviour.
I Posted this here because i genuinely thought it was undesired behaviour.
No worries, I can move the thread there.
And, you're right, it probably is undesired behaviour from a "user experience" standpoint.
We get a little pedantic about "working as intended" versus "suggestions" simply because.. at some points our community can get pretty intense about discussion topics, and it really helps us to carve things out into two specific groups. Make it easier to manage, when things get chaotic.
Thanks again.
And, you're right, it probably is undesired behaviour from a "user experience" standpoint.
We get a little pedantic about "working as intended" versus "suggestions" simply because.. at some points our community can get pretty intense about discussion topics, and it really helps us to carve things out into two specific groups. Make it easier to manage, when things get chaotic.
Thanks again.
i think it might be better if i copy this, and reformulate it into an actual suggestion.
Okay, that's fine, I've responded over there. Thanks.