even with the QS volume sliders at max, the music is lowered by 6dB (and the mixed sfx are as well) in the mixer code. I did this because the engine is outputting 16bit/44kHz to the OS, which you really don't want to have clipping in, and the mixed SFX can get really really loud (and the music has loud sections too).

This could probably be tuned a bit better.. for the time being QS just needs the system volume turned up a little.

kaffikopp, agreed would be nice, i'll look into it some time. 

Thanks yeah, best to not clip. Understood. I will remix my sfx and music tonight and try and get the dynamics raised a bit. Not a deal breaker they were just low for my taste. Good to know I am not going nuts. :) 

considering windows' audio mixer will convert stuff to floating-point anyway (hurrah for sse), engines might as well just use floats too, and by doing so skip all the clamping - windows will be doing that anyway (at least vista+ anyway).
if windows clamps the audio much, then it'll just automatically reduce the volume or something until it stops clamping so much. I assume the other audio apis will do something similar. 

I use the left trigger for jumping and the right trigger for shooting. Sometimes the buttons act like they're 'stuck'. When shooting, the gun keeps firing when I take my finger off the trigger only stopping when I push it again. When jumping in liquids (and only when jumping in liquids) the same thing happens.

This only happens occasionally and I can't deliberately reproduce it. It seems to be random.

I don't think it's my controller as I have no problems with any other game. Looking at the settings in windows all axis controls (triggers and sticks) centre perfectly.

Anyway, thought I should report it. :) 

and it's the analog triggers that do that?
Thanks for the report, will take a look at how that could happen. 

bind MOUSE1 "-attack; wait; +attack"

Substituting MOUSE1 as appropriate.

This won't solve the problem, but the symptoms of the problem will go away. If it acts up, you can just shoot again like normal. 

Hm, I bet the default for joy_deadzone_trigger is too low; it is currently 0.001. That's a fraction between 0 and 1, so if you set it to 0.5, it generates key press/releases when the trigger is 50% pressed. Maybe try raising it a bit e.g. to 0.01 or 0.1. 

I'm actually using a DS4 with DS4Windows. As far as I know that software fools Windows into thinking it's a 360 controller (ie/ totally transparent).

I've changed the trigger deadzone. So far, I've only had the issue once and only when jumping in liquid. I'll keep tweaking and let you know if there's any difference.

@Baker: Thanks for the suggestion. If the issue persists, I'll give it a try. I'd just rather try to isolate the issue first. :) 

I have all sorts of controllers, if you ever need them testing in a build I have 'em. From 360 pads, to xbone pads, ps3 pads and ps4 pads. 

So, I bumped up the deadzone all the way to 0.5. I haven't had the issue at all so far and with no ill side effects. It does seem the deadzone was a little tight before. Thanks for the help.

Like FE above, I have lots of controllers that I could dig out for testing purposes if you ever need anything checked in the future. :) 

I raised the default to 0.2. Thanks for the testing offers :) afaik this is the only controller thing that changed since the last release. 

Hey. I'm now using r1435. I was playing Quake fine at fullscreen 720x480. Have been since I 'fixed' the issue mentioned above. I loaded up Hipnotic and, "BAM!", the screen was back to 1080.

I looked in the config and sure enough it had changed to vid_desktopfullscreen "1" again.

I redownloaded r1435, made a new folder on my desktop, deleted all config files from Id1, Rogue and Hipnotic so as to generate new ones.

No joy. I ran the game, it was windowed at 720x480, I switched to fullscreen in the menu, the game ran fine. I quit. When I checked the config it was back to "1" again.

Don't know what to do. Fresh install, no config files and only the official PAK files in Id1, Hipnotic and Rogue... 

I reproduce the bug, should be a straightforward fix. In the meantime 0.92.1 should not have this bug: (though this is last fall's release) http://quakespasm.sourceforge.net/download.htm 

Thanks. At least I'm not going mad! In the meantime, I'll use 92.1 as you suggest and keep an eye open for a new nightly.

Thanks again, it really was driving me crazy. :) 

 

Well, it's nearly 3:00am so I think I should probably go to bed for work tomorrow!

Anyway, so far, I've played around with lots of maps and mods and all seems well now.

Thanks for jumping on that so quickly. I can sleep easy now. :) 

So there is something i'm not sure about. Player is sliding on slightly rotated horizontal brush faces. Is this intended? There is nothing like that in Half-Life, but i don't know how it was in original. 

in vanilla NQ, you will slowly slide down slopes, even if they're fairly shallow.
in QuakeWorld (and derivatives), you won't (until they're 45ish degrees).

so for quakespasm its 'working as intended', and mods like Slide (although possibly only that one) would break if it was any different.

if you need a workaround then you can just build some steps from clip brushes around your slopey stuff. That'll give the player physics some nice flat surfaces to walk along.
alternatively, turn it into a trap that has the player needing to stay relatively still in a field of crushers and lava pits and only slopes! 

Please note I was using my irc-modified version of quakespasm (latest version) and a modified progs.dat. I can supply both of these if necessary.

In e1m6 my game crashed with the following error:
"SV_TouchLinks: encountered NULL link!"

It wasn't a friendly crash either, it actually froze the game and wouldn't relinquish control back to the window manager (I'm running linux).

Can you guys think of any reason (aside from my modifications) why this might occur, I wasn't able to replicate the crash. 

One of remove(eg: killtarget), setorigin, setsize, setmodel, walkmove, movetogoal, droptofloor called inside a trigger's touch event can cause such crashes.
This is why the vanilla QC code used SUB_Remove all over the place (except for killtargets, unfortunately).

The exact ordering requires two triggers near each other. If the first trigger removes the second trigger in its touch function then the engine will end up walking that removed second trigger's links. QuakeSpasm has some code to try to heal this, but it can't cope with recursion. Replicating it requires quite a few things to become ordered in an exact way (which may even have framerate dependencies).
I've no idea what could cause such recursion in vanilla quake, but to be fair you're using a modified progs.dat, so maybe its something in there.

QSS/FTE/DP have code that can handle recursion etc, so they'll never give the crash you got no matter how exotic you make it.
QS should be okay for most of those functions, but can have issues if you're using movetogoal or walkmove inside touch functions.
Vanilla can and does explode if ANY of those functions are called inside a trigger's touch function. Like I say, order matters. You may feel you've gotten away with it, at least until they're things are triggered in some other order, or a dropped backpack might be enough to prevent the bug or be the difference between an infinite loop and a segfault. 

Where is that modified progs.dat? 

https://www.dropbox.com/s/j6fuwscy5ja7vq8/pacifist_practice_progs.zip?dl=0

I think the only changes I made were in combat.qc 

exactly what do I do to trigger the issue? 

Be on the start platform on e1m6
I think I had a quicksave beforehand.

I wasn't able to replicate it.

It just died with that error. 

Well, I can't reproduce it either. We'll need to reproduce it reliably in order to find a solution.