Hahah ...

Nice job Spike! GLQuake could connect to it just fine when running sv_protocol 15. 

I tried adding these things into a pak with pakexplorer, but "particles" is an invalid filename apparently. Any way around that? Weather would be a nice addition to my mod for engines that support it. 

I have a particlefont.tga inside my darkplaces\id1\particles folder, if that's any indication. 

I know, different engines, but it still could be of some use. 

Filenames of the 8.3 format is a PakExplorer limitation. AFAIK, the pak format allows for longer names, as long as the whole path is no more than 56 characters.

I haven't tried any other tools yet. 

Pakscape is what you need 

Finally got around to adding more support for this to the latest version of AD and the particle scaling looks really good. Its nice to know that all my time spent creating a DP particle file has not gone to waste! :)

For some reason I cannot get a screen shake entity to work. Its called "misc_shake" and is based on the version from the RRP codebase. It specifically uses punchangle_x on the player to move the screen around and velocity to make the player move around. For some reason this entity is doing nothing to screen or player.

The new function does use findradius to locate the player and that is certainly working, but the parameters on the player are being ignored. Any ideas why? 

An example video of the QS-Spike (v4) client running with AD 1.5 showing DP like particles effects and weather (rain) 

all these teasers are phenomenal. 

The amount of atmosphere that adds, holy cow it is gorgeous. So players not using QS-spiked will not have the rain or sound effects correct? 

DP users should. Now QSS needs its own Pretty Water mod. 

-- and wouldn't have smoke effects coming from the flames. 

I'm sure Seven could do something about that.

*thinks about Seven's forthcoming SMC v5.53*

Hmmm... Seveeeeen? 

The QC example in weather.cfg has spelling mistakes
Line 4 - particleeffectnum("weather.te_rain")

In order to check for rain / snow functionality the engine should respond to the following extension checks, I am getting false from these.
checkextension("DP_TE_PARTICLERAIN");
checkextension("DP_TE_PARTICLESNOW");

@Bloughsburgh
not using QS-spiked will not have the rain or sound effects correct?
I plan to only implement this for QS-Spike and DP clients 

Prepare PBR materials and real-time GI too. 

Why not asking ericw to merge Spike�s code into QS for a new release? 

I suspect it will be eventually. It isn't a set of changes that drastically changes the game. I don't even thing fog was a "vanilla" glquake feature and that was added.

The guys are probably just keeping it separate for quarantine while the bugs are sorted out and to see how it is used / abused. 

Get the following console messages
findfile: can't find particles/effectinfo.cfg
findfile: can't find effectinfo.cfg

This is after doing the file registering thing in world.qc. particleeffectnum("effectinfo.txt");
Any reason the engine is still trying to find a config file? You did say in the documentation the engine will not look for particles files by default. (line 73 in qs-spike.txt "no effects will be loaded by default"

Any chance you can move the "Particle effect token stainblah blah" to developer 2? The engine is not going to support stain stuff so why spam the console about it?

When I register my own weather.cfg file I keep getting "fte_weather.te_snow: is not a recognised particle type" There is no type specified in the effect, its default. Why do I get this error?

@Icaro
Why not asking ericw to merge Spike�s code
This is nothing to do with me, totally up to the QS team. I plan to support QS,QS-S and DP egines for AD. Some features are not just present, this is something for the engine coders to add/sort/fix. 

It isn't a set of changes that drastically changes the game. I don't even thing fog was a "vanilla" glquake feature and that was added.

Your enthusiasm keeps baffling me, because I vaguely remember you giving me a speech about the need to avoid unnecessary feature creep. Maybe it was someone else? Too many shamblers on this map. 

a speech about the need to avoid unnecessary feature creep does sound more like Shambler than Shamblernaut.

@khreathor What are PBR and GI? 

It was less a "speech" and more an observation of how the QS contributors seem to operate.

For what it is worth I think there is a need to balance useful "good" changes vs chaff.

It is the same reason why my IRC mod will never make it to the main fork. It's bloaty and nichey... And probably buggy as all hell.

The Spiked modifications (I think) fit in well with the general "feel" of QS. The effects aren't "high-definition", so they don't feel out of place in quake. 

@sock
punchangles are indeed broken, thanks for reminding me to look in to those.

regarding DP_TE_PARTICLERAIN+SNOW, I'm not entirely sure that its correct to advertise those when the engine gives no guarentees that there's a particle configs loaded that it can actually use for those effects.

'no effects will be loaded by default' means that r_particledesc defaults to empty (or classic, to use the classic particle system - note that relative to FTE, QSS always assumes that classic is specified even when its not, which avoids the need to rewrite the existing particle system, as such make sure classic is still listed in default.cfg or you'll probably mess up FTE a little).
so if you're usingp articleeffectnum and using giving it a namespace, it'll now know to try loading effects from said namespace (effectinfo or effectinfo_* being special that automatically triggers importing from dp effect definitions from the relevant file name, if there's no fte effect available).

re stains, stainmaps kinda suck. especially if you want your effects to work properly with q3bsp too, or rtlights. As such I can't really recommend using them anyway thanks to those inconsistencies.
Either way, they're DPrints, so end-users won't see them, unless they actually want that info.
Considering that quakespasm traditionally spams all sorts of 'WARNING:' messages for simple things like using a couple too many entities, I don't feel that its entirely out of place, but then that's my personal probably-biased opinion.

@Mugwump, I don't think seven has any interest in any engine other than DP.
there are a couple of qc fixes needed (namely: fixing up monster spawning so that it doesn't nudge monsters into the ground). I'd like to think that Seven would accept patches to fix that, so long as it doesn't break DP.
it'd also need repackaging as quakespasm doesn't support pk3s, md3s, stereo sounds, and has lower mdl limits. thanks to the way smc works, much of that could be 'fixed' with some specific cvar settings.
I would apprechiate it if someone were to go through smc's features looking for qss engine bugs, but whether its a qss bug or a quake-vs-dp difference, or just a qss content limitation is likely a bit more awkward to figure out.
either way, if anyone were to do something significant, it does kinda need some cooperation from Seven, preferably in advance.

@Shamblernaut, those particle effects are as high-def as they're made to be. if you want high-def, try the particles from AfterQuake or SMC.
Sock's use of them is at least aesthetically consistent. 

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

includes a variation of baker's 'e1m1_effects' thing with some hacks gone (some of which required engine tweaks to resolve). Otherwise just a bugfix release.
the zip is bigger because it includes both win32 and win64 engines (still no dlls) 

A quick test ... 2 things I noticed.

1) Grab an item emitting effects (nail gun), the item remains visible.

2) Appears to run particles/map_e1m1.cfg to get per model effects, once level is changed the effects from the previous level persist.

The ability to misc_model without progs support and the ability to do effects without a model are invaluable. So is honoring the angle of an entity for effect emission. 

I would say there are too many mugbumps on this board nowadays

i miss Kinn