what to do about future QSS builds?

[neogeographica]

Some extant issues.

For reference...

Issues: https://github.com/Shpoike/Quakespasm/issues

Commit activity: https://github.com/Shpoike/Quakespasm/commits/master

[neogeographica]

Main/recent issues should be fixed now.

[neogeographica]

OK the latest QSS release has shenanigans where it has changed the default value of sv_gameplayfix_setmodelrealbox (from 1 to 0). This reverts from a longstanding Quakespasm/Fitzquake behavior and goes back to an original Winquake behavior, which is fine in the abstract, but in practice will break some (perhaps several) maps/mods that were tested and released for use with Fitzquake or Quakespasm.

The 2021-10-14 version of QSS is the last one without this change, so for now I could just package that one. What to do moving forward though?

• Could include some recommended configuration (and discussion) for explicitly setting sv_gameplayfix_setmodelrealbox to 1. This is probably not a great idea though since many folks will not do that and some things will mysteriously break.
• Could switch to packaging vkQuake instead of QSS. The main downside there is that old video cards can't run vkQuake.
• Could switch to packaging Ironwail instead of QSS. Ironwail may not be completely fully baked yet? And it doesn't support the custom particles and HUDs that QSS and vkQuake do.

[neogeographica]

Going to use that older QSS build for the 2.3.0 release and leave this issue open to ponder future stuff.

[neogeographica]

Possible approach:

• Document the QSS sv_gameplayfix_setmodelrealbox effects in some new doc file.
• In the example autoexec.cfg, include a setting for sv_gameplayfix_setmodelrealbox = 1.
• Add an option to the quakestarter config about whether it should override the sv_gameplayfix_setmodelrealbox with a command line arg. Default that setting to doing an override to a value of 1.

The other valid option honestly is probably just switching to vkQuake, and documenting what else to use if your hardware is too old for Vulkan-capable drivers.

[GenericJohnDoeNO0]

Leave the old and stable QSS in as an fallback and as an default, ironwail (i guess i saw it in your release) and vkquake as additional engines where needed or as option for vulcan users or granny-computers.

[Shpoike]

Firstly, sv_gameplayfix_setmodelrealbox only affects badly written mods.

sv_gameplayfix_setmodelrealbox 0 reasoning: 1) Is better defined, avoiding non-integer offsets and the like, and is more likely to match values specified in fgd files (so fewer droptofloor issues when its already on the floor). 2) Matches Quake's behaviour (mods properly tested against 0 won't have any related issues in winquake/glquake either). 3) Fixes various mods like quakerally/others. 4) Doesn't break in weird ways when people use replacement content with said buggy mods, avoiding nightmares of people reporting issues that can't be reproduced due to not having the exact copy of whatever random rubbish they've thrown into their id1 dir. 5) Allows dedicated servers to completely skip loading non-bsp models.

sv_gameplayfix_setmodelrealbox 1 reasoning: 1) caters to people who couldn't be bothered to test their mods in more than one engine.

Like I said, it only affects badly written mods. The recent ones tend to be aware of this issue and thus are much less likely to suffer from it. Considering the fitzquake behaviour breaks compat with a whole range of other engines, its only the recent lazy mods that might benefit from a value of 1 (older ones tended to care more about cross-engine compat so will not suffer from this bug, early mods will hate a vale of 1). Both FTE and DP(hence the awkward long name) also feature this cvar. At one point DP defaulted to a value of 1, but reverted it back to 0 after taking a lot of flak for general incompatibility.

Anyway, that's why 0. If it breaks any mods then feel free to override it on a per-mod basis - just note point 4 above.

Regarding quakestarter specifically, why are you not letting people chose their engines? People are more likely to actually test things properly if launchers respect user choice...

[neogeographica]

Hey thanks for chiming in!

Yep, folks can choose their engine. It's customizable in that way and documented how to do it. However in service of quick/easy startup into a situation that can be kind of overwhelming to newbies, I want to provide the most widely compatible, featureful, easy-to-use option out of the gate. In the past I judged that to be Mark V; these days I've been rolling with QSS instead.

I don't disagree with any of your points, and I can see why you wanted to make the change. But those points are all kind of focused toward content creators, while for this package I'm concerned with the experience of players (especially new ones). If some release doesn't work, that's just bad for them regardless of whose fault it is.

That's an interesting idea to override it on a per-mod basis; in some ways that feels like the ideal/correct approach. I'm not sure how to reliably and quickly detect whether that's necessary though -- given the volume of releases I process for this, I can't in practical terms do something like compare entire playthroughs of a release with that setting on/off. If there was some sort of automated test that I could e.g. fold into my zipalyzer.py script then I'd be on that in a flash.

[Shpoike]

you could guess based upon release dates, if you know them.

Its tempting to tweak the engine to flag the sizes as undefined and spew warnings, which might be more informative but will still bamboozle the user. Unfortunately there's no real way to analyse the .dat directly. You might be able to detect whether its vulnerable to the bug, but that won't tell you which value it actually needs (and will vary by map).

[neogeographica]

FWIW it looks like this behavior was introduced in Fitzquake 0.80 which was released on May 26 2005, so one thing we could rely on is that nothing released before that date really needs it to be enabled.

[Shpoike]

that gives 9 years of mods broken - the most prolific period of quakec writing, before people started switching to quake2/3/etc. and more, because it took a while for fitzquake to actually start getting used.

I mean sure, you don't care about 90% of the mods out there, but that doesn't mean that its not broken. Does tweaking that cvar even fix the issue that you're actually trying to fix? Or is pr_checkextension 0 the better fix there (the other tweak required to mimic QS - which will make slopes randomly solid and disable various fancy parts of AD)?

[dumptruckDS]

@neogeographica I'm wondering why the standard QS isn't an option for you? I assume compatibility for newer map/mod releases?

@Shpoike since I am a newbie coder I want to understand where I'd check to see if this is an issue? I understand it's drop to floor but what's the specific bug and how do I avoid it in my QC?

[neogeographica]

Vanilla QS doesn't support multiple game/mod folder activation, so it's a nonstarter for the way I handle add-on maps for AD and Copper. (Cf. the docs on mod installing and mod dependencies.)

There are other less-important reasons -- mainly it's pretty rare to ever see QS recommended for singleplayer use these days because vkQuake/QSS/Ironwail have more compelling features. But the multigame thing is the showstopper.

[dumptruckDS]

Gotcha. That's understandable. Somewhat related, here's a poll I posted to YT. I was a bit surprised at the results. Small sample though. https://www.youtube.com/post/UgkxVXkooRY6-hxrPN3jc0p0M5fU0L4v8fTv

[neogeographica]

Lot of Quakespasm inertia I'm sure. :-) (I kind of also wonder what the numbers would have been for DarkPlaces in there.)

Interesting reddit post for even more perspective: https://www.reddit.com/r/quake/comments/ugvjdv/which_source_port_do_you_prefer/?utm_source=share&utm_medium=web2x&context=3