If you track commits to the QuakeSpasm code you'll have seen that development never really stopped, but also that most recent changes have been relatively minor nips & tucks moreso than anything else.

This signifies to me that the codebase is now mature and stable. It might not be as full-featured as QSS or as highly performant as vkQuake, but in the scope of what it sets out to do, further radical changes would result in it becoming something else.

There are certainly under-the-hood changes that I'd make if it were me, but it's not me, and for most of them it's likely really only the type of person who cares about that kind of thing who would notice.

The Quake 2021 release is a new set of content that people would like to run in their favourite sourceport. Again, going to the various Githubs, you can see QS and vkQuake picking up a common set of code for supporting it.

This is exactly what I'd hoped would happen. Like it or not, the probability is that the new content is going to become the standard that new players get going forward, and supporting it in sourceports is required to prevent the community becoming fragmented and niche.

I'm obviously only on the outside looking in so far as QS development is concerned, but that does indeed seem to have been what prompted this latest release. Hopefully there will be more to come; I'd love to see QS picking up MD5 support, for example, now that we have an officially sanctioned MDL replacement format with a set of ID1 models. 

Splitting QS into three main branches feels kinda needless to me at this point, anyway. Why not have QSS's enhanced features and vkQ's renderer in the official build? Often, the branches copy features from each other, anyway, depending on dubious limitations authors choose to impose on their branch for reasons I can't understand.

Also, QSS has fallen a bit behind feature-wise right now. It lacks support for QuakeEX and external .vis files, for example, which are important features. It would really be time to bring all important QS branches to the same development level. 

Not everybody wants or needs the new features from QSS, and not everybody runs Vulkan (there are even people having difficulty with it in the 2021 engine). Stock QuakeSpasm is a good, solid baseline with most of the barriers to entry from the old ID engines removed. People can just grab the files, drop them in their Quake folder, and get a good game of Quake that plays quite faithfully to the original but that can run on a wide variety of devices and without much in the way of tweaking or config required. That's reason to exist on it's own. 

Well, at least all projects share the same dlls, so all executables can co-exist in the same folder if you want them to.

Personally, I need pk3 and vis support plus accurate underwater warp. There's still no QS variant out there which has all of that. 

I just took a look at the commits. I stand corrected, so it wasn't dead at all. And in retrospect, every QS release has been a bit of a surprise.

====

We already do have issues with fragmentation in the single player mapping community that are going to get worse now IMO.

QSS has made tremendous gains and is the daily driver for many high profile mappers, streamers and players. We can blame Arcane Dimensions 1.8 for this. There were some sexy features on display there and for players, online is a bit easier to deal with and more robust in Spiked. The irony is that very few mappers are using the features that peaked their interest in the first place! But "uncoupling" physics and framerate was a welcome addition that people like.

We're already seeing maps by newer or less "disciplined" mappers, that are "broken" by Quakespasm-Spiked. Spike changed the precaching system and a couple other little things that can lead to maps that are slightly broken or even unplayable in good old QS. I try and encourage everyone to use QS while mapping, but as I mentioned above, I nearly did a QS RIP video that would have suggested that mappers just switch to QSS to save everyone headaches. QSS and vkQuake share a lot of code now. Changes that many people like that I presume, aren't ever coming to QS. So even recording demos for mapping feedback is a problem now. These issues are not going away if QS is still alive and kicking.

So I guess the solution is to use QS for mapping and QuakeC and to encourage as many others to do the same as possible.

As I said, I am not seeing any mods or maps that use the fancy CSQC and particles aside from AD. Yes, people are tinkering, but as grandma used to say: "Where's the beef?"

The first of these ports to include the new lighting and md5 support from Quake Ex will be tough to beat though. Looking forward to that new wrinkle. 

Version 0.94.1 of QuakeSpasm is released.

Downloads:
https://sourceforge.net/projects/quakespasm/files/
http://quakespasm.sourceforge.net/download.htm

Changes since the previous version:
- Fixes lightmap issues introduced in v0.94.0 (sf.net bug/50) 

QSS supports MD5 now

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

Spike said on discord about the new release: "fixed up iqm support, added md5 support, merged QS's various changes are the main tweaks... oh, and added an 'extras' menu" 

But is there a changelog somewhere or more info?

No, it's QSS. :P

Downloading. 

QSS now supports external .vis files as well. Outstanding. 

There is decision to store /localisation/ in mg1 folder?

OUM:
[img]https://quaketastic.com/files/screen_shots/loc.jpg[/img]

I solve it by removing custom font, but?.. 

- Copy over the "mg1" folder from your Steam installation (default dir: C:\Program Files (x86)\Steam\steamapps\common\Quake\rerelease) into your QSS dir
- Open "QuakeEX.kpf" with 7-Zip (or another zip manager of your choice) and extract the "localization" folder into the "mg1" folder in your QSS dir
- Start the game with parameter -game mg1 

/localization/ should be stored off the Quake basedir - e.g. C:\Quake or whatever - rather than in any game dir. The localization text file contains localized strings for all mods in a single file.

Ideally that wouldn't have been the case, and each mod would have had it's own strings that are merged at startup time. This, and other evidence (*another* crusty plain text format to parse, yayy) indicates that the localization system was pre-existing stuff in the Kex engine rather than something specifically written for Quake. 

Removed QuakeEX.kpf from quake dir completely. But in AD the same thing: font lose translucentness.

https://quaketastic.com/files/screen_shots/ad_font.jpg 

Good point. Like that you are probably also able to use the new ID1/SoA/DoE pak files. Which is kinda necessary if you want to profit from the new MD5 model support. 

You can export /progs from the new PAK files, drop it into your existing ID1, and using an engine that supports MD5s, just run them that way.

The new MD5s don't actually require a new progs or new entities lumps. The model names are the very same as the old ones (barring the extensions), and the models all have the very same number of frames as well, aside from some pickups and others where the original had 1 frame but the new has 2 (I've not been able to determine the reason for that). They work perfectly with a stock ID1 progs and maps, though.

So in other words the MD5s were clearly and specifically designed as drop 'n' go replacements for the old MDLs, and they just slot cleanly into place with no messing required. 

if you have both mdl and md5 replacements, e.g. from the AMQ? Will md5 take priority over mdl automatically?

Asking because I saw that latest QSS has a toggle for model replacements which is set to "off" by default. 

Will md5 take priority over mdl automatically?

Depends how the engine coder handles this. Quakespasm already has a "path_id" solution for LIT files and the like that would seem appropriate for this too, so the scenario where:

- ID1 has MDLs
- ID1 has MD5s
- MyMod has MDLs

Would mean that when loading a model, the priority order would be the reverse of what I've listed: a MDL in MyMod takes priority over the same named MD5 in ID1 which takes priority over the same named MDL in ID1.

That would seem to be the behaviour desired by content creators too, but like I said: this has been a solved problem for years. 

And what if the mod has mdls and md5? Basically think AMQ with added md5s. 

I think you're getting silly now, and I think you're deliberately trying to pick holes in any proposal to add MD5 support to engines.

It can be as simple as this. People who want to use MD5s can use them. People who don't can just delete the MD5 files and pretend they never existed.

Your line of questioning fails an important test - what's to stop players doing the very same with their own preferred MDL files?

How about rather than pick holes, you propose how you'd like to see it work? 

Ah well, just sticking to one format, then. Got it. I am out of this conversation now. Enjoy. 

in few last builds of QSS. Alive falling on the base floor or sticks on floor. Dead bodies sometime floating down in void then up to its place. md5 models where disabled. Issue encountered in last pre-md5 suppurted release to. 

This was happening on September 6th build for me as well. There's a new one from September 8th - I quickly tested it, and this bug is fixed. 

on QSS from September 8th. But there is few time sicked alived on the floor. May be it is rather mapping mistakes where monster placed closer 4 point to the floor? 

while scrolling up to choose the LG there is no v_light.mdl visible until pressing "fire". If choosing model replacement "off" issue is gone. 

Lately I am finding more and more issues with QSS, with regular QS working just fine.

Latest QSS build (Sep 13, 2021) seems to have showstopper issues in some maps like:

- Not all enemies spawn to lower the silver key platform in HIP3M3 "Limbo"
- At least one SoA level (from Gotshun's "Lost Levels") has issues with func_train entities

There might be more. I have already created tickets on Github regarding that. It seems that right now, regular QS is the better choice at least for classic/vanilla-style levels since it runs all maps just fine.