I'd say multiple controller support and splitscreen in a decent engine is more important ;) 

its DP that can run the server on a different thread. the real issue with running the server on a different thread is that of cvars and commands. cvar_set would require a full-blown sync to ensure the other thread isn't reading cvars that are about to go away, while commands also need some sort of sync - which is not what you want with +forward etc.
on the other hand, running the server in an entirely different process skips over ALL of that, with more understandable behaviour for the user. much fewer mutexes, much less likely to break other stuff, but more annoying to configure.

either way your client needs to be able to properly cope with dropped/delayed packets. 

In DirectQ, which had client/server decoupling if you turned left or right using the keyboard while moving forward you had jerky movement, like a mild stutter.

Part of the problem there was that I'd made a huge mess of the timer code well before then. In earlier versions you can timescale down and see how atrociously jerky it really is, and it took me a long time and many revisions to get things back to something that even approached correct. I don't think I was ever 100% successful either, and I didn't really understand the subtleties of the timer code at the time. 

prev weapon bind does not seem to work for some reason. Anyone else getting this? 

Prev weapon is controlled by QuakeC and QuakeC only. Some mods don't support the prev weapon impulse, one example is Duke of Ontranto and I think another example is Castle of Koohoo.

(Mark V uses the Requiem engine cheat to make prev weapon available in about any mod, but it isn't 100% fullproof and at least one mod --- Neruins --- it doesn't work "right" at all) 

I really, really appreciate the Xinput controller support added to recent builds of QS but I was wondering if it would at all be possible to add rumble support?

My first foray into Quake was on the good old N64. Two things I really miss from that version is centred message text (though I don't think you're interested in adding that option) and the other is the Rumble Pak.

It adds some real heft to the weapon fire. 

please... please please please......

(obvs you'd need to have support for more than 1 pad) 

This has come up quite a few times, and I think Spike has given some good discussions on what's involved, but one thing to realise is that this:

(obvs you'd need to have support for more than 1 pad)

Isn't true.

You need a hell of a lot more.

You need to recode the engine to be able to support 2 or more clients, running concurrently, in the same process. 

And considering how there are more global variables in the Quake engine than atoms in our solar system, that is going to be a huuuge, collosal task.

I wonder, if that's the case, if we should consider instead recoding the engine completely, from scratch. And while we're at it, doing away with the hardcoded engine limits. 

Raised limits have long been standardized -- and mostly don't present a problem in modern times.

What Quakespasm uses as limits is essentially the standard. Those limits are ...

1) BSP2 for map limits
2) For non-map limits, the limits are nearly unchanged from FitzQuake 0.85 (with 2 small modifications, if I recall, max packet size and visedicts)

Protocol 666 --- written by metlslime in FitzQuake 0.85 in 2009. Supercedes protocol 15. If there were awards in Quake, metlslime would have won something like "Best Modification of The Decade" or something.

http://celephais.net/fitzquake --- comparing the FitzQuake 0.85 vs. FitzQuake 0.80 source codes.

http://forums.insideqc.com/viewtopic.php?f=12&t=2450 (summary of protocol 666 changes)

BSP2 --- written by MH in 2011 or 2012. Similarly outstanding like protocol 666.

Spike made a BSP2 patch of Mark V, which was used to easily port BSP2 to Quakespasm ...

http://triptohell.info/moodles/junk/markv_bsp2.zip <--- changes for BSP2

... and later probably the basis of BSP2 support in other engines like Super8 and Qrack, if I recall correctly. DarkPlaces and FTE support BSP2 as well. BSP2 was written by mh for the RemakeQuake engine. 

I was able to get prev weap to work with ne_ruins a while ago based on reQuiem. It may require omission of quaketest compatibility or similar to obtain this result. 

The Requiem impulse 12 hack will crash neruins. Give yourself all weapons and ammo, then use impulse 12 a whole bunch. *boom* 

neruins doesn't need a impulse 12 hack. It has impulse 12 support for prev weapon in the progs. Nevertheless, the Requiem impulse 12 hack explodes on neruins. 

ne_ruins is a strange release. It's the only mod that screws with my movement speed settings, maybe except total conversions like Malice.

No, wait, I think I caught OpenQuartz doing something similar. 

try "give all" instead.. maybe this works.. though.. 

What's wrong with cycle reverse in ne_ruins? I always use 1.6 progs which has the reverse cycle function. 

Nothing is wrong with ne_ruins. The Requiem impulse 12 hack has a certain method of trying to determine whether or not a mod supports impulse 12 previous weapon and some it depends on QuakeC function names.

In the case of ne_ruins, it (falsely) concludes that ne_ruins doesn't have impulse 12 support and then does forced progs hacky kung-fu that explodes.

The only thing remarkable about ne_ruins is that it is first known mainstream mod that the impulse 12 hack doesn't play nice with.

Mark V has a cvar named "sv_fix_no_impulse12_exceptions" and the value is "ne_ruins" (supports comma delimited list i.e. "ne_ruins,kinns_new_sp" would work) --- so as you can imagine ne_ruins doesn't crash Mark V any more. 

Noted! 

interesting. maybe because i refactored a lot of the impulse handling and renamed the W_WeaponFrame method to player_processInput?
what do you check for to determine that there isn't support? 

a) It looks for an ImpulseCommands function. If it cannot find one, assumes there is impulse 12 support.

b) Found an ImpulseCommands function. Check for a statement that checks to see if self.impulse == 12. If found one, assumes there is impulse 12 support, otherwise assumes there is not impulse 12 support.

ne_ruins apparently has an ImpulseCommands function but doesn't check for impulse 12 there. 

"sv_fix_no_impulse12_exceptions" drips off the tounge like "r_nolerp_list", but could the approach be a whitelist instead of a blacklist? That is, a list of the old classic maps that need it.

The reQuiem impulse 12 hack is missing a 'default' fall-through during switch. The prev weap crash seems to be solved by coding the default to axe. But now next weap will fail... because it's not really an axe, it's a book or something... 

Well, there have to be a finite number of single player mods without impulse 12 support.

And in theory, if someone had the entire Quaddicted archive, could code an engine to switch gamedir to each gamedir and if impulse 12 support was not detected, write it to a log along with maybe ...

a) the CRC16 (what Quake uses), the filesize in bytes and maybe throw in a MD5 (because GitHub uses MD5 for file comparison and Linus Torvalds seems to how versioning down to a science)
b) and the file date and time from the archive.

1) Koohoo
2) Stuff using CustEnts like about all of Fat Controller's stuff
3) Probably a few random ones where the author could write QuakeC but used a bad progs base

Then you have to determine what dumb progs exist like Quake Progs 1.01 --- or is it 1.02? --- but catch the ones that aren't 1.06.

So yeah, whitelisting would work very well --- eventually. And would be the best solution long term. 

Ok, I see, instead of checking is self.impulse == 12, i assigned self.impulse to a local float _impulse and then check that instead. :(

void() ImpulseCommands =
{
local float _impulse;

_impulse = self.impulse;

if (_impulse >= 1 && _impulse <= 8 || _impulse == 250)
W_ChangeWeapon ();

else if (_impulse == 9)
CheatCommand ();
else if (_impulse == 10)
CycleWeaponCommand ();
else if (_impulse == 11)
ServerflagsCommand ();
else if (_impulse == 12)
CycleWeaponReverseCommand ();
 

Stumbled on a strange glitch while testing a new palette.

http://i.imgur.com/m38oeEe.png

Re-entering the map didn't change anything, but after restarting the game everything was back to normal. Only the torches, flames and hanging zombies seemed to be affected.

The way the zombies looked like random lumps of gore, twitching and extending their "tendrils" in semi-random directions, actually was pretty cool.

http://i.imgur.com/R7zye7B.png

I think it's an interesting idea for a new decoration, or an environmental hazard. Only if properly executed, of course.

Version 0.91.0, non-SDL2. Nothing suspicious in stdout. 

Weird, I haven't seen that since the new mdl renderer was still being ironed out.

If you find a way to reproduce it that would be great, but I assume it's an unlikely combination of conditions to trigger the bug.