Spitting obvious nonsense and/or insults is the lowest form of trolling. 

not for the initial discussion, but certainly for what it evolved into. 

I'm sure there's an argument in that statement somewhere, whether or not it is real. Right? 

Is it possible to switch different fog color or overall settings which support different moods? Yes I was thinking of Quoth when it comes to logic gates yet sending console commands during gameplay, but personally I wanted get back into AD modding too. I guess this hasn't to do much with the engine in this case, but it should support these features I know or might not know yet. 

AD lets you change fog colors. 

SolidClass base(TrigOFF,Targetname,Target) flags(Angle)
= trigger_fog : "Trigger Fog" [
speed(integer) : "Time to fade (-1=Instant)"
wait(choices) : "Wait before reset" = [
-1 : "Trigger Once"
0 : "Always reset"
2 : "Default"
]
fog_density(integer) : "Fog Density (def=0.1)"
fog_colour(string) : "Fog Colour (0.1 0.1 0.1)"
] 

Quoth doesn't have a dedicated fog entity (yet), but you can use a trigger_command or trigger_command_contact to send a new fog command to the console and change the color that way. 

Is there a way for an entity to be marked by QC so that QuakeSpasm does not included it in demo's or MP/Coop traffic?

A new key, an existing flag, something that can be set via QC so that an entity is never sent, transmitted or recorded and remains client side only. I really want this for the QC sprite particle system so players can enjoy the visuals and not create monster demo files or drown network connections for coop. Thanks. 

Thanks, that answered to my question* 

So I can use these trigger_fog brushes, and inside of it will be specific fog I set up. If I put next to each other almost the same duplicates of the original, but I only change color a little bit.. or maybe changing it to totally different color like from blue to orange/yellow.

It that is possible, has any maps done this in the past? 

Is there a way for an entity to be marked by QC so that QuakeSpasm does not included it in demo's or MP/Coop traffic?
Its called the remove builtin... just check that deathmatch or coop are set first...

regarding demos there's not much you can practically do. The recording is clientside rather than serverside, so csqc's access to that sort of thing is going to be limited whatever happens. I guess an engine could add a some cvar that gets set when its recording/not (which would only work for local servers), or it could send a clientcmd (which qs mods would then be unable to parse anyway).
the client just dumps the entire data that it receives, so a serverside flag would do nothing to prevent demo bulk (unless the client was rewritten to be muuuuch more selective about what it writes).

one alternative would be to write a tool that just strips entities out of the demo based upon their modelindex, after the demo has already been recorded.
alternatively at least one server includes gib filters, which can be used to disable sending of entities based upon their model/frame. for instance a serverside gibfiltr.cfg file in fte with 'model firstframe lastframe' lines, which can be enabled on a per-(qw-)client basis with 'setinfo nogib 1'. obviously different engines, different rules, and I have no idea about eg qrack. looks like baker added some flags into proquake that a mod can set too (which naturally conflicts with dp extensions). the catch is that absolutely none of this is automatic, so whatever happens you'll have to get the user to manually switch stuff off to avoid huge demos.

one way to reduce bandwidth would be to pre-spawn your various particles/entities with the right frame/modelindex/colormap/skin/angles/scale/alpha already set.
then use only those entities for your particles.
this will reduce wasted bandwidth from resending the modelindex etc with every single packet.
qw/fte/dp are not so wasteful, so you won't gain much from that with those protocols.

anyway, pick your poison, give it a little momentum and someone will probably implement something eventually.
or just live with the user being explicit about it. 

When different trigger_fog brushes touch each other, the fog will actually flow from one brush to the other, through the joining faces, until the fog is equalised - so for example if one fog brush is full of red fog, and it touches a blue fog brush, the fog will mix until both brushes contain a purple fog. czg's Honey uses this extensively to get the smooth transitions between fog colors - different colored fog brushes are dropped onto invisible func_trains - the trains then move them around to collide with each other - when they collide, the fog mixes and you see a colour change. 

Thanks, that sounds so neat. I only can assume it can be used many other ways too. Maybe finally I can create that resembles doom's sector lighting even - but in form of fog. 

what* resembles doom's sector lighting.. 

Yes, it makes for a very flexible system with loads of different applications. 

ayy lmao kinda explained that poorly.
trigger_fog is NOT the same thing as eg q3's fog volumes.
the client can only use one set of fog at any time, which is applied to the entire map...
the trigger_fog brushes just change that client-wide setting once the player bumps into them, and its is applied smoothly over a short duration.
for practical purposes you're pretty much limited to one sort of fog per room, and transitions from one room to the next have to be handled really carefully to avoid the psychadelic world-changing-colour effect, typically by having small half-way rooms/corridors to keep the player distracted.
the smooth transitions mess up teleporters too.
they can be used for decent enough effects though, just remember that they're global and affect both near and far walls. 

anyway, pick your poison, give it a little momentum and someone will probably implement something eventually

Thanks spike for your reply. I was hoping that some kind of entity filtering happened when client demo's are recorded and another exception could be added to a list somewhere. I use the particle system built into DP/FTE so they produce better demo sizes.

There are so many new features I would love to be added to QuakeSpasm, but I do understand why they are not. Its just frustrating from a QC/MOD point of view as so many modern features (ie. global fog) are just hacks in QC to get them working. 

Would rock 

I will keep that in mind, I need to experiment a bit of it, after all my map will consist a lot of hallways, but I assume even elevator would work as a mood changer. 

I took a very quick shot at generating rain/snow and deconstructing the method used for Qrack's gl_rain.

Qrack gl_rain

Qrack uses for gl_rain video ... look at 13 seconds in to see gl_rain.

1. Take the sky surfaces.
2. In GLQuake, the sky is subdivided. (FitzQuake/Quakespasm it isn't and it would need a fake subdivision added in to have these rain or snow points.)
3. Average out the vertex positions in each sky polygon.
4. Emit rain from around those areas.
5. .. With a bit of randomness in origin
6. .. Some randomness in direction

End result is very easy rain.

But the fine tuning may be important ...
7. Appears to generate particles even out of view, which would be important if entering a new area.
8. But this means a ton of sky in a map is going to use a lot of particles.
9. But the particles at least "as-is" don't check for collision with the map or map entities (retractable bridge) and it would really need to. I can find indoor areas where rain comes through because outside a sky brush is over that structure.
10. Qrack does not appear to have rain in water, but I don't know if this is just because the particles don't last long (possible) or if I didn't find the code that killed off a particle that touches water.

Snow is would be easy to generate but possibly hard to fine tune.

Seven's DarkPlaces rain/snow

Video | Code + info

Another alternative would be the approach Seven used for DarkPlaces .

But Seven's DarkPlaces approach requires snow or rain emitting brushes in a map (func_snow or something?) -- which makes sense because QuakeC very likely has no way to know where sky brushes are.

Qrack's automatically identifying sky points method is vastly superior and easier on someone wanting to use it.

But there'd be a ton of fine tuning required.

I know because I took a quick shot at it screenshot.
1. Edit glpoly_t structure to add a vec3_t midpoint field and offset field.
2. Add a "rain think" in CL_RunParticles
3. Use -particles 8000 in cmdline // Default 2048
4. Pretty much take QMB_LetItRain from Qrack but adapting it to be just normal particles.
5. Some messing with Mod_PolyForUnlitSurface to pick vertex coordinates for snow/rain points. Would need some sort of fake polygon subdivision added back in to get it right.

(*) Seven's actual code appears to not use CSQC (client-side QuakeC), which would be better and required to avoid all of the problems with QuakeC rain (each rain drop particle is an entity, each entity saves in demos and has to go from server to client ... majorly big problems there). 

Note: The above is detailed notes for the benefit of whomever.

I took some time to chart it out, thought it would be good to record the info and make some notes.

But I don't really have time for engine coding--- especially something that would involve a lot of time intensive fine-tuning --- and don't want to create some sort of false expectation here.

On the plus side ... Spike seems intrigued by the idea of adding FTE's particle system to Quakespasm in the General Abuse thread.

If he would actually be willing to do something like that, that would be right avenue ;-) 

I have to say, I'm not sure I agree with this statement:

"Qrack's automatically identifying sky points method is vastly superior and easier on someone wanting to use it."


Unless there was some other way to limit which sky sections snow/rain could fall from, it would be a rather unfriendly situation to work with. Obviously the majority of cases it would be perfectly fine to have the particles fall from any sky surface, and it would certainly save on a few brushes, I can't think of a situation where it was better not to have as much fine-grained control as possible in content creation.

Just my 2 cents, of course. 

We'd still want the option of just spawning from all sky though - to suit the 90% of users who'd want to do it like that.

We'd certainly also want the ability to trigger sky rain on/off and change the density of it etc. midgame (like we do with fog triggers in AD and whatnot). 

That is some awesome info collation / analysis.

Best option (IMO) would be to use a particle based system from a func_weather/rain/snow brush. This way it could be triggered on or off, disabled in multiplayer, chosen where to implement and could allow flexibility in properties.

Style: snow, rain, acid-rain, etc
Density: distance apart.
Speed: speed.
Angle: straight down or xy

Am I going to implement this myself? Fuck no, I have enough shit on my plate already =P 

It could be blocked with skip brushes or skip the engine supported it which it should since particles should be blocked by geometry.