FTEQW Multiple Keyboard/Mouse support

[Baker]

Just stuffing this info here, it relates the ability of FTEQW to do split screen multi-player on the same machine.

What I think is the most remarkable about this is the fact that FTEQW can support multiple keyboards and mice.

you need to fiddle around with a few cvars to get it to work.
cl_splitscreen 1 to 3 (the number of extra players to use)
allow_splitscreen 1 (on the server, requires an FTE server, by the way)
in_rawinput 1 (highly recommended, reasoning below)
in_rawinput_keyboard 1 (highly recommended, reasoning below)

more recent builds automatically ignore allow_splitscreen for local clients, so it works in 'single' player by just setting the cl_splitscreen cvar, which now appears in the menus.
Note that you need to reconnect to the server or so, you can't just change map.

in_rawinput is a windows-only cvar which changes the input method to something supported on winxp upwards. dinput was originally meant to report which device was giving your input, but this works only for joysticks. rawinput actually allows the engine to know *which* mouse or keyboard reported the key press.
with that, the engine is able to figure out which input device and thus which keyboard to use for each player (each is numbered, and the player it controls is dev%numsplits).

[Spike]

if you looked at the code, your surprise would go away. :P

Every Key_Event call carries an index saying which input device it came from. Key_Event then adds a command prefix into the console command which is executed.
This prefixed command just sets some global then calls the command as normal (unsetting after).
This means that every command works with minimal changes.
However, it also means that the engine still only supports a single set of bindings. The only thing that is done is the extra global saying which device, thus which player, is the one that triggered the console command.
I've no idea what happens with big long aliases.

RawInput (and DirectInput on winxp) do provide functionality to read the device index that the event is reported on, so really there's no barrier to it, other than (ab)use of globals that may be in any quake-derived engine...
An older incarnation actually included code to read mouse commands directly from serial ports for the second+ player. But windows made that one a real real real pain to use (due to using its own driver, blocking the serial port until next reboot, then not distinguishing between mouse devices).

Joysticks have always been individually queryable, but rarely used in FPS games, at least on PC where people enjoy touching rodents instead. Plus I don't have one, so can't test it anyway.

You could combine it with bindmaps or something weird like that so you can give different keyboards/mice different binds, but that's awkward to explain to the user, and a pain to configure as far as the user is concerned, so support is likely overrated.

Either way, separating input devices typically requires rawinput, available only in xp upwards. dos versions of quake would easily be able to distinguish between serial ports and ps2 ports... But distinguishing usb mice from ps2 mice would require writing a usb hci driver or 3, as well as the actual mouse driver. Not unheard of, but its a few lines of code, and naturally wouldn't work in windows.

[Baker]

if you looked at the code, your surprise would go away.

Haven't looked yet. I just perpetually find it amazing all the theoretical odds and ends that FTEQW supports.

[Spike]

kinda vital to have a mouse to play quake, even splitscreen.

seriously, I wanna see you play properly using just a quater of a keyboard! :P

its a very very practical feature if you're using splitscreen.
note that every engine supports multiple mice/keyboards for the simple reason that windows does.
The only twist here is that FTE tracks which device it is, and uses that for the right splitscreen player. If you're not using splitscreen then it makes no difference.

Sadly I have yet to find any technical specifications of any hot bevarage dispensor yet, and am unable to provide any support for such devices.

Besides, adding support for stuff is fun. Kinda.