* 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
Good luck to whoever wants to deal with the raw texture numbers in
that Liminal Landscape HUD hook that changes sidedef textures
(I had no idea that was even possible...)
Many new options have been added.
You can now specify "menucolor" when creating a gametype. This accepts a V_ colorchar flag (IE V_PURPLEMAP) and will be used to color hud elements in menus and on the HUD.
Encore is now controlled by GTR_ENCORE. This allows for custom modes that don't accept encore.
Itemodds are now controlled by GTR_RACEODDS and GTR_BATTLEODDS respectively. If neither is specified on gametype creation, completely random items will be rolled.
General GTR_FREEROAM adjustments
