why is it better? is it because you want to play your own music and it keeps getting overridden by the engine? 

No, when playing tough maps it's often frequently saving-loading or dying-restarting :D and every time that happens, music restarts. I'm talking about the original NIN/Reznor's soundtrack (though I am using OGG/MP3, not CD).

I do realize that's the "proper" behavior like the original game had, though. 

In general the problem with this kind of request is that for every one person who wants it one way, there will be another person who wants it another way. Unless it's very obviously broken (I don't see too many defending how GLQuake drew skies) it can even be impossible to get agreement on what the default for a switchable behaviour should be. Sometimes "when in doubt just do what the original engine did" is the only sensible approach. 

Understandable. Make the "original engine way" the default one, and introduce a cvar/option to have alternate? There are many such cases in general in sourceports anyway... 

I know what you're talking about... a lot of the background tracks evolve over the minutes, and it feels a little weird if you reload to a super-recent savegame and the music resets all the way to the beginning. That's especially true with a lot of the recent custom music we've been getting which is less "ambient" and more melodic.

I dunno what the ideal behavior would be, but this probably isn't it. Anyway yeah there's currently not any way for either the player or the mapper to choose a different behavior. 

As Joel explained it, quickloads reset music and that is an atmosphere breaker - at least for me. Also, on the maps wherein the author himself does not opt for any (unless the map is heavy on ambient sounds), I cycle through the soundtrack via an alias and find an optimal track to go with it. Similarly, quickloading in such terms means it is back to silence and cycling through it again. A cvar for this behaviour would be nice. 

Is there no other option to track the maptime in the HUD/stats tab instead of skill level than adding -fitz to the shortcut? 

What I would still like to see in Quakespasm, either in the original release or the Spiked spinoff:
- Vanilla waterwarp (as seen in Mark V)
- .vis file support (for Mark V lit/vis packs)
- some option for gun-specific fov/repositioning

These are the features I am missing most compared to Mark V. Besides that, the increased limits in this port make it the preferred choice when playing advanced content like Arcane Dimensions. 

> - Vanilla waterwarp (as seen in Mark V)
> - .vis file support (for Mark V lit/vis packs)
> - some option for gun-specific fov/repositioning

Oh yes. Also, option to NOT restart the music track that is already playing if loading the save or restarting the same level (like in Doom)! 

I know I had already mentioned this a while ago, especially the waterwarp thing. I am trying vkQuake right now which has it, but the missing .vis file support still weighs heavily. Using (kinda) weapon repositioning with scr_ofsx "-2" in autoexec.cfg as a workaround, but a menu option for this would be better. 

the latest QSS version available for MAC is the "old" 0.92.2-admod.

https://fte.triptohell.info/moodles/qss/

is EricW planning an upgrade to 0.93.2?

Even better if provided with the "MODS" menu like the previous one!
The young generations have problems in understanding the beauty of the console!
;-)

Thanks 

And apparently there's an incompatibility issue with QSS and the latest AD 1.80, on Mac OS. 

> Using (kinda) weapon repositioning with scr_ofsx "-2" in autoexec.cfg as a workaround

Both QS(S) and vkQuake should have a cvar for this:

* New "r_viewmodel_quake" cvar. Set to 1 for WinQuake gun position (from MarkV). 

Yeah, I am using that (pity there's no menu option for this). For my taste, weapons are still too low with it. But well, it's also because the statusbar is in the way. Maybe it's really time to switch to one of AD's new fancy side panel-HUDs as a new default. 

You're running with a status bar alpha less than 1; set it to 1 and it will correct the position, obviously as a trade off for no longer having a translucent status bar.

QuakeWorld has a nice HUD that it would be cool if other engines picked up, and that also works well with gun model positioning. It's about as close to an official alternative as it's possible to get. 

Ah well, I will get used to it. I wished there were ways to do things like that Fullscreen Statusbar Mod I made with 3saster for GZDoom.

Consider that statusbar request cancelled, then. Vanilla waterwarp and .vis support should be doable. I saw there are feature requests for it over at the QSS Github already. For vkQuake, I made the tickets by myself. 

In QS 0.93.2 For MAC, elevators are definitively an issue, irrespective of the map.
Just try the elevator in the start map of AD 1.8. 

... or the elevators in E1M1. The elevator blocks if you are going up. No problem if you go down.

I didn't have this issue with 0.92.2. 

... my fault --> host_maxfps above 72!

I apologise, a warning was even present in the console. 

Hey, I'm using the OS X version of Quakespasm with a 16:10 resolution and none of them look right. The screen's either too high or too low, so I get black bars on edges. Any way to fix it?

PS. Sorry for my noob question, this is literally my first post. 

Adding -width x -height x to your command line will run Quake in a custom resolution of your choosing. Not sure how this would work on a Mac but doesn't a popup appear when you launch on Mac?

More info here

https://steamcommunity.com/app/2310/discussions/0/340412122415607313/ 

Yeah, that's the obvious thing, right, but doesn't fix the problem. I select the right resolution for my monitor and honestly all of them have the screen either being too high or too low, cutting off parts of the game. 

Since there is no vkQuake thread I figured I would ask this here. In the latest version of vkQuake (1.05.0) any and all brush entities are not affected by dynamic lights, including lights from rockets and weapon flashes, flickering or strobing lights, etc. They always remain the same lit value, note the first secret door in e1m1 is fullbright despite being in an area with a flickering light.

Is this behavior intentional, or is it a bug? 

That has to be a bug. I've just had a quick look over the Github and the code for calculating lights on brush models is still there. I didn't look over it comprehensively enough to pinpoint what the bug may be, however. 

reading through the issue tracker I found that this commit caused the problem.

https://github.com/Novum/vkQuake/commit/253a706f8907866ae7ab664e092cdcb6ae43cfc2#diff-d606d657e2d89d658bc091d13fb9ee2de2cf4fa01a26b127d79d890a0c75c20bL151