* Previous control checking flow:
* Current controller/keyboard (userbound controls).
* If on a menu:
* Current controller/keyboard (default controls).
* All controllers not in use by a player (default controls).
* New control checking flow:
* Current controller/keyboard (userbound controls).
* If player 0 and just checked a controller, check keyboard (userbound controls).
* If on a menu:
* Check all controllers not in use by a player (userbound controls).
* If keys are inaccessible/unbound and keybind is necessary to navigate menus, repeat eveyrhting with default controls.
* Instead of duplicated code, control the flow in a finer fashion.
* Now able to detect if gamepad inputs are possible to recieve (via checking deviceID), instead of assuming they are.
* If a keybind is set but inaccessible by the above metric, make it flash on the Profile Controls screen.
* Fix out-of-order key mappings for a given bind being invisible on the Profile Controls menu.
For some reason gamepads have not been registering buttons for a while, which makes this pretty hard to continue. Not sure if it's to do with how the menu cmd is generated, or something deeper in the SDL code.
Ultra mega hacked in, by saving all "discarded" joysticks to an array so they don't get totally closed & we can still poll them. Events now properly send the device number instead of the player number, which means we can store all controllers pressing buttons, and thus, can detect when ANY controller is pressing anything, and THUS we can make the character select work like we wanted to :V
Did not bother fixing any of the bugs, however. First of all, the opening menus do not properly fallback to default controls. Yet again, we may need a more robust system -- storing all keys from gamekeydown separately? Additionally it seems like when I input gamepad it makes me use keyboard anyway, so I think something fishy is up.
(G: finally, a commit that mostly survived... deviceResponding is useless
for us right now but might as well keep it. maybe easier assignment on
the multiplayer setup menu in the future?)
More or less a port with gamecontrols left untouched.
Some notable differences:
* ev_joystick now has a separate data1 for each axis, rather than having you
check which of data2/3 is INT32_MAX and which one isn't
(pissed me off when updating menu code...)
* Gutted the 1.6 upgrade code, since we're not upgrading from anything :P
* G_GetControlForKey, a helper for menu code
* Turn smoothing code left unused as a reminder to fix it
* Various small fixes so this commit is playable and doesn't segfault
Menu changes:
* Max 4 binds, joystick axes are now bindable like any other button
* The gamepad options submenu has been replaced by its two remaining options
after the removal of axis cvars (gamepad select and deadzone)
See cd8862f0's message for more details
(Huge change: NO_MIDI is now a define, simply because that makes it easier for me to resolve merge conflicts if I can see the original code and the new code. Also means that people who REALLY miss MIDI can compile & fix it themselves :P)
You can now remap Change Viewpoint, Screenshot, and Toggle GIF Recording to other keys, mainly for gamepads
They also pushed me to my breaking point and I couldn't tolerate the control menu anymore, thanks to toaster for the scrolling backport
No more weapon number buttons, button constants reordered, and BT_JUMP
renamed to BT_DRIFT, and removed a lot of commented out stuff or stuff
we didn't need. Spectator-only support for looking up/down soon.
Keyboard defaults are just what I use, plan on adjusting it further
after more feedback
