There's a comment in the source explaining this removal:

//johnfitz -- removed all gun position fudging code (was used to keep gun from getting covered by sbar)

I believe that Baker's FitzQuake Mark V fork restores that code, but QuakeSpasm doesn't. 

Original gun is available as an option in mark v. Default is still the FitzQuake norm that Quakespasm uses but yeah you can go menu ... preferences ... set gun position to classic. 

I'd like a cvar for that.. we had a patch contributed that enables the classic gun position: https://github.com/bangstk/Quakespasm

It's on my todo list to review and compare to how MarkV implements it. 

You might as well take "fov doesn't affect gun" option too when the time comes. 

Ironically, if I recall, Mark V doesn't have gun fudging code. Original Quake did fudge the gun position. Classic weapon in Mark V calculates the right gun position for the gun to appear on top of the status bar based on FOV and HUD settings and screen aspect ratio. This calculation also has to take into consideration FOVy adjustments for screen aspect ratios.

When you think about the gun fudging code in original Quake, it sounds newbiesauce easy.

But just see what happens when you change the resolution to something with a weird aspect ratio or set an irregularly sized window resolution of 600 x 600 or 400 x 600.

The original weapon position fudging code breaks down terribly in situations deviating far from a 4 x 3 aspect ratio or with enlarging the HUD (hudscale).

(If I recall correctly, it's been a while since I worked on that.) 

Speaking about FOV, I think this option should have a threshold of sorts. Right now it always draws the gun the same, even with a very narrow FOV, which makes zooming very weird. Maybe it should take a value (in degrees) beyond which the gun stops changing. 

Hehe, I noticed that once but thought that I was only the person that actually created such a bind.

You could actually modify your zoom bind.
+zoom "fov 70; r_viewmodel_fov 70; wait; fov 50; r_viewmodel_fov 50"
-zoom "fov 50; r_viewmodel_fov 50; wait; fov_70; r_viewmodel_fov 70; wait; fov 90; r_viewmodel_fov 90" 

Good to know, thanks. 

will Spike's code be integrated into the next Quakespasm release or it is intended to be a stand-alone piece of software? 

Thanks for the explanation about the weapon offset. I hope the patch or another kind of fix finds its way into a release eventually :)

Regarding Mark V, I noticed that it's better there, although unfortunately the beta release of the mark_v.exe crashes on my computer, unlike the latest stable release. However, I've used the WinQuake port of Mark V for playing through Quake the first time only recently and it worked flawlessly :) Now onto Arcane Dimension with Quakespasm. For the time being I'll stick to scr_ofsx -2.8. 

Mousewheel weapon switching is broken on macOS 10.12 due to a SDL2 bug: https://bugzilla.libsdl.org/show_bug.cgi?id=3432

The SDL1.2 version seems to be unaffected.

Icaro: I'm not sure.. For the time being, it's a fork / branch. 

If I were to modify gl_model.c to allow for more animated textures (beyond 10 per surface) would I also need to modify the compilers to save the extra textures (beyond +9) to the bsp file? 

You can add the textures the manual way by including a brush in the void with the desired textures. That's how we used to do it in the old days before compiler did it for you. 

Is this a change that the guys would be willing to see incorporated into the engine? I don't want to fragment the engine ecosystem for such a small change.

Especially with spikes modifications being released too. 

My music has spontaneously stopped working in quakespasm. I have the tracks as ../ID1/music/trackXX.ogg, which used to work fine. But now I get no music and a message in the console saying

Findfile: can't find music/trackXX.mp3
Findfile: can't find music/trackXX.flac
Findfile: can't find music/trackXX.wav

Any ideas what might have caused this? 

animated textures ... beyond 10 per surface

It is 20 per surface already according to this ...

http://www.celephais.net/stuff/texturefaq.htm

Which was written by metlslime, hehe. 

Pretty sure that 20 is regular + alternate anims. 

0-9 for regular animations. a-j for alternative animations. the limit is due to the base animations using digits, although the alternative anims could be bumped to 26 chars.
more than 10 (or 26 for alt) requires getting people to agree with a single consistent naming system within the 16-char name limit, and that all gets far too political... 

What I was thinking was expanding the frames by a factor of 10 for the numbers and leaving the alternate animations alone. +00 to +99 is what I was thinking.

If nobody cares for it that's cool too, I won't make this change unless the QS authors are cool with it. Like I said engine ecosystem and all. 

slimealpha worldspawn key does not work in Quakespasm

The value seems to never be honored. Unless I'm doing something

Put in worldspawn:

"slimealpha" "1" // Nope, uses r_wateralpha

All the other ones work like "telealpha" and "lavaalpha". 

It's working for me.. tried "slimealpha" "1", as well as "slimealpha" "0.1" in worldspawm.

Does the r_slimealpha cvar work for you? The interaction between the cvar and the worldspawn key is a bit confusing.. when the map loads, if the worldspawn key is set, that gets used until the next time you change the cvar. So the cvars behave like the fog command.

Also if the cvar or worldpsawn key is 0 (the default), that is interpreted as "use r_wateralpha" 

Here is an example of misbehaving, although apparently in different way.

1. Empty Quake folder, just pak0.pak + pak1.pak
2. This start.ent in quake/id1/maps

Mainly featuring ...

"lavaalpha" "0.5"
"telealpha" "0.5"
"slimealpha" "1"
"wateralpha" "0.7"

3. Result: No water transparency but the other 3 settings are used. 

I *think* that might just be un-water-vised transparent water? QS defaults to gl_clear 1 so you get grey tinted instead of a HOM. 

I type r_novis 1 in console. Now water is transparent like it should be.

And although I specified slimealpha 1 in the worldspawn, it is not being used.

Slime is transparent but I said 1! (which is not transparent)

Slime is under medium bridge. I typed "fov 10" to magnify.

Test was that start.ent, no config (I deleted every time to make sure it couldn't be config) and just the pak0/pak1. 

under the "normal" bridge? It's not burning if I noclip into it..