News | Forum | People | FAQ | Links | Search | Register | Log in
Spiked Quakespasm Modding/Coding Help Thread
Thread for figuring out all the new particle and modding features in the "Spiked" version of Quakespasm.

Tutorial on how to enable rain and snow on the Quake start map:

1. Video of snow:
2. Video of rain:


1. Put this start.ent download in c:/Quake/id1/maps folder. Tells it what textures emit snow and rain.

2. Put this weather.cfg download in c:/Quake/id1/particles folder. Indicates spawn information on particles and how they behave.

3. Enter r_particledesc "weather classic"; map start in the console. I assume "weather" is the name of cfg. Also seems to work with just r_particledesc "weather".


Q: How do you find out the name of textures?

With Quakespasm I don't know that you can, but in Mark V just type "tool_texturepointer 1" in the console and look at a surface and it displays the name of any texture you look at on-screen. screenshot

Q: How is the external ent file made and what does it need?

Open up Mark V and type "map start". Now just type "copy ents" and the entities for the entire map is on the clipboard. Open a text editor and paste. Save it as c:/Quake/id1/maps/start.ent

The first few lines of the file look like this, add the 2 bolded lines that tell the particle system that the texture names are "sky1" for snow and "wizwood1_8" for rain.

"sounds" "4"
"classname" "worldspawn"
"wad" "gfx/start.wad"
"_texpart_sky1" "weather.tex_skysnow"
"_texpart_wizwood1_8" "weather.tex_skyrain
"message" "Introduction"
"worldtype" "0"
Alpha Masked Model Support - How They Work 
Alpha masked models are supported --- texture transparency for trees, brushy stuff, etc.


See it in action in Quakespasm "Spiked" by downloading this mod and extracting to c:/Quake/alpha_mask.

Start Quakespasm and do "game alpha_mask; map start" and look at the lavaball in the HARD hall way.

This is how they work:

1. You'll need QME 3.1 to set the flag. Download QME 3.1 shareware

2. The flag is 0x4000 (same as Hexen 2). Here are screenshots:

QME 3.1 - Model view - screenshot
QME 3.1 - Model menu - screenshot
QME 3.1 - Flags Panel - screenshot 
Holy Crap 
Holy Crap
Holy Crap this is awesome. All the cool stuff of Darkplaces but still twisty water. 
This is all very cool. Thank you spike. 
And Baker For Putting This Help Together 
Great Stuff 
Any chance of implementing lit water in this? It would be a huge incentive for mappers. 
+1 For Lit Water 
Thank you so much Baker for your effort to show examples, this is very easy to follow.

-If someone not using QS-spike attempted to play a map that had weather enabled via the worldspawn key option, would they just not see the effects or would they receive console spam/errors?

Anyway, this is completely amazing to see these type of effects in my favorite engine! 
Just no effects. No console print or anything. 
Playing Around With Weather. Pretty Awesome 
So, I've made a new snow particle texture (tga only yes?). Where do I put this tga?

Is there documentation for the FTE particle system? (I assume it works basically the same as this?) 
So This Is Interesting :) 
but um, probably not desirable to inline as a blob.

One idea is - would Spike/others be interested in uploading vaguely stable versions (as tarballs with a readme.txt) to this directory ?
and we can link/document it in some form ?

If so, pls create a sourceforge account and i will add you to the project and you can upload to this directory.

This would probably be easier for everyone than the alternative; preparing patches and chatting to Eric and Oz about committing single features to main. Cheers 
Ok I Just Figured It Out Myself 
so if I have image bensnow.tga, i can dump it in the particles folder, then enable it by using

texture "particles/bensnow" in the definition in weather.cfg 
I Can't Wait To Play Your Yellow Snow Adventure Kinn 
Czg I Thought You Were More Into Golden Showers? 
You Know, One Leads To The Other 
Another Question 
I can't immediately tell from the documentation:

Let's say I wanted 4 different rain settings for the same bit of sky (off, light, medium, heavy) - I assume I'd need to create a separate particle definition for light, medium and heavy. Can I disable/enable particle emission from the sky texture, mid-game, via QC? Can I change which particle definition the sky texture uses mid-game, via the QC? 
Spike's Weather.cfg Raw Comments ... 
to use from qc, r_particledesc "weather classic" or call particleeffecnum("weather.te_rain") so the engine knows which config to use, then use the particle[rain|snow] builtins as normal.

without qc changes option 1) use a texture called skyrain or skysnow, in addition to the r_particledesc thing so that this config is actually used (this is more for people to add stuff to existing maps).

without qc changes option 2) add a worldspawn field called "_texpart_TEXTURENAME" with value "weather.tex_skysnow" or "weather.tex_skyrain"

without qc changes option 3) an equivelent console command: r_partredirect tex_TEXTURENAME "weather.tex_skysnow"

note that without qc, you need to restart the map for it to take effect.

on the other hand, if you wanted to emit particles from models, use r_effect (which can optionally hide those models too).

to override trails defined by model flags, you can use the r_trail command.

weather effects that leave decals are probably overkill

one option is to spawn a particle from qc that emits other particles that leave trails. emitting such trail emitting emitters from surfaces is definitely overkill.
It looks like from the weather.cfg comments you can do that, you might need to do some experimentation. If you get it to work, plz post back and share. 
I can't see a way to set the particle emission for a texture, from the QC.

It can be done from the console (e.g.) r_partredirect tex_TEXTURENAME "weather.tex_skysnow"

...but that requires a map restart to take effect. :/ 
Cross Posting A Piece Of Knowledge 
Baker: random angle on rain like Qrack's gl_rain

Spike: use velbias, and add a bias so it's angled.

or just make it bounce off walls at a high velocity, because that's fun too, then turning into blood, bouncing some more, and splattering all the walls with decals.

you currently need to reload the current map in order to change the effect associated with sky.

the r_partredirect command *should* do what you want, but its implementation is still lazy and doesn't reprocess anything (which doesn't affect regular particle effects because I just left it using strings for most things, but does affect surface+model associations).
(it can be used recursively too, and possibly should if you want it to be generic for mods, though it gives up after 5 levels to avoid infinite loops).

you can also change r_particledesc, but doing so will obliterate all existing particles, but not the polys emitting those particles...
really r_particledesc is meant to be a user-command rather than a mod one, while the namespace stuff is meant to be for mods (config names allow for downloads).

the _texpart_foo thing is great because it means the config can be used regardless of the r_particledesc setting the user used, so its noticably more robust than trying to use the automatic tex_foo names.
a user can still override eg "weather.tex_skyrain" by just using that name (including the 'wrong' config name) for an effect in some config named by the r_particledesc cvar. Or you can use r_partredirect.

and yeah, I suck at explaining. much of it is just me trying to give complete info, even if its not useful to you personally. 
Particle Fields Descriptions - FTE Wiki 
Very Important Link:

Spawn Related Fields

. *count (count)*
- count: specifies number of particles to spawn with point effects

. *step (step)*
- step: specifies Quake units per particle to spawn with trails
! Note: step (x) is a synomyn for count 1/(x)

. *die (die)*

- die: specifies time in seconds it takes for the particle to die. A value of 0 means that the particle will be rendered for a duration of 1 frame.


/Far more detail and number of fields @ wiki 
Sparks, Lava Effects, Trails 
fte particle examples are rare, but I remembered one from long ago from Haze.

Sparks, Lava effects, trails

1) haze.cfg download in c:/Quake/id1/particles folder
2) Type r_particledesc "haze"; map start

Here is result in video:

The config is not completely recognized and is not entire Quakey --- and Haze never intended it to be.

But the contents of haze.cfg may serve as a reference for modifying/adding effects to models or particles. 
Cl_bobcycle 0 
gives a grayflash 
Cl_bobcycle 0 
Actually causes a floating-point division by zero in most Quake engines; line 113 of Spikespasm view.c:

cycle = cl.time - (int)(cl.time/cl_bobcycle.value)*cl_bobcycle.value;

Just set it to a really really low value instead. 

sorry it took so long. I got bored, and distracted. so I might as well give what I have before I forget about it completely.
Anyway, this build should fix various issues with the previous one, as well as making protocol 15 servers more compliant (which makes it a little more limited, but oh well). 
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? 
A Storm Is Coming 
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? 
R4 Feedback 
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.

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. 
"I Plan To Only Implement This For QS-Spike And DP Clients" 
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. 
R4 Feedback 
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?

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? 
Nono That Was Me 
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. 
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. 

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. 
Too Many Shamblers On This Map 
I would say there are too many mugbumps on this board nowadays

i miss Kinn 
Is "Too many shamblers" a meme or something? What is happening. 
@sock / @spike 
See post 1014 that I accidentally posted in the Arcane Dimensions thread instead of this one ...

I guess I'll just repost it ... :(


A thought for Sock: The QuakeC extensions check is only for what language extensions a server has. That's why they are QuakeC extensions. In single player, that's the same thing as the server.

But it sounds like you are doing coop too.

Remember, a regular Quakespasm client and a DarkPlaces client could be connect to a Quakespasm Spiked server.

Doing checkextension("DP_TE_PARTICLERAIN") tells doesn't tell you anything about a client.

Send some WriteByte wizardry to regular Quakespasm client and it'll crash out? Quakespasm Spiked R25 have new extension that uses WriteByte (that DarkPlaces doesn't have and R24 doesn't have) and DarkPlaces or Quake Spiked R24 as client to R25 server gets unexpected message and crashes out after 5 minutes because explosion effect sends unexpected bytes?

/Please let me be wrong and that I haven't found the achilles heal of the QuakeC extension system where even a server never knows what clients will work --- it just needs to run the progs and maybe the client crashes out eventually or maybe it doesn't. Hope to hear "Baker is completely wrong because ..." as next Spike post ... 
baker, use the te_particlerain builtin, and hope the server isn't stupid and knows how to filter. writebytes are evil.
where there's an actual builtin to do the exact same thing, just use that. seriously, writebytes are evil!

alternatively you can just order everyone to use the exact same engine+revision and then you don't even need to bother checking for extensions! yay for lock-in! 
How would a client know what version is needed for a given server, though?

/I'm just thinking things ahead to try to avoid a tower of Babel situation. 
You'll hate this, but as you've noticed a ProQuake server sends a byte indicating the server version.

Just trying to avoid a situation where clients have no frogging idea whether or not they could play on a server or not and the server has no clue either.

/Yeah, WriteBytes are evil. Do any the QSS extensions require WriteBytes? If not, I'll feel a ton better. 
And btw Spike, don't take these questions wrong.

I know you know your stuff and think about these things, you can do multiprotocol stuff on your FTE servers and have done it for years.

The opposite of this is an engine that can't play Zerstorerer or the Mission Packs without a patch and used to have keys falling out of standard Quake maps.

I know you aren't like that and do a ton of thinking about compatibility. So don't take any of this wrong -- all the looking at QSS for R4, it all seemed impressively super-compatible. 
I think the solution to this is simple. Protocol 66600 (protocol is 32 bit when sent to client)

66600 = FTE666 + no extensions are used.
66605 = FTE666 + all Quakespasm Spiked R5 extensions.
66606 = FTE666 + theoretical Quakespasm Spiked R6 extensions.

Server knows if mod wants to use extensions. If the mod doesn't ask for extensions, have it report the protocol as simply 66600 (00 means no extensions required).

Server reports to client the protocol in the form of printf("666%d", QUAKESPASM_SPIKED_LEVEL) so to speak.

Quakespasm Spike R5 sees server running Quakespasm Spike R9 feature set, says "Server requires R9 extensions level. Update engine.".

FitzQuake 0.85 tries to play a 66605 demo, "Can't play demo, protocol is not 15 or 666."

Duplicate process for 999.

Everybody win/no hassles! No incompatibility! test2 say sv_protocol 66605 
AddressSanatizer on macOS reported this bug: the memcpy at net_udp.c:443 is reading past the end of myAddrv6.
sizeof(struct sockaddr_in6) == 28 bytes, and the myAddrv6 is only 16 bytes.

Also I mirrored r5 as a branch on my github mirror of QS:
It builds and runs fine on macOS 10.12, btw, once I added the new .c files to the xcode project. 
the server already tells the client what the protocol is. go read how the pext stuff is communicated to the client, and possibly how the server queries what the client supports too.
for server browsers, if it really matters then just use different master servers (or a different protocol name for dpmaster).
otherwise just listing servers that might not work helps encourage people to update! an old client is an unhappy client...

the memcpy size is wrong, sorry.
memcpy(&((struct sockaddr_in6 *)addr)->sin6_addr, &myAddrv6, sizeof(((struct sockaddr_in6 *)addr)->sin6_addr));
should be more correct. 
Could One 
Make a level now set in a desert storm? 
I'm Sold

Im so fucking sold. 
Is that a Doom 3 inspired tileset? 
Some maps made in that set already: 
Pretty Awesome Stuff MFX 
Quality is top tier as per usual! 
Some maps made in that set already
How surprisingly few... 
AD 1.5 Hype 
It would be so sweet to have DP's features implemented to QS-Spiked since it's way too unoptimized for me even with RT World off and the interface stretches badly with widescreen for some reason.

How would those decals work? I feel like they would affect map aesthetics if there are too many around.

Great work so far.

PD: Any idea if these effects will have a performance hit? 
Performance Hit 
I am guessing it's minimal... The bonus is that these particles should also result in smaller demo sizes 
R5 Feedback 
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.

I once asked LordHavoc for a way to query the DP engine so that I could customize a MOD I was building. He told me there was no way of doing it. When I asked him why, he said, I want MODs to query features not engine types. So that is why "pr_checkextension" exists.

MODs are suppose to query the Quake client for features; Particles, fog, surface inspections, rain and snow volume effects. This is the standard that Quake engines *should* follow. If QS-Spike refuses to tell what features it has then its just going to be a clusterfuck of guessing, spamming the console and wasting people's time.

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

I agree QS use to be really bad for console spam, but over the past year I have worked with Eric to move all the console spam to Dev 2. As a mapper I rely on Dev 1 all the time, I need to know what errors are happening with a map. Having to wade through pointless spam messages every time I load a map is just a waste of time. I highly recommend the stain messages be dev 2 because you are reporting a feature that does not exist. So I am not sure how this is useful to know every time a map is loaded.

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)

I have asked all members of the AD team to download this zip and try to install the engine. Every person has said the same thing, How do I install this engine? The Zip file is just seems to be a clutter of stuff. There is no readme file, a ton of config files and no clues what to do. I know you expect everyone to just work it out for themselves, but the organization of the zip file could be a better layout.

@Baker, WTF, why are you arguing for abandoning a current standard for querying clients for features? Anyone who mixes Quake clients is always going to have problems, so using that as a justification for not applying a current standard is totally wrong. The extension system was designed so that MODs don't have to guess what features are active and spam console with endless commands hoping they will work. Lets all move in the same direction for once!

WARNING : MOD USES BUILTIN #xxx - blahblah
I am not sure why this is a warning on the console? Its not a problem, how is it a warning? a warning against what? Anyone who reads this will wonder if something is broken. This is a good candidate for Dev 2 spam because mappers/modders know they are using particle query commands already. This is just confusing and misleading atm.


On a final positive note, I really love this version of QuakeSpasm. The particles are amazing, finally I can play quake with good movement code and have clouds of smoke swirl around me as I fire rockets! I highly recommend anyone from the QS team to consider merging this stuff into the main branch. It really brings maps to life with extra ambience and does not go full on crazy with eye candy.

Also on a side note, the rain/snow effects in this engine are so much better than DP!?! No more hardcoding effects, can finally customize the weather candy with unique effects! :D

Its such a shame the FTE/Spike particle system did not become the standard, because its got some really lovely features missing from DP. Its like the classic 90's battle of VHS vs Betamax and we all know how that turned out based on popularity! 
@Baker, why are you arguing for abandoning a current standard for querying clients for features?Spike explained to me why it is non-issue because of how he designed Quakespasm Spiked.

So ignore my old thoughts on that, Spike obsoleted them ;-) 
it depends how you define 'checkextension'.
Remember that there is absolutely no standard way to query the client's extensions on the server, you can only check the server's. Which generally means that the server should only advertise what it's client component also supports.
If you want to define checkextension as purely serverside, or with potential client support then yes, particlerain+snow should be advertised. On the other hand, if it should only be things that are going to work out of the box then it shouldn't be listed. Hurrah for things being more complicated than they should be!.. This wouldn't be an issue if QSS had a built-in fallback for rain/snow particles, but unfortunately the only built-in is the original/classic particles.

engine types vs engine features
it depends how far down the rabbit hole you are.
Once you're using 20 different extensions for a range of different things, its very unlikely that the mod will still be checking those extensions properly. Its also unlikely that the modder will be aware that half those features they're using are actually later extensions built upon a previous extension - like checking for pointparticles and assuming that means that 'effectinfo.txt' is also supported and parsed.
Plus many mods are too lazy to even bother to even check for extensions...
As a result, checking for QSS/QS/DP vs QS/markv/vanilla/others, makes a lot of sense (those with string support and those without). Then use individual extensions for more minor optional features, like rain volumes. The trick is in figuring out which set of extensions ensure that its safe to put it in that first group...
Either way, there does kinda need to be a way to check the engine's name and version even if its just to blacklist things - there'll always be implementation differences and bugs.

builtin warnings
its along the same lines as eg the '%i nodes exceeds standard limit of 32767.' warning.
I went for consistency rather than practicality. :)
if you cleared pr_checkextension so that mods shouldn't be able to detect any extensions, then any builtins that are used despite the apparent unavailability of any extensions are going to be an issue for compatibility reasons. Any other builtins that are being warned about are warned because the qss implementation is a stub and doesn't necessarily even do anything (its probably better than crashing on those mods that fail to check extensions properly). Otherwise users without developer set will see none of those warnings.
Tbh, I was kinda leaving half the developer warnings for someone else to tame. :)

the zip
yeah, its not organised that well. end-users just need the exe so it doesn't really need that much. The readme file isn't really aimed at end-users either, because frankly my changes arn't really aimed at them either.
I could make a clone of vanilla quakespasm's installer and by doing so obsolete it entirely, but frankly that's rude and not really what I intend to achieve with QSS, if only because I don't want to have to keep merging quakespasm's changes over to qss.
Really, the biggest issue is that it lacks all of the required dlls... So yeah, its kinda intentionally bad. :s

Its such a shame the FTE/Spike particle system did not become the standard
While mods like yours only provide DP efffects, not much is going to change that. :P
In the meantime, nothing is stoppng you from making an effect for FTE+QSS, and a fallback one for DP. You don't even need to change any QC. Hurrah for being able to plug a tape/mod into either type of player/engine. :) 
... waffle waffle waffle ...
OMG spike, that is like 2 pages of not agreeing to anything! Are you going to support check extension for rain and snow or not?

Tbh, I was kinda leaving half the developer warnings for someone else to tame. :)
Are you giving up on this engine already?

In the meantime, nothing is stoppng you from making an effect for FTE+QSS, and a fallback one for DP
You are missing the irony of my analogy, its too late! The DP particle language is standard and there is no going back in time. I am certainly not going to maintain QS particle, DP particle and FTE particle files!?! Sorry man, that moment is long gone! 
About The Rain And Flames Effects 
The rain and flames with smoke effects appear to be so great, it NEEDS to be implemented into the standard QS !

Now I'm just wondering about their implementation for old maps : will the flame effect be automatic, or be turned on in recent maps, only if they ask for it ? It should be automatic, IMO.

About the rain (and possibly snow or other effects), could it be turned on by the user, even on old maps to add more atmosphere ? I guess not, but I would like to have a confirmation. 
if I do an r6, yeah. its not like mods can do very good fallbacks anyway, so a false positive that's invisible won't do any serious harm.

regarding an r6, I'm kinda hesitant. I don't want to have to maintain a fork long term.
I've achieved the major things that I personally wanted, csqc being the only real thing that I didn't try tackling but at least that one has good reason. There are a couple of omissions like some minor builtins that I doubt anyone will use, but meh.
Regarding someone else taming the warnings, QuakeSpasm, even QSS, is not the engine that I personally favour. The final polish needs to come from someone who actually cares about the whole package, and that person isn't me.

By 'QS particles' I assume you mean sprite ones? Yeah, I can understand not wanting to support those... :P
I can disable the effectinfo support if that'll make the idea more palettable (which would be more correct with regard to your analogy)... Really the only way to get away from DP's particles is to fork DP and port over the particle system (and fix its stupidities too, hmm)... 
It would be so sweet to have DP's features implemented to QS-Spiked
If you want a quake engine with more DP features but which isn't DP, then try FTE some time.

QSS is meant to retain the QS aesthetics, but without ignoring modders/multiplayer. Bling is kinda irrelevant when other engines can already do that much better. 
regarding an r6, I'm kinda hesitant. I don't want to have to maintain a fork long term. I've achieved the major things that I personally wanted
Well that is a shame, I only plan to support weather in AD if the checkextension is active. Good luck with your next project then and exit stage left from me. 
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... :) 
Extendable Gfx.wad HUD 
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
- 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? 
Side Note 
Do not worry spike. Nobody will use fte anyhow since there is qss. 
The Carpet Is Wet ... 
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 :) 
Cruel Joke? 
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
New update, just for you sock. :) 
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...). 

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. 
Really Amazing 
I love the effect, I wish it would be come standardized. 
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. 
Ah This Is Great 
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. 
New Release - R7 
bigger maps, downloads, voip, more networking choices.


Impressive Changelog 
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) 
Also A Limit Bump Request 
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.). 
Thanks For The Heads Up 
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). 
Two oneliner fixes for demo playback:
fix for a crash
static ents not appearing in demos

That should be all that's interesting in my git branch.. the other changes are tweaks to get it to compile on my jenkins box, and merging in QS svn.
QS svn has a rewritten Host_Loadgame_f where I eliminated that fixed size buffer, which was overflowing on the DP/QSS extended savegame comments in big maps. 
Quoth / Map Jam 9 Bug 
Barnak reported this in the map jam 9 thread and I was able to reproduce:
- install map jam 9 and quoth
- launch QSS r7 with -game func_mapjam9 -quoth
- launch start.bsp and walk straight ahead through 2 teleporters.
- the loading plaque comes up, (it's loading jam9_kell) then you're kicked to the console with "Host_Error: Illegible server message 110, previous was svc_serverinfo" 
QuakeSpasm-admod Don't Have The Issue 
I'm very curious to know what is happening, since about half the maps are looading without troubles from the start map, while others don't. You can still load them all from the console. 
While We're On The Subject Of Bugs... 
in qss-admod, on some maps when I try to save, the game crashes instantly. I've noticed this in the forthcoming episode jam's start map and some of Qmaster's old maps, and it happens both with quick and hard saves. It doesn’t seem to happen with regular QS. 
< /*ent->v.modelindex = */SV_Precache_Model(com_token);
> /*ent->v.modelindex = */SV_Precache_Model(PR_GetString(ED_NewString(com_token)));

The above fix has been in the 'prer8.diff' file on triptohell for a while now.
QS isn't as mallocey as FTE, which results in precaches being empty strings, which the client interprets as terminating the precache list when the server thought it was just another string. The idea behind the change from QS being so that eg vanilla's func_illusionary could use any model it wants, but I fucked up, and then kinda gave up.
There's also new bugs in 'pre-r8' which I'd need to fix before another actual release, but I can't find the motivation to actually spend time on it. 
I've been poking around with weather effects in QSS for the past couple days, and it's going pretty well so far. I've got a nice little map-specific, texture-emitted effect worked up for what I hope to be an entry to the Xmas Jam, but I'm having a little trouble with something: is there any way to get what I can only call "preroll" on a particle effect with the FTE/QSS system? Currently the particles start spawning when the map starts, and the player can see the effect getting up to speed. I'd love some way to have it already warmed up when the player first spawns, but as far as I can tell from this thread and what documentation I've found, there's no such option.

Does anyone know how I might accomplish something like what I'm after, or am I stuck trying to trap people for a few seconds on map start so the illusion isn't broken? 
Unfortunately there's no way to do that right now. The best I can suggest is to write some QC that spawns those particles for you, however this may run foul of any future 'preroll' feature.

I guess the easiest thing to do is to start the player in a room with a closed door, with any windows being high up, thus giving your snow particles time to drop.
As well as low skies... 
Black Box It 
You could atart the player in a small box func_togglewall textured with BLACK and then target wait, killtarget a func_wall box I mean, after a short delay. This would give the impression of loading. 
If you wanted to experiment with horrific evil, you might set host_frame 9999 on map load and then set it back to 0.

Depending on what mod you are using, there may be a way to execute commands.

Something like cl_forwardspeed 0; host_framerate 9999; wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait; host_framerate 0; cl_forwardspeed 400 
Ha, Spike knows immediately it's a snow effect, well yes, the jam is Christmas themed, I couldn't resist. The existing AD snow effect (or FTE? Not sure of its origins) was a little too jittery for my taste, and didn't have the lifetime I wanted, so I made my own.

I'll have my sky as low as possible, and maybe give people a simple button pushing task to complete while everything gets going. I'd also considered some sort of centerprint backstory about arriving just as the weather was getting worse, but then in engines that don't support these particles it'd sound weird. But maybe that's a writing challenge more than anything.

I appreciate the info and ideas (especially Baker, that's exactly my type of clever, sadistic cvar abuse); thanks for the help! 
Post A Reply:
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.