Bug #317

Undesired CAPS_LOCK behavior

Added by Das_Fleisch over 6 years ago. Updated about 6 years ago.

Status:Fixed% Done:

100%

Priority:NormalSpent time:-
Assignee:-
Category:Client
Target version:2.71rc2
OS: Arch:

Description

Since CAPS_LOCK is right next to the WASD-keys, I like to bind it to a "weapon"-key (instead of the number keys).

This works, but it only works every second time I hit the key (it works when "activating CAPS_LOCK", but it doesn’t work when "deactivating CAPS_LOCK").

It should work every time the key is pressed, like the original ET client.


Related issues

Related to ET: Legacy Development - Bug #23: Movement slowed down after HW usage Fixed 15.03.2012
Related to ET: Legacy Development - Bug #111: Numeric pad not properly recognized / AZERTY keyboard issues Fixed 11.11.2012

Associated revisions

Revision 0b8a9e0e
Added by IR4T4 about 6 years ago

client: fix for undesired and annoying CAPS_LOCK behavior fixes #317

History

#1 Updated by IR4T4 over 6 years ago

  • Category set to Client
  • Target version set to 2.71rc2

#2 Updated by IR4T4 over 6 years ago

Please tell us your OS an your bind cmd.

#3 Updated by IR4T4 over 6 years ago

  • Status changed from New to Feedback

#4 Updated by Das_Fleisch over 6 years ago

Windows 7 SP1 (amd64)

I used the keymap dialog, clicked on the button I wanted to change, then hit CAPSLOCK.

etconfig.cfg
————
bind CAPSLOCK "weaponbank 5"

#5 Updated by IR4T4 over 6 years ago

  • Status changed from Feedback to New

#6 Updated by IR4T4 about 6 years ago

  • % Done changed from 0 to 20

We have to change the standard keyboard CAPSLOCK behaviour to ignore the keystate (up/down) when used as control key.

#7 Updated by IR4T4 about 6 years ago

  • Status changed from New to Fixed
  • % Done changed from 20 to 100

Also available in: Atom PDF