Well as you probably have guessed I'm no expert on the subject, but you gotta admit that it's a bit confusing when they use the same term to describe different things. Like "brush". 

Like I said I'm sure it was traditionally painted, like oil painted, and scaled down. Then it was tweaked using pixel pushing techniques afterwards 

The Doom monsters started as scanned in photos of actual models. 

Which is probably why they looked so coherent from all sides. 

Is MugWump now allowed to just trash this thread into smithreens?

He's not house trained, where is a moderator?

This is the Quakespasm engine thread, not his personal litter box. 

 

Hey, I came back here to reply to Preach. Like I said, when someone talks to me I respond, that's the basic principle of communication. People then commented on that reply, etc etc... and I wasn't expecting the discussion with dwere to be this long. Next time I'll move it to general abuse, but between you and me you should work on your people skills. You know I'm new to this site and right now, you're making me feel very unwelcome. Not cool. Mugwump out. 

You trashed up this thread.

I don't care how you feel, you are the wrong-doer

An apology would be nice. 

You want me to shut up or you want me to apologize? Maybe you should ask all the people who kept me talking - including you, how ironic! - to apologize too, they're just as responsible for making the off-topic linger on. But you won't do that, will you? Mugwump out. Again. 

Maybe you should ask all the people who kept me talking...

Yeah I agree that it was a mistake engaging in conversation with you in the first place. I imagine not many of us on this forum will bother doing that again. 

https://media0.giphy.com/media/fDO2Nk0ImzvvW/giphy.gif 

Yeah let's all pick on the new guy. Provides coherent arguments and all you do is whine about how this is the wrong thread. Boo hoo. Reminds me why nothing decent ever comes from this community, just circle jerking over a 20 yo game. 

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.