I also find console-style controllers much more comfortable than mouse & kb.

Would love 360 controller support in QS. 

I appreciate that the number of people who want to use a controller in QS is probably single-digit.

Legend - have you looked into using some sort of scriptable input emulator? A quick google throws up this: http://andersmalmgren.github.io/FreePIE/ looks like it could be cool if you fancy doing a bit of python. 

but only because I would also love to see split-screen functionality in the game. 

Legend - If you wanna have a look at FreePIE - I found a script for the 360 controller that looks like it could work well.

Note: I haven't tried any of this stuff out yet - but will do as soon as I can.

Also, you can (and should) edit the .py file to change button mappings to what you want.

script here: http://andreasaronsson.com/projects/xboxwasd-in-freepie/ 

There is none currently.. I tried implementing it in QS a while ago; I do have a 360 controller.

What I found frustrating is, the FPS games that have good-feeling controller support (Valve games) are doing some fairly complex easing stuff. Like, if you flick the analog stick all the way to one side, there's a period of time where you turn slowly, then suddenly it accelerates like crazy - so there's some sort of time-based acceleration going on.

I don't actually game with a controller ever, so maybe that stuff is not really desirable, but I'm guessing it is. Anyway I'll try to dust off what I wrote and post a beta here for feedback. 

get that 4 player split-screen support coded in while you're at it ;) 

FTE can do split screen.

http://i.imgur.com/ChTAaTM.jpg 

why are the players christmas lights 

that's cool as hell!

Does it have Pad support though?! 

Didn't make the pic. ;=) 

@fifth -- don't know. If I recall, Spike said it basically needs 2 USB keyboards plugged in. 

@baker
bind w "+p1 forward"
bind uparrow "+p2 forward"
bind lctrl "+p1 attack"
bind rctrl "+p2 attack"
bind 5 "p1 impulse 5"
bind kp_5 "p2 impulse 5"

if you omit the p1 / p2 stuff then yes, the engine uses an internal index of the input device that generated the key events in order to determine which player the event is meant to be controlling.
4-way splitscreen kinda needs a lot of keyboards and binds... you could of course also use csqc for really weird bind setups, which has access to the devid stuff too, but of course this isn't relevant unless you're making a mod.

you don't need two keyboards, just really weird binds.
also, fte is supposed to have support for xinput now, including support for per-player headphones as part of that (I don't actually have one, of course), so that's an alternative way to play splitscreen games.

@kinn
yeah, bloom + fullbrightskins kinda has that effect. quakeworld players might be crazy for wanting fullbright skins, but at least they don't use bloom. only a crazy person would use both at the same time...
also looks like someone disabled rtlight shadows in an attempt to make rtlights look obviously worse than lightmaps. 

what about the direct input joystick support that the original quake had? I know it works with directq and qbism super8. they don't recognize 360/x-input, but work fine with direct input controllers like logitech f310. 

in_xinput 1 //enables xinput for 360 controllers.
joystick 1 //enables the old joy* apis that vanilla winquake used. some of the stuff will have been tweaked over the years, however... you'll probably need the binds menu to figure out which button is which. 

Does FTE splitscreen work with networked multiplayer? IIRC a few years ago it didn't. 

set 'allow_splitscreen 1' on the server if you want cl_splitscreen to work with a separate server (otherwise its only permitted for the local client by default). This setting has existed for as long as fte has had splitscreen support. 

This mean we can create an 8-player game using only two computers, right? 

Imagine a team deathmatch like this. Two teams of four in two computers. 

Of local multiplayer. So it would be awesome 

 

You know when you're noclipping and you hit a brush sloped in a certain way, and it takes control away from you and sends you floating vertically upwards until you exit noclip?

I know it's low priority as it only affects developers/cheaters, but I just wondered if it was an easy fix because when developing I seem to spend a lot of time wrestling with this quirk :( 

Never seen that... noclip always, well, doesn't clip with anything no matter what shape it is.

Is it just because I only make boxes? 

I think that's a trigger_monsterjump and the following tutorial I wrote over 3 years back on Inside3D is all you need: http://forums.insideqc.com/viewtopic.php?f=12&t=4946 

It's when i noclip into brushes that are sloped in two axes maybe??

But - it's definitely world brushes and happens to me constantly. 

That's weird ... I mean, as was said, noclip shouldn't be colliding with anything. At all.