-
Notifications
You must be signed in to change notification settings - Fork 615
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SDL - There is no reason to know if shift is down when pressing a numpad key with NumLock ON #1118
Comments
mandaxyzw
changed the title
SDL - There is no reason to know if shift is down when pressing a numpad key
SDL - There is no reason to know if shift is down when pressing a numpad key with NumLock is ON
Apr 28, 2022
mandaxyzw
changed the title
SDL - There is no reason to know if shift is down when pressing a numpad key with NumLock is ON
SDL - There is no reason to know if shift is down when pressing a numpad key with NumLock ON
Apr 28, 2022
Code block doesn't exist within OpenJK |
This sounds like an issue with SDL to me? I'd suggest submitting an issue to the SDL library instead |
Pretty sure we made the NumLock to behave like the vanilla game in terms of how the key works though compared to say ioquake3 behavior. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Operating system and version:
Windows 10 Pro 64-bit (10.0, Build 18363)
Description of the bug (and if possible, steps to reproduce the bug):
What did you expect to happen instead?
I want to get the input [End] for [1], [↓] for [2], [PgDn] for [3], etc. but I can't because there is no reason to know if the shift is down with NumLock ON because as I explain above, the value of 'shift' is always 0 at the time when the numpad keys are down, but 'shift' will be 1 at the time when the numpad keys are up.
The text was updated successfully, but these errors were encountered: