we need an MacOS version of QSS!!! :-) 

And FINALLY fixed a couple of bugs in qss-r7, so quoth shouldn't bug out any more (is the theory)

That's cool, but were we doing something especially weird or dodgy that provoked this? Like the ultra-high fps "bug" that keeps being reinvented, if it happened to your engine it might happen to others, and I'd like to programme defensively if so. 

sorry, I should have phrased that better. That bug was totally my fault, and it happened on more maps than just quoth's ones.

(I was trying to be clever by auto-precaching any model named by a model field, so that mappers could do interesting hacky things. the real issue being that I got the code wrong and the server ended up reading random tempstrings instead.
Even without that it would have broken saved games though, so now you need '_precache_model' instead, or alternatively you can set modelindex to a non-numeric value, which might be useful if you're trying to bypass the lack of a setmodel. its nice to have options, or something) 

https://i.imgur.com/Ye09ueS.jpg

WTF?! :) Sometimes (often) last Vore teleports in the player at the end titles. I don't remember this bug in original game. 

You've probably just got faster at completing the level, and leave a vore alive more often. The teleporter at the end isn't flagged "player only" so if the vore's alive on the final ledge then it can walk towards the camera and hit the tele. 

Before I overwrite I'd like to know ;)

Thanks in advance. 

I think qss-r7 is older and lacks some fixes needed to run ad_sepulcher.
btw QSS homepage is http://triptohell.info/moodles/qss/ and there is an r8+ released recently. 

Thanks. 

I quicky tried it yesterday and AD Sepulcher seem to run as good as with the ADMod version of QSS. Unfortunately no chance at the moment for a deeper test session.
Only thing that is missing is the possibility to select the mod to play directly in game main menu. 

I haven't been able to play QS in a while. I play with a controller but it seems that movement is more twitchy than it used to be.

Of course, Windows 10 has updated a million times since I last played which broke my controller until I updated its drivers - SCPToolkit. Thus, I'm not sure if the change is in the drivers or Quakespasm...

Just so you know, behaviour hasn't changed in any other game. :) 

The only default that has changed since June 2016 is L/R trigger deadzone, because the shoot/jump keys were getting stuck sometimes.

Maybe try deleting the joy_* cvars from you config.cfg's in case they got changed at some point.
Here's the manual section on the controller cvars if you need to tweak them:
http://quakespasm.sourceforge.net/Quakespasm.html#ss3.2 

Any idea why SDL 1.2 and SDL 2 treat mouse buttons differently? Between the two versions my mouses thumb buttons are 4 & 5 in SDL2, but 8 and 9 in SDL1.2.

Not a big issue, it just means another rebind, was just curious about the logic. (am using linux btw) 

Thanks for the reply, Eric. I tried your suggestion but to no avail. That put Quakespasm being the issue to bed. I uninstalled SCPToolkit, installed DS4Windows and all is back to normal.

Again, thanks for your help. :) 

Sorry to harp on about controller stuff, Eric, but I have a request if it's possible.

Though there is change in player movement speed depending on how far one pushes the left analogue stick it would be nice if there was more nuance to it.

I don't know the technical term for it but I feel the movement should ramp up smoother across a greater range of the stick. Right now, it's a little twitchy for precision jumping and the like.

The right stick for looking is great though.

A slider in the menu would be perfect but even a CVAR (or is there already one that I've missed?!) would be nice.

Hope you're having a lovely Christmas. :) 

Hmm.. it looks like the only cvar for controlling the movement stick is "joy_exponent", default 3. But, that also affects the look stick as well.

Try lowering it to 2 or 1. 1 will give you linear mapping from stick travel to movement speed.

I can probably split this into 2 cvars if it turns out you need different values for the move and look sticks. There is no menu page for any of this, would be a good idea probably.
Thanks and merry Christmas as well! 

Setting the joy_exponent to 1 made a big difference to movement. However, like you suspected the effect is too heavy handed for looking. Would it be possible to split it into 2 CVARS?

I reckon setting them to 1 and 3 would be pretty perfect in terms of map navigation and aiming. At least, for me.

Also, I just want to say thank you for always responding in an interested and polite manner. I can't tell you how refreshing it is not having a dev respond with eye rolling or "code it yourself, noob". I enjoy playing another old FPS and I dread asking questions about that source port. Again, thanks for allowing me the space to 'just' be a player and not a mapper, modder or coder. :) 

Hey guys, thanks for the great work you're doing.

I tried running heavy mods like AD with Quakespasm, experienced not-so-high-fps. Which features can I disable (or use some commands) for any fps boost? 

• Reduce video resolution
• Play on a computer made after the year 2010. 

Be aware that the physics breaks above 72 fps. So if your standard is ultra-smooth 144 fps you're going to be disappointed. 

Can't find the tools thread (I suck) ... didn't want to kill joy in a new release thread.

"Fix MarkV .lit rendering (do the color->greyscale conversion in a way that forces MarkV, FTEQW to render identically to Fitzquake, Quakespasm) "

That's is completely inaccurate description. The external .lit file is just covering up the evidence.

If you would load a map that suffers the issue in GLQuake or WinQuake it would look all wrong too, so there was a majorly serious issue there with the .bsp having lit data that didn't resemble the data in the external .lit file.

I am hoping you already know this and expect you do.

Back a few years ago when Spike explained the rationale behind FTEQW's .lit method, the logical was so sound and impactful that it was clear it was the "right" way to do things.

Posted here so I don't killjoy your release thread.

Pritchard should get beta tester MVP trophy. 

What, for noticing that the lighting was buggered?

I don't know what the best solution is for .lit compatibility is but it might still be this one - having maps look different in different engines sucks so being able to make everything look the same is very valuable. It would be a lot harder to coordinate this between each individual engine I imagine... 

In AD you can try disabling the custom particle system. QS doesn't sort or batch sprites so this can be still a bottleneck.

IIRC there's an impulse command for it docemented in one of the readmes.

Be aware that at some point in the future a version of QS might exist that does batch sprites, so this bottleneck might go away and "disable particles for higher performance" would no longer be good advice. 

Can't one set vid_refreshrate "144" and host_maxfps "72" for a smooth frame rate without tearing and breaking the games physics? I thought that's what these CVARS were for... I could be wrong, though, as I'm pretty ignorant to most settings for Quake! 

Interesting comparison of model light levels across WinQuake, QS and FTE:

http://www.celephais.net/board/view_thread.php?id=61351&start=121 

Nice port, I'm really sorry that my first post is gonna be a bug report. Previous Weapon doesn't seem to work, no matter what I assign to it. Next Weapon does work though. Also, when assigning a key to an action (when the equals sign appears) moving the mouse acts as if using it to point (as in moving the camera). Besides that, it's a great port, really faithfull to GLQuake.