Allow each player to open a menu separately ingame

[GoogleCodeExporter]

Having Key_GetCatcher separate for each local client would be useful if each 
local client could open menu in game separately. Though this would mean the 
menu could only use the players control binds, so not useful for chat or 
setting their name. Might be useful for team and player model select.

Original issue reported on code.google.com by ZTurtleMan on 22 Mar 2012 at 5:55

[GoogleCodeExporter]

Having Key_GetCatcher separate for each player doesn't really make sense, no 
good way to even tell who the key "belongs" to. Need to think of another way.

Maybe add a new trap call to allow cgame to read bind commands and choose 
whether client execute them. So cgame could see key bound to "+2forward" was 
pressed and choose to move menu selection up, then tell client not to execute 
command.

Original comment by ZTurtleMan on 6 Nov 2012 at 2:50

• Changed title: Allow each player to open a menu separately ingame
• Added labels: Priority-Low
• Removed labels: Priority-Medium

[rawr51919]

This doesn't seem to really be feasible or fair to the players because P2 could be off at the controls menu, & P1, a bot, etc. could've already fragged him by the time he unpauses. @zturtleman, go ahead and close this.

[zturtleman]

The ideal situation for separate menus is using game controllers. Spearmint has joystick mappings (based on SDL2) so in menu we know exactly what was pressed. There are absolutely no issues for game controllers.

Keyboard is probably kind of messy and confusing from a user point of view. But it is feasible at a technical level. Spearmint CGame does all of the bind parsing and executing. It's possible to make it so that when a player has a menu open the bound commands will navigate the menu instead of being executed. So WASD +forward/+moveleft/+back/+moveright, Jump +moveup, Crouch +movedown could be used to navigate menu.

"It's not fair". Neither is vanilla Q3 multiplayer.