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.
-----

Actual QSS engine download:
http://triptohell.info/moodles/qss/

-----

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

1. Video of snow: https://youtu.be/DvqxsJChXH0
2. Video of rain: https://youtu.be/NRud8T88tDc

Steps:

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".

Stuff:

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"
}


A devkit is also available HERE http://fte.triptohell.info/moodles/qss/QSS_DevKit.zip with source code examples of how to create your own custom HUD using CSQC. The examples show CSQC recreations of the classic HUD as well as variations for the missionpacks and should serve as a good starting point for your own creations. There's a few other goodies in there too (e.g. particle stuff), so check the readme inside the devkit.
Alpha Masked Model Support - How They Work 
Alpha masked models are supported --- texture transparency for trees, brushy stuff, etc.

Screenshot

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 
 
Woo 
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 ?
https://sourceforge.net/projects/quakespasm/files/Community/
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.
 
@Kinn 
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. 
Baker 
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.

Source 
@kinn 
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:

http://fte.triptohell.info/wiki/index.php/ParticleFields



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: https://youtu.be/4BTywfBdbRc

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. 
R4 
http://triptohell.info/moodles/junk/quakespasm-spike-r4.zip

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. 
./particles 
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 
R4 
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. 
:O 
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.
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 
@Mugwump 
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? 
Icaro 
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?

@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? 
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. 
 
@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. 
R5 
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. 
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.
etc.

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: https://github.com/ericwa/Quakespasm/tree/spiked
It builds and runs fine on macOS 10.12, btw, once I added the new .c files to the xcode project. 
 
@baker
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...

@ericw
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 
https://i.imgur.com/RpnGmsP.png

Im so fucking sold. 
 
Is that a Doom 3 inspired tileset? 
Yes 
Some maps made in that set already:

https://www.quaddicted.com/reviews/?filtered=doom3 
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! 
@sock 
@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 ;-) 
@sock 
checkextension</>
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. :) 
@Spike 
... 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. 
@sock 
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)... 
@QuakePone 
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. 
@Spike 
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 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? 
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
http://triptohell.info/moodles/this_is_not_a_cruel_joke/honest/quakespasm-spike-r6.zip
New update, just for you sock. :) 
LOL 
 
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...). 
R6 
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. 
Really Amazing 
I love the effect, I wish it would be come standardized.

https://www.youtube.com/watch?v=aHCocIjeWuw&feature=youtu.be 
Great 
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 
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 
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. 
Bug 
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.. 
@ericw 
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. 
@ericw 
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. 
Pr_edict.c 
901c901
< /*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 it...er 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 
Thanks! 
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! 
FTE Software-like Rendering 
Is there any chance of including the "software" style rendering that FTE has?

I just had a look at this in FTE and it's exactly what I'm after :D 
 
if you want to use fte's features then use fte.
if you don't do so then you're showing that it doesn't mean much to you. and if you do switch then rewriting it would have been pointless.

so no, no chance.
if someone implements it into QS then it'll get merged eventually (and I won't have to deal with extra merge conflicts). otherwise its not something that I'm going to waste my time with.

the point of QSS is to make something that the 'community' might accept that doesn't leave the people creating stuff with their hands tied behind their backs.
that's why it has qc extensions, md3s, removed limits, and better network compatibility.
note that even the particle system is aimed at mods like ad rather than the end-user.

and its actually kinda rude for people to keep asking for only a fraction of my stuff.
Its also a joke that people keep on insisting on using quakespasm because its somehow 'faithful' while being less faithful than the engines that they apparently shun.
Its not just software banding either, and I'm actually getting pissed off about it.
The entire thing is a massive counter-productive joke.
The point of QSS is to try to reduce the stagnation, its there so that people can create without being held back, rather than for the end-user themselves, that's why it does nothing as little as possible to change the feel of the engine, and yet so much for potential creators.

Adding user-centric features like ugly banding is simply not part of that goal.

So no, I won't port the code. I've no problems with merging it from Quakespasm if someone else wants to port it, but I'm not going to spend my time writing all that stuff myself. 
 
Ok, point taken.

The reason I'm requesting a "software rendered" look in QS isn't because I'm trying to add extra spangles and shininess and bloat to QS; it's quite the opposite.

I think of QS as the ultimate "faithful" quake engine, and I think adding an emulation of the glorious (not "ugly", it's beautiful and glorious) software look is something that fits the "faithful" quake spirit perfectly.

Hell, I'd play everything in an actual software engine in a heartbeat, if one of them could run a modern ad-style megamap at a decent framerate, but alas that's not possible, so emulating the software look in hardware is the way to go.

Anyway, I'm not gonna push it any more, I'l just keep quietly wearing ericw down I guess until he submits :) 
 
Why not use FTE, really?

Spike is going to burst a vessel one of these days, maybe we can head that off by bullet-listing a few things that are blocking FTE adoption. 
 
It might be a case of momentum. I mean, AD comes with a recommendation (and link) to use Quakespasm and since AD is basically default Quake now ... 
 
Why not use FTE, really?

FTE is close, and r_softwarebanding is sublime, but there's a few things that bother me and make QS still my go-to engine:

- In FTE, even in "classic" particle mode, particles are too bright (so are sprites)
- Models are shaded differently and are generally too dark - this looks especially problematic with things like the AD health pickup items.
- I don't know how to turn off coloured rocket, explosion etc. coloured lighting (can I?)
- Underwater sound is all different (is there an option to control this?)
- No controller support (yeah, yeah, I know)

There's lots of other little niggles and nitpicks that I don't really want to bang on about, like the exact details of how the menus and fonts look etc. etc, but you get the idea - point is I'm a purist and I will always tend towards the engine that looks the most accurate in my opinion. 
Just To Clarify 
I am NOT asking spike to implement any of that stuff just to please me (lesson, learned oh boy), I'm just answering Johnny Law's question. 
@Kinn, #116 
I suspect I ought to post this in the FTE thread instead, but I guess its a comparison between engines, so whereever...

sprite lighting differences - these are just drawn fullbright, so I don't see how there can be any difference. that goes for particles too, but to a lesser extent obviously. overbrights are not normally used on either of these, so no idea. comparing screenshots show the sprites at the same lighting level. maybe its just your imagination on account of dlight colours?
note that square particles have more coverage - and the result is more like software's rendering than QS as far as I can tell.

models - software banding applies to models too.
personally I think its QS's modes that are too bright - they're almost unshaded. but yeah, fte's models end up too dark in one direction and fine from the others. ironically fte follows ezquake in qw deathmatch and they all get fullbright... ho hum.
/me does a four-way comparison between various engines... quakespasm has double-brightness models (seriuosly, I check relative to glquake)! what happened to the lighting vectors? no shadows, no sense of depth, urgh.
imho of the three non-sw engines, fte was the closest to software rendering's model light levels - and quakespasm the worst.
so that's another thing to fling at the community when they claim quakespasm is somehow more faithful.

dlight colours - use r_dynamic 2. this should already be part of the appropriate presets. it still seems a little darker than software rendering, but so does qs so that's just an old config that predates the setting being added to the presets I guess.
(note: fte has some code to avoid over-saturation and loss of colour tone, which is kinda significant with eg q2 or bright blue quad glows, so darker is at least justifiable from that perspective)

underwater sound - switch audio driver to alsa or directsound, or anything other than openal (the menus should give many driver+device options). openal's reverb effects are nice and all (which is how come I got harassed into setting it by default), but yeah, openal sounds different from vanilla.

controller support - wut? fte has controller support. on windows set in_xinput 1;in_restart. its actually the default (now, since a few months ago, hurrah for lingering config settings). splitscreen without controller support would be awkward.

menus - not clunky enough? too small? or what? mouse support! zomg! or just so cluttered that noone has a clue what's actually in there... if it helps I hate designing UIs. Users always have different impressions of how its meant to be used... hence presets, so they don't have much of a choice. mwahahaha. But yeah, I admit that the options menu is a little hard to navigate on account of all the somewhat random options, and yes I personally tend to just use the console instead of trying to find whatever option it is... the apropos (aka: find, yes baker.) command is often faster, at least if you know part of the name... and yes I do unfortunately have to admit to grepping the sourcecode to find cvar names sometimes. :(

fonts - try r_font_linear 0;vid_reload, probably. personally I think that's ugly (especially with high res fonts, but whatever, if its what you're used to then its what you're used to, but I guess if you're trying to mimic sw there too then remember that software had clean scaling [while QS's defaults are not] so no half pixel weirdness[which linear sampling helps to hide]). it'd be nice if people would use truetype fonts so this stuff becomes (mostly) irrelevant, but oh well. linear filtering is at least the safer bet still, and legibility beats all else when it comes to text. 
 
Yeah I don't think you should worry about "banging on" :-) ... I did ask, and I think it's worth getting particulars out in the open if people (not just Spike) are going to keep saying that FTE should be used as the go-to engine for SP. And there's some people (not Spike) who rant about a conspiracy or at least a circlejerk keeping everyone holding onto Quakespasm, but I'm pretty sure that's not the whole story. 
 
(#119 was for Kinn obv) 
FTE 
sprite lighting differences - these are just drawn fullbright, so I don't see how there can be any difference. that goes for particles too, but to a lesser extent obviously. overbrights are not normally used on either of these, so no idea. comparing screenshots show the sprites at the same lighting level. maybe its just your imagination on account of dlight colours?

These shots show what I mean - all particles are brighter and sprites get their colours blown out.

https://i.imgur.com/XFRHlYv.png
https://i.imgur.com/JJOlj7m.png
https://i.imgur.com/qqJKqAm.png

quakespasm has double-brightness models (seriuosly, I check relative to glquake)

glquake has dull models. FitzQuake (and descendents) changed the model lighting to resemble the original software quake. However.....

https://i.imgur.com/LYXwYIH.png

The above is really interesting - it shows QS is pretty close to vanilla software quake (but is actually a little bit too bright), but FTE is a bit too dark in comparison and the models do disappear into the scenery. I don't mind it too much, but some custom models that are designed with QS in mind (like some of the AD models, e.g. pickup items) tend to disappear a bit sometimes.

But what about from the back?

https://i.imgur.com/dE5NhAm.png

FTE is very close now (in accordance to what you said about the models only being too dark from certain angles). QS is like the front shot - close but actually a little bit too bright.

I'll answer the rest of your points tomorrow (I have to go bed now) but I still can't get the dynamic lights non-orange, or the controller to work (which I'm sure is more my fault than yours) 
Historic Note. 
http://celephais.net/board/view_thread.php?id=60133&start=35&end=43

It would appear that Fitzquake, and therefore Quakespasm, (in its emulation of the original Winquake), ended up making overbright models slightly too bright than intended. 
 
WinQuake uses a variable amount of ambient lighting, plus a fixed amount of directional lighting.

The amount of directional lighting is very small, just enough to give the model some depth without evidencing the direction of the light. They made it this subtle because since the lightmaps doesn't store any angles, there was no quick way to rotate the directional lighting of the models towards the origin of the lights.

Plus, WinQuake also ensures a minimum ambient light value of 20 to viewmodels only. I don't remember if this minimum value is clamped or added, though. 
Spike 
There's something on the FTE website that my ISP doesn't like. I have to use a proxy to even visit. It gets flagged as dangerous from Virgin. 
 
dlight colours - use r_dynamic 2

Doesn't seem to make any difference - it's still orange. All I'm talking about is an option of reverting to the white light of vanilla quake. Minor quibble, but the orange just feels a bit out of place in classic maps.

underwater sound - switch audio driver to alsa or directsound, or anything other than openal

Thanks - setting it to directsound via the menu seemed to fix that. Is there a command I can put in my config file for that?

in_xinput 1;in_restart

Didn't know about that, but in any case I can't get it to work with my XBox 360 controller. All that does is make the screen vibrate crazily and lock my view to the floor.

menu / fonts - I may talk about that another time, it's not terribly important. 
Found A Bug In FTE 
Tried to use delete to remove binds but it hard crashes to desktop.

Why doesn't FTE use an external .cfg file? I want to know what I am editing.

I also get the same problem as Kinn. My view shakes and locks to the floor. Control input is broken as far as I can tell. When I try to rebind in the menu it doesn't allow it. 
FTE Controller Binds 
DPAD = movement up/down/left/right

Left Stick =
moving left or right throws the view down, if you push up or down very lightly you can turn left or right.

Right Stick = pulling back moves diagonal forward, pushing forward moves diagonal back. RS also controls swim up/down respectively.


Right Trigger = Stops the view shaking

Nothing is bound to shoot, jump, change weapon, view center (centerview command is also not recognised despite being a default game command).


Yeahhhhhh.... Maybe steal EricW's controller input and allow binding for separate pads in the rebind menu? 
 
Why doesn't FTE use an external .cfg file

I just discover FTE dumps a ton of cfg stuff in C:\Users\[you]\Documents\My Games\FTE QuakeWorld

instead of the traditional place where you installed your quake 
FTE Hangups 
That last one is particularly egregious. I hate it when software thinks it's ok to hide data in other folders.

Does FTE support fence textures?
Does FTE support Orl maps?
Does FTE support AD Sepulchre and Swampy?
Does FTE have an option to use standard Quake physics instead of Quakeworld physics?

I thought QS and this QSS were the only engines that supported AD fully and the Orl megamaps? 
Non-base Directories 
I dislike that behavior that too. maybe -nohome or -disablehomedir 0 will do the trick. 
I Meant -disablehomedir 1 
 
FTE Feedback 
Hopefully the controller feedback can be taken on-board. Splitscreen is one of those things that I have been wanting to use for years.

I just have no idea how this is supposed to work with pads in FTE, what am I doing wrong here?
If I am not doing anything wrong then how can it be fixed? 
 
if you want to use fte's features then use fte.
if you don't do so then you're showing that it doesn't mean much to you.
[...]
and its actually kinda rude for people to keep asking for only a fraction of my stuff.


I really know that feeling.

I was really happy when QBism forked Makaqu 1.3 into Super8, and actively worked on it. That kind of thing is very rare to happen.

More often than not, other coders just looked at the engine from the surface, and only copied the features that were too evident to miss. There are tons of little improvements that are too subtle to be noticed without analyzing the code or which belongs to parts of the engine that most people don't care enough to notice.

And then we get people trying to solve things which we had already solved in our engines, but they didn't know because the only thing they cared about in our engines was just a couple of features.

After years of seeing this happen, I've realized that there was no reason to try to code my improvements in a minimalistic way to ensure ease of portability to other engines, because the truth is that almost no one will ever care.

When the Quake engine source code was released, everyone was curious to know how many kinds of cutting-edge features people could add to it, to make it not seem old in comparison to more modern games. Nowadays, what people want in comparison to vanilla Quake is for the engines to handle larger amounts of the same things that vanilla Quake handled.

There isn't much of an audience for technological innovations in Quake anymore. Rather than getting excited by them, people will usually get annoyed.

menus - not clunky enough? too small? or what? mouse support! zomg! or just so cluttered that noone has a clue what's actually in there... if it helps I hate designing UIs.

Well-designed UIs can have lots of options without feeling cluttered. The key is to figure out how to better categorize the information and organize its flow so the user don't get lost.

But yeah, designing UIs is an art form in itself, which requires lots of boring practice. 
 
Nowadays, what people want in comparison to vanilla Quake is for the engines to handle larger amounts of the same things that vanilla Quake handled.

That's an excellent observation and I think it's spot on. The community has transitioned from adding flashy stuff to Quake to wanting original flavor Quake - but in larger doses. Huge maps, fast rendering, quicker compiling, and so on, while still maintaining the software rendered look that makes Quake what it is.

I guess it's somewhat like car enthusiasts who covet classic cars. Eventually things become old enough that you get people who want the original again. 
 
It feels like a natural progression.

The Commodore 64 scene progressed in the same way. Initially there were add-on boards and such that added speed and memory to the base computer but, over time, demo scene coders transitioned back to the base machine and starting extracting as much power as they could from it.

There's stuff being done today on that machine that I never would have guessed possible. 
FTE, And Stuff 
@FifthElephant, Kinn
I had PrimalLove take a look at the xinput stuff (I don't have a controller myself, hence the prior b0rkedness). Hopefully it should be more acceptable now.
Note that you may still need to do 'cvarreset joy*' if any previous settings got saved to a config. Be sure to use a test release (ie: 5197+).

@Kinn
I found a bug in the defaultmodel.glsl code where it was computing a value and then discarding it, resulting in extra darkness, so that should be fixed now. It should be much closer to sw rendering (especially with r_softwarebanding enabled).

@Kinn
The double-brightness particles+sprites I couldn't reproduce.
the r_dynamic 2 setting not working is only a thing with the 'stable' build from 6 months ago - give the testing build a go instead, where its actually supported.




In other news (that's actually on topic), I have a QSS build that can run CSQC.
It has a number of intentional limitations that make it simpler to implement, but it should be ideal for custom huds/scoreboards/intermission/menus (read: 2d-only CSQC_DrawHud entry point, instead of CSQC_UpdateView with all its 3d nonsense).
When I get around to releasing it, I'll include an example hud, with some extra code to deal with DP's different expectations (FTE will be promiscuous).
For now though, there's still a number of issues that I need to resolve, primarily in the input handling stuff (for custom menus - quakespasm's mouse logic is not being too friendly). The current issue is how/whether to deal with fte's splitscreen feature - not that this is really a Quakespasm issue of course, I just want to avoid shooting myself in the foot as it were.
Probably nothing will come of it due to whatever, but without hope all we have is despair, or something *starts mumbling*. 
Spike 
Cheers, I've just tried the latest FTE test build and the models look identical to WinQuake now (I even did a super-pedantic screenshot test). Sprites and particles also appear correct too. So, right now, I can make FTE look closer to WinQuake than any other hardware-powered engine I think!

I'll have a look at the controller stuff when I get home. 
 
Even software rendered engine that added flashy stuff to be on hardware engine level get ignored in the end. super 8, engoo, makaqu all dead 
Bump. 
 
@Kinn 
you mentioned once that CSQC for custom HUDs could be coming for QSS - is this still planned?
I've committed what I have to github. It should mostly work (if you compile it yourself), but its not perfect.

For it to be useful, it needs a clean example/base mod that people can use to do cool stuff without needing to figure it all out from scratch. I don't plan on releasing updated engine binaries only once that's actually done, because I don't see any real point without and it would risk people complaining about obvious already-fixed bugs.
Really it just needs polish. Lots of it. Hence why I haven't bothered to do anything with it for a while now. 
Spike 
Cheers for the info. I'll have a tinker at some point. 
QSS R9 Released - Simple CSQC 
Get it from here:
http://fte.triptohell.info/moodles/qss/
(linux+mac users will need to compile their own).

This release adds support for a cut-down version of CSQC that allows for mod-created huds (but not fancy 3d stuff). Requires a compatible hud however.



Boring technical junk:
I uploaded a preliminary(read: probably buggy) qc dev-kit to that site too. Inside you can find a simplecsqc/src/csprogs_simple.src file.
Compile that with fteqcc (set up a file association or something) and you'll get a csprogs.dat that'll be understood by QSS+FTE+DP (cl_sbar 0 for a qw hud, or 2 for n64quake style, as an easy way to see that its actually doing something new). You can edit the csqc_hud_vanilla.qc file to do your own mod-specific things.
You can use clientstat from ssqc to register custom stats (starting from slot 32) in order to provide mod-specific fields to your csqc that can then be read with getstatf. You'll probably want to share your constants between both modules... Magic numbers are evil.
(I also knocked up some other files to provide hipnotic/rogue huds too. I guess that might be useful to quoth perhaps but probably noone else will care.)
Alternatively, you can just directly add the csqc_hud_vanilla.qc to the end of your ssqc src. Doing so will not give you a working hud in DP (so I don't recommend this), but will work in QSS+FTE (unless there's an explicit csprogs.dat, which takes precedence). Don't expect to be able to directly poke ssqc data though, it might be the same .dat but its a different qcvm.

Constructive feedback welcome. 
Wow 
I will give this a rumble as soon as I can.

Just want to say thanks, this really opens up the possibilities. 
 
Hi, I'm afraid I'm getting a little crashette when I load up AD in this new build and fire the shotgun. I assume particle related? 
@Spike 
It's great to see this updated again. I'm prepping a video on source ports so I will add this to the mix. Questions tho. Is QSS a side project or is it starting to take over FTE? I'd just like to know a bit more history and have more context so I can communicate that in the video. And BTW the video is a few weeks away but on the to-do list. 
 
@Kinn
Sorry, stupid oversight (due to csqc/ssqc abstraction). I updated the zips to fix that.

@dumptruck_ds
QSS is still just a side project.
It was born out of frustration with engines like QuakeSpasm ignoring everything but vanilla-ish maps, hence QSS's focus on networking+modding capabilities (while otherwise trying to feel the same). 
@Spike 
AWESOME!..I'll have to test this out.

@dumptruck, make sure you emphasize how DarkPlaces is NOT a proper port since it doesn't have the twisty water effect.

Keep em coming! Both of you. ;) 
 
Man if we throw out every engine that doesn't have twisty water, that's a lot of babies being tossed out with that bathwater. :-)

There's a lot of tradeoffs that come up when you get into engines-talk. Like,
with DP you get hit with changes to lighting and movement if you're interested in vanilla-ish singleplayer, but if you really want to go hog wild with replacement media it's the main vehicle for that.

For singleplayer stuff like dumptruck is focussing on, I'd be tempted to say that most folks should just use whatever engine the mapper created/tested the map on. If you later get into being an enthusiast of tricked-out engines like FTE you can learn to work around the occasional gotcha (like the Quoth thing being discussed on some other thread). 
FTEQCC 
Hi Spike, slightly different topic but where's the most complete documentation for fteqcc located?

Would it be here? http://fte.triptohell.info/wiki/index.php/Main_Page#FTE_QuakeC_Compiler

Also thanks for the QSS fix, appears to be fine now in AD, cheers :) 
Disable QSS-specific Effects 
Forgive my ignorance, but how do I disable the fancy effects I get in conjunction with Arcane Dimensions? Renaming the effectinfo.txt seems to work, but I get error messages when any projectile impacts a wall. I don't like switching to normal Quakespasm for that, because it lacks features like set/seta, which are a godsend. 
 
@Kinn
Sorry, I never got around to writing proper docs for fteqcc. Someone else beat me to it, so there never seemed much point. Admittedly those prior docs are woefully out of date now, but hey...
Basically, C syntax is meant to work, unless it conflicts with existing QC syntax.
The options dialog of fteqcc should document the basic idea of most compiler flags.

@DabbingSquidward
If you set pr_checkextensions to 0, then AD will no longer be able to detect any QC extensions at all, and will thus use its entity-based particles instead (the exact same behaviour as in regular Quakespasm).
(Unfortunately AD has no way to select between entity particles and engine particles - if it thinks that it can use engine particles, it WILL use them.)
IIRC, the other option is to set temp1 to 1024, which will disable AD's engine+entity particles alike. 
Bug REPORT 
Using the provided updated fteqccgui.exe, anytime you edit a .qc file within the program it causes EOF errors.

Reproduce:
Add a variable that isn't used anywhere into a def file.
Compile.
Double click on the warning for no references.
In the subwindow that pops up, comment out a variable.
Compile again.
Witness the ERROR EOF detected in comment of file. 
BUG Report 
Using the provided fteqccgui.exe (ONLY one with support for compiling the csqc files which is why I'm considering this a bug report related to QSS), I get multiple erroneous no reference warnings for variables. After commenting out the related variable, I get numerous errors for not having defined that variable.

FYI. 
Qcc 
'EOF inside comment' means that there as a multi-line comment that wasn't terminated.
//single line comment
/*unterminated multiline comment that will hit eof
otherwise I've no idea what you're actually doing, and thus no idea how to reproduce.

Regarding unreferenced variable warnings, I'm going to need a proper example/more info.
If you're using '#pragma sourcefile' then remember that its compiling your code twice, and variables that are unused in your csqc are likely NOT unused in your ssqc (and vice versa).
If you're lazy, you can use the __unused modifier to just mute the warnings, but I wouldn't recommend doing so with fields. 
 
Eof: Simply using // to comment out variable definitions e.g.:
// .float gorging;
Which then gives me that error for EOF on that line, but only if I add // inside FTEQCC's gui editor. If I add // in Notepad it's fine.

Unreferenced warnings (about 133 for my project) are showing that a variable is not used in this new version while the older version of fteqccgui has 0 warnings. The "unused" variables are clearly used by the code so some check must be either not parsing all files or failing to parse all files to see if they are used.

Tested without csqc and no #pragmas. 
 
the 'EOF inside comment' error message is specific to multiline comments, and I have absolutely no explanation that would not be accompanied with a 'file contains null bytes' warning.
All I can really say is that there's more going on here than it seems, and I've no idea how to reproduce it.
The second bug is quite probably the same root cause as the first.

If editing your code works in notepad then you may have to just stick with notepad. You can get a commandline-only version of fteqcc here: http://fte.triptohell.info/moodles/fteqcc/
There's also some docs there for fteqcc's extra syntax, if anyone needs it. 
Ya 
I'll have to play with it more later and try to narrow it down. Thanks though. 
@spike 
what does it mean the console output

disabling rendering/network isolation 
@Spy 
Its a slight rework to host_maxfps.
Its enabled when above host_maxfps is above 72(or 0), and ensures that c2s packets as well as the server itself are throttled to no more than 72 fps without throttling the client too.

This means you can set host_maxfps to whatever you want and no longer get any physics issues because of it. Like all the other engines that already fixed it...

I should probably just remove the prints, at least once I'm sure it all works properly. I don't really expect any issues, I'm just paranoid. 
I See 
btw. for some reason i got this rendering borkage (the grey screen)while i'm running the frogbot mod with qss
http://quaketastic.com/files/screen_shots/spasm0000.JPG 
Wait What!! 
You should advertise that in the main post or something.

-Attention all those who own a fancy-schmancy high fps monitor! QSS/FTE now have a fix for high framerate physics bugs! Rejoice-

I would test in glee, except my poor-man monitors are stuck in the 90's. 
High Fps Normal Physics 
If it works flawlessly, would definitely join the tier 1 level of enhancements that improved the Quake experience.

It is a great thing that Spike has become more and more immersed in the world of traditional single player Quake.

(And this implementation is the least complicated one I've seen. I saw something about "bf" timing. Ironically, mh's implementation for allowing high fps normal physics had lots of comments addressing bonus flashes, I can't recall if he addressed that -- I think he did and it required an extra clock at a minimum.)

/I read the code 2-3 hours ago because I had a "WTF??" moment when reading that. 
 
I tested it a little bit last week on a 165Hz monitor and it looked/felt amazing. Agreed, this is a big deal! Check it out of you have a >60Hz monitor. (host_maxfps 0 = uncapped.)

The particle production rate was visibly a bit off @165Hz, but this is a well know issue discussed on insideqc. 
 
I ran it through a few input scenarios that I thought might be able to "mess it up" but not seeing any juttering with some stuff that used to very subtley trip up DirectQ's implementation.

Also did a quick test connecting to an online server to see how it behaved.

Everything looked and felt completely normal and fine.

Spike+++++++++ 
Regarding Future Implementation In QS Vanilla 
my IRC update code gets called from the _host_frame code in host.c

Is it likely that I'm going to have to significantly change the way I'm calling this when the physics and framerate are separated? 
 
A friend of mine would like to run Quake on 144hz monitor, but with 72fps physics. Using QSS by default the game run @ 144fps, and that does changes physics a lot. How to set original Quake physics while having 144fps ? 
@spike @Qmaster Re: Code Parsing Fuckups 
Hm,so the code works when written in Notepad but not in the actual editor? I had the exact opposite thing happen to me recently when trying to add entity information to a config file in a Doom mapping program I use, so I wonder, was this program originally written for Unix compliant OSes (Linux Mac etc) or Windows? The text parser might be expecting DOS-format end of line characters and not getting them, either that or there's a bug in the code that is searching for the end of comment delimiter, I haven't looked at the code yet so I'm not sure which is the case but that is probably where I would check first. Then again I am a pretty inexperienced coder so maybe you shouldn't take my advice 😂😂 
 
@Shamblernaut
The specific patch is quite small, and if you're doing something that's sensitive to framerates that that would exist regardless of the rate at which the server runs at. So no, just the usual potential-but-trivial merge conflicts.

@nemo
QSS ALWAYS limits its physics to 72fps or less, regardless of video framerates, so its nothing to worry about with the latest QSS.
Just set host_maxfps to 0 and enable vsync and you're fine (usually - nvidia drivers seem to have issues with vsync and otherwise-high framerates).
If physics feels different then it'll be purely down to the interpolation (or if you're more familiar with higher rates - which are generally considered buggy).
I didn't add any settings to limit physics to eg 20fps as is the default on many dedicated servers. my aim was purely to smooth out the single player experience, and I personally hate 20fps anyway.

@anon
fteqcc accepts windows, unix, and supposedly also mac line endings, which is meant to match scintilla's behaviour also.
note that support for mac endings means that rogue's sourcecode does not compile as-is due to a mac line ending appearing in the middle of a single-line comment, and these being line endings means the next line contains uncompilable gibberish.
this is why I've configured fteqcc's text editor parts (a third party widget called scintilla) to display explicit line ending chars if they appear to be mixed.
While fteqcc attempts to support various types of unicode encoding, it only considers the ascii chars as whitespace, so chars like non-breaking spaces that you might have pasted in will confuse the compiler but might be invisible in the editor.
Any non-ascii codepoints are pretty much ignored - they're accepted in names, and any non-ascii chars inside strings will be treated the same way as they always have - needing eg com_parseutf8 1 in order to display them properly in-game (instead of as multiple random red glyphs). As an english speaker that's also quite lazy, this hasn't got much real-world testing, just specific cases that required annoying copy+pasted glyphs that I can't even read, so it wouldn't surprise me if the unicode crap is completely unworkable as-is.
It'd be nice to have an actual copy of a bugged file so that I can figure out which chars are actually in there, otherwise I have absolutely no idea how to progress (and I'm too lazy/paranoid to try fiddling with my system locale etc to try to reproduce it). 
More Testing 
Because I can't use the CSQC without using the new compiler version and I really like being able to edit within FTEQCCGUI for quick simple fixes so testing to help us fix this....

If I compile code that has a warning for a variable that isn't used anywhere, then // it out inside FTEQCCGUI, then compile, I get the warning about EOF in a comment on that line:
•If I then A close FTEQCCGUI, reopen and recompile, the file change is not saved (add popup warning to save edits?).
•Or If I then B manually save the file with // added within FTEQCCGUI from FTEQCCGUI's File->Save, close FTEQCCGUI, reopen, recompile, I no longer have the EOF warning.

Hmm...
If I open the same file within FTEQCCGUI and delete the // for that variable, then recompile, I get the EOF error again. I could have sworn the older version auto-saved any in-FTEQCCGUI edits before compiling, but it seems like something is screwy with that......

AHH!! THAT'S IT!
If I change the file within FTEQCCGUI, SAVE IT!!, then compile, then I get no errors. That's the bug, auto-save-all before compile is disabled. Can you please add that back or at least add a warning or prompt to "Save files before compiling?"

Still wierd how if I don't save before compiling, then compile, get error, then save, then compile, the error is still there. 
World Size Limit 
What is the proper way to compile big maps for quakespasm-spiked ? The default world size limit in Quake 1996 is 4096 units. Quakespasm/jackhammer is 8192 units (beyond that limit some bugs occurs in the game, even in QSS). If I go with higher limits (16384, 32768, 65536, 131072, 262144) ericw tools don't want to compile the map. Thanks 
Afaik 
ter-shibboleth world is 65536 units,

not sure, but prolly you have to add -bsp2(or something) switch to your command line 
@ericw Tools Says 
-bsp2

Create the output BSP file in BSP2 format. Allows the creation of much larger and more complex maps than the original BSP 29 format). 
Escaping The +- 4096 Bounds 
sv_protocol 999
gl_farclip 100000 (or whatever you need)

does bsp2 have anything to do with this, other than indirectly? (i.e. bigger maps - more leafs, clipnodes etc.) 
 
BSP2 has nothing to do with the bounds. 
Yeah Thought So. 
 
There Is A Bound Limit On Bsp29 
Node bounds in bsp29 are int16_t so all of the coordinates have to be within -32768 to 32767; bsp2 changes these to float.

Not all engines use this value (fitzquake family doesn't) but winquake/glquake do use it for culling, and it would totally break rendering in those engines if you overflowed the coordinates, so it should probably be a hard qbsp error.

(talked to nemo on discord and I think he solved the issue, was too many verts on a sky polygon) 
 
thanks for the replies, i got it all !
huge maps are so cool... 
Misaligned Lumps 
Just installed QSS and im getting errors in the console about ammo crate bps misaligned lumps. No idea what that means, and I didn't get those errors in original QS... 
With A Mod? 
Which level? I don't see any with id1 / e1m1, for example.

I get some for breakables in ad 1.70 patch 1 (maps/ad_brk/wood01-4.bsp)

It indicates a bug with the qbsp or other tool that wrote the .bsp file. 
 
Yeah, it's custom bsp's I had installed for the ammoboxes, regular Quakespasm seems fine with them, as does QSS, except QSS pastes the error in the console 
 
the warning is new to QSS and won't get displayed in QS.

if its your map/bmodel then update your tools, otherwise just ignore it. it won't affect the vast majority of people so w/e.

(any maps/bmodels that get warned about will give crashes if you try running them on android/ios/rpi, or really ANY non-x86 cpu. which means that its really easy to fail to notice when tools write out buggy files - I was guilty of it too with fteqcc a while back). 
Projectile Reflection 
I'm a beginner at QuakeC, and I want to make a weapon that works like the airblast from Pyro's flamethrower from Team Fortress 2.
The airblast can reflect projectiles and launch players away depending on where the player's aiming it, here's how the hit detection is done in TF2:

https://www.youtube.com/watch?v=W1g2x4b_Byg&t=13s

I suppose it would be easy to replicate this in QuakeC, I'd just need to spawn an entity with its center offset to the player and in the direction he's aiming. But this has its problems (and they're present in TF2 and shown in the video), from what I've read Quake doesn't rotate hitboxes, and this will produce some really strange situations if the player is reflecting at an angle.
Is it possible to check collisions in a cone in QuakeC? If it is, I suppose I'll have to implement the math by myself.
Are there any other alternatives? 
 
findradius will get things within a sphere, that might be less bad than an AABB

you could also math it up yourself to get a cone, by testing angle between the airblast's forward vector and the vector from the airblast's origin to the incoming projectile.

However, a sphere might be better and i would size it big enough to be more forgiving to the player -- false positives are better than false negatives in this case i think. 
@Torgo 
Not sure if the source is out there but there was a weapon called the AirFist in the Painkeep mod. It was also a stand alone mod released as a promotion for Painkeep IIRC. It's been over 20 years. But it was very cool back in the day.

+1 for making new stuff for Quake 
 
Yah AirFist was the first thing I thought of too. :-) We ran that for a while on one of the kitty1.stanford.edu servers back in the day.

Looks like it can still be got here: https://www.quaddicted.com/files/idgames2/quakec/weapons/airfist1.zip

...and that does include the QuakeC source code.

(not sure if there was ever another release after version 1) 
 
BTW Torgo, that's just nostalgia coming through... we're not trying to dissuade you from making something new along those lines.

It's always cool to be able to look through a relevant codebase though, especially if you're just starting out with something as idiosyncratic as QuakeC. 
@Torgo 
I agree with Johnny. I am new to QuakeC too so any existing code to look at is a godsend! 
 
Thanks for the help guys, I'm really against discovering the wheel again, so existing code helps a lot.

Also, I really appreciate your videos dumptruck_ds, it's actually the reason I started messing with Quake. 
You Might Need... 
Extras_r4 has some fancy particle effects, in particular it turns nails and rockets into 'particle' objects that react to forces. That mod has a cool gravity well thing that pulls nails and rockets away. Could be used to do the reverse.

http://www.quaketastic.com/files/single_player/mods/extras_r4_fixed_saves.zip 
@Torgo 
Thanks for saying that, makes my day!

There's a newer version of extras now that Khreathor fixed up. I'd suggest that. The source is included in uwjam. See here:

http://www.celephais.net/board/view_thread.php?id=61613 
 
just curious why on the first post it is raining inside?

2. Video of rain: https://youtu.be/NRud8T88tDc 
@R00k 
maybe baker was curious as to whether the floor entity thing would cause the splash effect too (not my video, and I don't remember what state I left my examples in). 
Traceline And Texture Questions 
I'm trying to check what texture is below the player when he walks, then I'll change the sound of his steps depending on the texture.
I found this function in fteextensions:

string(entity e, float s) getsurfacetexture

So I thought that I should use traceline to get an entity below the player to get its texture:

traceline (self.origin, self.origin + '0 0 -40', 0, self);

But trace_ent always returns world.
I'm almost positive I'm doing everything wrong here, that traceline only interacts with entities and not the map itself.
Any ideas? 
 
Yeah, I was completely wrong.
Just do this:


local float surfnum = getsurfacenearpoint(world, self.origin + '0 0 -40');
local string s = getsurfacetexture(world, surfnum);
sprint(self, s); 
Missing Textures On Models 
Textures for models used with DP do not affected in QSS. Models still grey.
How to solve an issue? 
Post A Reply:
Name:
Title:
Body:
message
question
exclamation
idea
flame
noflame
error
skull
beer
moon
pent
rocket
sheep
pacman
pig
cheese
worldcraft
gauntlet
crate
pitfall
pimp
smile
cool
sad
frown
oi
yay
tongue
evil
wink
neutral
q1
q2
q3
ut
hl
cs
doom
dkt
serious
cube
Website copyright © 2002-2018 John Fitzgibbons. All posts are copyright their respective authors.