|
Title: buggy numpad input Post by: Fuddl on June 28, 2007, 03:41:29 PM hi,
i received a bug report from a debian user, who wrote, the keyboard input by the numpad appears to be buggy. i followed his instructions how to reproduce the bug and could reproduce it on my machines. here's the user's hint how to reproduce: --- [ snip ] --- 1) Make sure numlock is on 2) Start open arena 3) Select multiplayer 4) Select "Local" game 5) Select specify (at bottom of screen) 6) Start typing something like "192.168.0.1", using the 10-key keypad --- [ snap ] --- for the full text of the bug report, see http://bugs.debian.org/430617 cheers - fuddl Title: Re: buggy numpad input Post by: dmn_clown on June 28, 2007, 05:21:03 PM Has any ioquake3 game worked with the numpad?
Tremulous, WoP, Q3:A, and Q3:TA all have the same behavior. Title: Re: buggy numpad input Post by: baconfish on June 29, 2007, 06:12:01 AM I've also experienced that with the original Quake 3, Return to Castle Wolfenstein, and Jedi Knight II. I'm thinking it's just a Quake engine thing! If it's a bug, I can't see how they could've missed it... but it sure isn't much of a "feature".
MYSTERY! Title: Re: buggy numpad input Post by: sago007 on June 29, 2007, 07:31:25 AM I havn't tested it under Windows, but it is an engine bug.
I looked in the code and believe the bug is in "sdl_glimp.c". It ignores numlock and consider it all ways off. The windows version does not use SDL, so I guess it isn't there. However it is common for games to ignore the state of Numlock and Capslock to prevent the controls suddenly changing in-game (the way SDL is implemented actually expects it). So the solution is not quite obvious: Should we check for Numlock? Should we let it be? Or should it consider numlock always on? After looking a little, I believe that the last solution is less likely to create new and more severe bugs. It is also the solution that I prefer. Title: Re: buggy numpad input Post by: dmn_clown on June 29, 2007, 07:10:27 PM I looked in the code and believe the bug is in "sdl_glimp.c". It ignores numlock and consider it all ways off. The windows version does not use SDL, so I guess it isn't there. So the solution is not quite obvious: Should we check for Numlock? Should we let it be? Or should it consider numlock always on? After looking a little, I believe that the last solution is less likely to create new and more severe bugs. It is also the solution that I prefer. RTCW, Q3A (with iD's binary), and JK II didn't use SDL and have similar behavior which kinda throws your theory out the window. Nice try though. The behavior is just in q3 engine games, quake 2 works fine, but then the keycodes for the numpad are actually defined in src/kys.c: Code: void Key_Console (int key) { switch ( key ) { case K_KP_SLASH: key = '/'; break; case K_KP_MINUS: key = '-'; break; case K_KP_PLUS: key = '+'; break; case K_KP_HOME: key = '7'; break; case K_KP_UPARROW: key = '8'; break; case K_KP_PGUP: key = '9'; break; case K_KP_LEFTARROW: key = '4'; break; case K_KP_5: key = '5'; break; case K_KP_RIGHTARROW: key = '6'; break; case K_KP_END: key = '1'; break; case K_KP_DOWNARROW: key = '2'; break; case K_KP_PGDN: key = '3'; break; case K_KP_INS: key = '0'; break; case K_KP_DEL: key = '.'; break; default: break; } You could try inserting the above code somewhere in client/cl_keys.c to see if that fixes the issue, but then people probably won't be able to control the game with the numpad. Aside: Doom 3 has the same behavior, but not quake 4. Title: Re: buggy numpad input Post by: sago007 on June 30, 2007, 04:41:04 AM Your right. It means that "sdl_glimp.c" is implemented to have the same bug as the old code, because the cl_keys does not allow the correct behavior.
That is a shame as it was the easiest place to actually see the value of numlock. Title: Re: buggy numpad input Post by: dmn_clown on June 30, 2007, 05:02:42 AM I'm not so sure that it is a bug but a design decision of Carmack. If you read the config files included in pak0 of q3a a lot of the configs use the numpad for movement and other things...
IDK, its one of those iD things... |