well, there's a few things that would be worthy for an r6, but I need to talk to ericw I guess about logistics or something.

What else did I miss? What bugs are there? What is there that I should actually care about? What is there that would make an r6 actually worthwhile?.. that doesn't also invole rewriting half of quakespasm... :) 

So if a mod wants to use more weapon slots, the engine adds them. Or pergaps even better, gfx.wad texture replacement support based on an integer so mods could have custom weapon, ammo, face, hud images. Or maybe not. 

Here's a bug report from mfx:
- extract https://www.quaddicted.com/filebase/ad_v1_42final.zip
- launch qss-r5 with "-game ad_v1_42final"
- type "map ad_crucial"
- press F6, then F9 to quickload
- "QUAKE ERROR: Loadgame buffer overflow" 

if you want more (hud) weapons or different huds, then the only way I'd consider doing that is with csqc. Anything else would be a hackfest.

One alternative would be a q2-like hud string that says what images to put where, and which conditions for them to be enabled. Using the same formatting as Q2 is probably not practical due to q2's configstrings, and they should probably be defined via configs or something, and I've no idea how to control which ones are used. Maybe just lots of conditional cvar expansion. Lots of aliases or something that get re-evaluated every now and then, I dunno.
Maybe I'm just overcomplicating things again.

Side note: At what point does it stop being quakespasm and become just a crippled version of FTE? :s 

What else did I miss?

I haven't had a chance to check any of this stuff out for a while, because reasons, but is crunchy lego pixel mode working on particles yet? 

Do not worry spike. Nobody will use fte anyhow since there is qss. 

What is there that I should not actually care about?

* I get constant crashes with save games or demo files. Maybe this is a new DarkSouls feature of the engine, one life no saves! :P
* Volume weather (te_particlerain / te_particlesnow) goes through solid brushwork. It now rains indoors, DP is good with the same setup :) 

DP volume particles
* checkextension te_particlerain / te_particlesnow
* console vars cl_particles_rain / cl_particles_snow
* hardcoded volume particle effects

QS-S volume particles
* no checkextension
* console var r_part_rain only
* flexible volume particle effects

I looked at SMC and its checking the CL_ console variable to enable / disable the QC functions for volume effects. DP also switches off the volume effects if the console vars are set.

QS-S is really aimed at surface weather effects. The different console variable only work with the surface option and ignores the volume version.

Why the brand new standard for console variables? How can the mod know if the effects exist or not? How to detect the state of the particle weather if the console vars don't work with both systems?

I am beginning to think this is some cruel joke by Spike. Maybe I should of saw the signs when the download link points to a junk folder. Man, I am so disappointed with this situation. :( 

Spike's engine code gift can't be a cruel joke.

I know because the next version of Mark V has devoured 1/3 of the engine enhancements that most interested me from the co-operative play perspective.

Spike saved me a ton of time in just the 1/3 acquisition, the fact he implemented these in a familiar codebase like Quakespasm is incredible.

I did what I could to try to make a working demonstration of the client-side particle system (where client-side = what does not require QuakeC). 

Why the brand new standard for console variables?
most cvars are not part of ANY standard. This results in random crappy inconsistent names. The only winning solution is to boycott all cvar hacks. They're user settings, and NOT how you modify the behaviour of builtins.

r_part_rain 0 blocks support for surface-emittance and technically isn't about just rain. Yeah, its a crappy name that dates back to the primary feature. You can use to to prevent your snow stuff working too. Either way, that's the user's choice, if they want to block it then they can, but they won't end up with what the mod really intended.

Its the same with DP's cl_particles_rain / cl_particles_snow except that they break te_particlerain/snow rather than surface-emittance. Default 1, users can reconfigure them to 0 to break the mod. SMC checking for them as well makes the engine support for that cvar redundant. You can add the same check in AD if you want, go ahead, it'll block the effect just the same in each of DP+FTE+QSS, just be sure to create an autocvar with default value enabled, or something.
Obviously, it goes without saying that using a cl_* named cvar in ssqc is a bit stupid, but there you have it.
There are very very few standards when it comes to cvars.
FTE's console scripting allows for all sorts of if-statements and other logic to control which particles get defined, unfortunately QSS doesn't use the console to parse particlesets, and lacks that cool logic stuff, so yes the result is a little more limited. You can still use r_particledesc to control which sets should be loaded.

How can the mod know if the effects exist or not?
Reliably? It can't. Not even in DP. Sure, it might exist on the server, but maybe the server was reconfigured to use protocol 15 (so that other clients can actually connect or whatever), in which case the server will still report that it exists, and yet noone will ever see it.
False positive? False negative? Either way its flawed.
If you want to ensure that FTE+QSS will load a particle config containing suitable effects for te_particlerain then you can just use particleeffectnum on the effect name to ensure that its containing config is parsed, at which point you'll start to question what the actual name is for the exact arguments you passed to the builtin, as opposed to the default name that gets used if the full name wasn't defined, and why you couldn't just pass a friggin effect number for it instead... But, well, DP.

I am beginning to think this is some cruel joke by Spike
http://triptohell.info/moodles/this_is_not_a_cruel_joke/honest/quakespasm-spike-r6.zip
New update, just for you sock. :) 

irony? 

either irony or just a barefaced lie, depending on whether you think I was being witty or just a dick.

I do have some tweaks towards an r6, including pk3 support, but I'm too lazy to bother making sure everything else still works, and I still need to do something about that demo issue that sock reported (to fix, I need to rewrite some crappy code that someone else ported over from proquake, and as I said, I'm lazy).

so yeah, there will be an actual qss-r6 eventually, and not just for sock/AD (ooo, a proper readme! okay fine, enough hype...). 

http://triptohell.info/moodles/junk/quakespasm-spike-r6.zip

adds pk3 support, a few bugfixes (saved games+demos), and a couple of minor things that smc uses.
the zip is also slightly more end-user friendly, imho, your milage may vary.

its almost certain that I missed something though. 

I love the effect, I wish it would be come standardized.

https://www.youtube.com/watch?v=aHCocIjeWuw&feature=youtu.be 

Its great to have particles and weather in AD without the DP slowness. My r9 290 would go down to 2 fps in some of those levels. 

It's performance is better even than MarkV at my laptop which was from 2013 with an i3 CPU and integrated graphics core. The frame rate is definitely higher than in MarkV when I am playing AD_TFUMA.

Now if this supports multiple gamedir and using path as game dir (as in "-game ./Addon/CZG07") then I can die in peace. 

Summary:
bigger maps, downloads, voip, more networking choices.

Changelog:
http://triptohell.info/moodles/qss/qss-changelog.txt

Download:
http://triptohell.info/moodles/qss/quakespasm-spike-r7.zip 

Quite the changelog there Spike! 

Some light testing ... Very awesome stuff!

It connects to DarkPlaces using DPP7 and appears to work just fine in a vanilla situation.

/Very incredible work in R7, Spike! I will no doubt be making acquisitions some time this year. 

entering "r_wateralpha 0.5" at the console with no map loaded crashes.

This bit in R_SetWateralpha_f seems to need an additional check for cl.worldmodel != NULL:

if (cls.state && !(cl.worldmodel->contentstransparent&SURF_DRAWWATER)

(same for tele/slime/lava) 

static ents 2048 -> 4096
efrags 4096 -> 8192

IIRC there is a tutorial from MH on making these dynamically allocated, looks like Baker has applied it to MarkV and I should try doing it for QS as well.. 

thanks, although I'd already found the r_wateralpha issue.

if I make another release, I'm sure I'll pull whatever QS updates first, so consider those limit bumps a done deal with any future updates. 

its probably worth noting that sv.signon limits the max static entities to (65536-baselinedata-staticsounds)/sizeof(svc_spawnstatic).
With protocol 999 that's about 23/25 bytes, so about 2730, assuming no baselines (17 or 19 bytes with 666).

or in other words, bumping beyond 2048 is probably pointless in regular quakespasm. qss can benefit due to how I bypassed sv.signon, but regular qs probably just won't be able to use those extra static ents very often.
(note that my qss improvement can break engines that borrowed proquake's mid-map demo recording logic, which depends on assumptions not made in vanilla - that assumption is also in qs, but gone in qss-r6 iirc... pick your poison.). 

Ah yeah that makes sense regarding >2048 statics.

I was going to at least attempt the unlimited signon buffer patch in QS. So that specifically has a conflict with the proquake mid-map demo recording I should look out for? 

yeah, iirc proquake saves a copy of the message containing the svc_signonnum, which works well enough when its just a serverinfo and a prespawn message, but when you have 50 different messages containing that prespawn data, all that extra stuff won't be saved and naturally won't be written into the demo.
I solved it by regenerating the prespawn data from what was parsed, though you could alternatively make a linked list of all prespawn messages (instead of just copying one).