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. 

http://quaketastic.com/files/misc/touchlinks-test.zip

The player spawns over 4 nailguns. The nailgun touch function calls setorigin() to move all 4 nailguns to the other side of the map (into another areanode).

The map freezes immediately in fitz085, MarkV, QS, and works in QSS and DarkPlaces 

Indeed it freezes immediately. (Linux note: test this with -nomouse on the cmdline.) It doesn't even hit the NULL link error. 

the only way I can see that QC would observe Spike's version being different is if a touch function teleports something into areanode that is currently being visited by SV_TouchLinks.

e.g. player touches a lightning gun. the touch function teleports (with setorigin) a nailgun (from a different areanode) onto the same position as the lightning gun.

With the vanilla code, the nailgun touch function could run during the same SV_TouchLinks call.
With the fixed code, the newly teleported nailgun wouldn't have its touch function run until later (next frame in this case, when the player entity is relinked.)

This wouldn't be observable with id1 since trigger_teleport is delayed 200ms.