Quakespasm on Steriods

[Spike]

6) premultiplied alpha blending can merge batches with additive blending. traditional alpha blending cannot. note that dp's effectinfo stuff ONLY supports premultiplied blends.
yes, I should have added some dprints for the fallbacks.

13) for rain, "count 32" that means spawn a puff of 32 particles each time (allowing spark-like puffs), hence why there's a separate scaler.
for r_effect that spawns at the origin of the entity every single frame, then count is per second, while r_trail uses step instead, which is the distance travelled per particle.

15) clipbounce -1
0 will make it stop, 1 will slide along the surface (its a dotproduct thing), 1.5 will act bounce like grenades, 2 will maintain its speed, >1 && <2 will give you other momentum conservation values, -2 will make it become a decal (handy for blood), and -1 will remove the particle on impact.
if you also include a cliptype then you can cause the particle to spawn different types of particle on impact.

16) 'type static' is logically wrong. use 'type normal' (again, I should have added a dprint about fallbacks). with r_part, 'type' describes how the engine generates geometry, and is equivelent to 'orientation' in dp's particle system, thus 'type static' is as wrong as 'type smoke' was.

[Baker]

15) For some reason I'm not getting any apparent collision with clipbounce 0 or -1 with this ...

(video is below)

// Emit myst

r_effect "progs/invulner.mdl" te_pent   // If this model appears, have it emit this effect.  invulner.mdl = Pentagram of Protection
r_effect "progs/g_rock.mdl"   te_pent   // g_rock.mdl = grenade launcher (g_ = ground model) 

r_part te_pent
{
    //texture "particles/myst"          // Uncomment: if you want it to use an external texture named "quake/id1/particles/myst.tga" used
    type normal                         // It's a fixed particle

    // frequency
    count 32                            // Number of particles to emit in the area
    spawnchance 1.0                     // 100% chance of it occurring.  Change to 0.10 it would have 10% chance.

    // size
    scalefactor 1                       // 1 = normal scaling due to distance.  0 = same size no matter distance!  -1 bigger the further away.
    scale 40                            // Base size of 40
    scalerand 15                        // Add 0 to 15 random to size for end result of 40 to 55 size for each particle

    // where
    spawnmode box                       // Spawn the particles in a box of the size ... 
    spawnorg 10 5                       // X/Y size of box, Z size of box.  This box is 10 wide, 10 deep and 5 tall.
    orgbias 0 0 30                      // originoffset x y z.  Start 30 above the object, remember this mist FADES DOWNWARD into existence from nothing.

    // movement
    randomvel 14 12                     // randomvel (x/y) (z) -- Add randomness up to 14 for the X/Y axis, 12 for the Z axis (up/down)
    velbias 0 0 -50                     // Give it 50 speed in the down direction

    // lifespan
    die 2                               // Lifespan of a particle in seconds.  After 1 second, the particle is killed off.
                                        // Note: it will go through walls, floors, etc.    
    clipbounce 0
    
        
    // draw
    alpha 0                             // Yes, that's right -- starts out invisible.  Then becomes more visible providing a mist looking effect.
    blend blendalpha                    // use alpha blending
    rgb 255 255 255                     // RGB red green blue (0-255)  (255, 255, 255) is white  (255, 0, 0) is red, etc.

    // progression                      
    rgbdelta 0 -11 -5                   // Rate of change for each color component    
    rampmode delta                      // Options are none|absolute|delta|lerp|nearest
    ramp 0 0 0 -0.7 0.5                 // ramp r g b alpha scale --- perform an alpha fade of -0.7 
    ramp 0 0 0 -0.4 0.5                 // ramp r g b alpha scale --- perform an alpha fade
    ramp 0 0 0 -0.3 0.5                 // ramp r g b alpha scale --- perform an alpha fade
}

[ame]http://www.youtube.com/watch?v=5pXpyZYC8ic&autoplay=0[/ame]

16) 'type normal' it is then!

[Baker]

Lighting on the gun appears to be screwed up whenever player can see the grenade launcher and the sparks.

Picture attached.

My guess would be a GL setting gets turned on but not off.

r_effect "progs/g_rock.mdl"   te_sparky   // g_rock.mdl = grenade launcher (g_ = ground model) 

//spark effects

r_part te_sparky
{
	//texture "particles/spark"          // Uncomment: if you want it to use an external texture named "quake/id1/particles/spark.tga" used
    type spark                         // It's a fixed particle

	// frequency
    count 50
    spawnchance 0.05                     // 100% chance of it occurring.  Change to 0.10 it would have 10% chance.

	// size
	scalefactor 1
    scale 40
    
    // where
    spawnmode box                       // Spawn the particles in a box of the size ... 
    spawnorg 10 5                       // X/Y size of box, Z size of box.  This box is 10 wide, 10 deep and 5 tall.
    orgbias 0 0 30                      // originoffset x y z.  Start 30 above the object, remember this mist FADES DOWNWARD into existence from nothing.
    
	// movement
	randomvel 140 0						// random velocity of 140, no Z axis (up/down) velocity
    gravity 400							// Quake normal gravity is 400
    
	// lifespan
	die 1								// live 1 second
   	clipbounce 0						// die if hits surface

	// draw
	alpha 1								// solid, no alpha transparency
    blend add							// additive blending
	rgb 255 128 76 						// orange

	// progression
    rampmode delta
    ramp 0   0  0   1
//  inwater gunbubble2
}

[Baker]

It looks like for particle scripts, the effect is oriented towards the camera. (The effect direction is same no matter what direction you look at it, the direction follows the camera).

Is there some particle script command that will use a world space direction for an effect?

Was trying to make an effect somewhat similar to Seven's effect of having a valve release water (but less realistic).


[ame]http://www.youtube.com/watch?v=MY4m8QNsuss[/ame]

r_effect "progs/g_rock.mdl" te_rainx 1    // g_rock.mdl = grenade launcher (g_ = ground model) 

//spark effects

r_part te_rainx
{
    //texture ball
    type smoke
    scale 12
    scalefactor 1
    count 300
    orgbias 0 0 60                      // originoffset x y z.  Start 30 above the object, remember this mist FADES DOWNWARD into existence from nothing.
    randomvel 14 //12
    

    alpha 1
    rgb 192 192 192
    rgbrand 0 0 64
    die 2

    gravity 200
    
    cliptype te_rainy_rainsplash
    clipbounce 100
    clipcount 5
}

//internal splash effect for rain
r_part te_rainy_rainsplash
{
    randomvel 50 50
    count 1
    texture ball
    scalefactor 1
    alpha 0.1
    rgb 255 255 255
    die 0.4
    scale 50
    stretchfactor -2.5
    veladd 1
    scale 1
    type texturedspark
    gravity 800
}

Seven's effect for reference

[ame]http://www.youtube.com/watch?v=CdrP07el_1U[/ame]

[Dutch]

This is pretty sweet spike, thanks for all the hard work.

If you don't mind, I have 1 really simple request (and 1 maybe not-so-simple) for a future release:

1) In view.c, under V_CalcRefdef, can you cvar the stair/ramp smoothing? I want to spawn particles/spr32 sprite for muzzleflashes, but with this smoothing enabled, the player's view drifts below his actual aim point, making the muzzleflashes appear well above the barrel of the gun when he's walking up ramps/stairs. This is my only hang-up to spawning actual muzzleflash models, and I imagine setting this to a cvar is infinitely easier than enabling viewmodels for clients only (and vice versa).

// smooth out stair step ups
if (!noclip_anglehack && cl.onground && ent->origin[2] - oldz > 0) //johnfitz -- added exception for noclip
//FIXME: noclip_anglehack is set on the server, so in a nonlocal game this won't work.
{
float steptime;

steptime = cl.time - cl.oldtime;
if (steptime < 0)
//FIXME I_Error ("steptime < 0");
steptime = 0;

oldz += steptime * 80;
if (oldz > ent->origin[2])
oldz = ent->origin[2];
if (ent->origin[2] - oldz > 12)
oldz = ent->origin[2] - 12;
r_refdef.vieworg[2] += oldz - ent->origin[2];
view->origin[2] += oldz - ent->origin[2];
}
else
oldz = ent->origin[2];

2) Any chance on custom crosshairs? Not to the level of DP/FTE, but just the ability to load external images based on cvar setting? This isn't a big deal, I'd be more than happy with the first thing I mentioned, but I thought it would be cool to be able to switch crosshairs in-game for each particular weapon. I understand there's probly a lot more to it than simply loading an image...scale and positions and all that come into play. No worries if you don't want to spend the time on this, I totally understand.

These are the only requests you'll ever hear from me, everything you've done is well above and beyond the call of duty. Thanks. I would do these myself (already implemented the stair step problem but will have to learn for the crosshairs) but I hate to release yet another FitzQuake/QS based build when yours already has a lot of nice features and will likely become the QS standard.

[Spike]

@Baker
the weird nailgun means that culling was left disabled (combined with buggy models where this becomes obvious - I've seen this before). Will be fixed with v5, I'm just too lazy to release one with only a couple of minor changes (not that there's any real testing department here).

use velbias if you want to bias the velocity by some worldspace direction.
use velwrand to add a random amount (scaled by -1 to 1, so be sure to compensate with velbias)
randomvel is essentually a simpler alternative to those two properties.


@Dutch
1) no. making stuff jerky just because you're trying to hide how jerky something else is is not the way.
viewmodelforclient is already implemented, but I probably should have tested it more. I expect it still won't work well with sprites unfortunately.

2) that's something the QS people should deal with. if its not likely to cripple modders, or servers running said mods, and isn't the engine that I want everyone to use, then I'm not really interested in it. I only really did the ipv6+delta stuff because I got annoyed at NQ engines in general and how they were limiting the effectiveness of coop mods/huge demos.
sorry, but my own interest has basically gone for now.

[Dutch]

sorry, but my own interest has basically gone for now.

not a problem, i understand.

[Baker]

Will be fixed with v5, I'm just too lazy to release one with only a couple of minor changes

My goal here is to try to make some working particle demos that are
1) Done proper
2) Someone can follow

I don't need a bug-fixed version to do that

(3. And identifying things that seem like bugs )

I want to some single player maps using this stuff, and I think you once you've seen my demo you'll get a good laugh when you look at a very villainous trick I'm using

/Relax, have fun and I think you just might be a little entertained too

[Baker]

@spike - Ok, got the directional stuff to be fine.

Honoring entity angle field for a directional effect in particle script

Let's call Quake angles the following:

angle 0 - "North" - Positive X if you step forward facing that way
angle 90 - "West" - Negative Y if you step forward
angle 180 - "South" - Negative X
angle 270 - "East" - Positive Y ... 270 or -90 angle are same thing due to wrapping

r_effect doesn't seem to honor an entity's angle. Now I could be doing something wrong.

{
"classname" "func_illusionary"
"model" "progs/whatever.mdl"
"frame" "3"
"origin" "1218 -1231 278"
"angle" "0"   // North <--------------------- 
}

By changing the angle of the entity in the map, it should change the direction of the effect?

"angle" "90"   // West <------ I change this, but effect direction does not change

Does it currently provide for this and I am doing something wrong?

[Baker]

Is there a worldspawn key where the mapper can set the preferred r_particledesc for a map?

Considering your namespace support, I can think of an evil way for a mapper to do this even if there is not, but I don't want to recommend hacks or something ugly.

---
It looks like the intent of your particle system name space system is to provide of effects vs. their implementation.

I could have a file called steam.cfg with 5 types of steam.
Then a file called, for instance, e1m5.cfg that may associate certain things specific to e1m5 like r_effect "progs/something.mdl" steam.light_steam (or steam.light).

Side note: Is there some sort of naming convention that you have in mind. In the weather.cfg you provided, you prefixed tex_ to texture based effects. I don't know what your suggestion would be for a particle effect naming prefix? part_? But rain/snow are particles too.

[Spike]

particles have a simplified orientation in the form of a direction vector, you can add that direction by setting veladd 1 (it should normally be normalized, so you probably want 200 or whatever). for 'rain' effects, this is the surface normal that its emitted from, or the 'dir' parameter from pointparticles. in other cases like te_gunshot its not specified, and is assumed to be '0 0 1'.
r_effect does not currently use any specific direction.

multiple configs was so that users can mix+match as desired. including the name in qc/maps allows content to still work even if the user neglected to set it (which is a significant issue if users are mixing configs from different mods). explicit(r_particledesc) configs will still override implicit(content-loaded) configs, such explicit configs will generally need to exactly match the name the content tries to use of course, but this shouldn't be a huge issue.

[Baker]

particles have a simplified orientation in the form of a direction vector, you can add that direction by setting veladd 1 (it should normally be normalized, so you probably want 200 or whatever). for 'rain' effects, this is the surface normal that its emitted from, or the 'dir' parameter from pointparticles. in other cases like te_gunshot its not specified, and is assumed to be '0 0 1'.
r_effect does not currently use any specific direction.

I'll just use specific directional effects then as a substitute for angle, it'll get the job done.

With effect names like mist_east, mist_west and corresponding model names like null_mist_east.mdl, null_mist_west.mdl, etc.

FitzQuake 0.85 creates it's own extra acknowledged entity field "alpha". In a perfect world, an extra acknowledged entity field like "effect" or "particleeffect" would prevent having to use several different renamed null.mdl to pull off pure particle scripting without any qc support.

But the system as it stands is already incredible nice and very flexible.

/And I can work within limitations I just want to make sure the option doesn't exist first, naturally.

[Baker]

(Nevermind, may edit post later. I had a problem, solved through looking thru engine source code and finding what I needed.)


Random notes:

Texture effects emit off worldmodel. Trickery with moving platforms and such emitting a texture effect is a no no.

Model effects also do not emit off a model with alpha = 0. Not even if it is a static entity. Using the engulf option will prevent the model from being rendered. Only downside to this is that if using the engulf feature in a custom map will mean that the model will appear in a non-supporting engine. So using an invisible model like null.mdl or setting alpha to 0.01 (not supposed to be invisible, yet effectively it is invisible). All things being equal, using a null.mdl is the best option where automatic loading of misc_model or Quoth mapobject_custom is available.

Model effects are not available on .bsp models, nor the player model even if using a func_illusionary to have a dead Quake body sitting around (I can't be arsed to find out the frame number "frame" "63" ?) Which makes sense because in multiplayer, dead bodies are separate entities from the player slots (although what classname is a dead body, hehe?) No flies hanging around dead bodies (Quake 2 style) without QuakeC

[Massao]

Good work!

[Baker]

17) I'm giving this one a number. As kind of an inconsistency, you can specify a texture emitting an effect (rain or snow) in the worldspawn, but ironically can't do that in a particles .cfg file. According to comments, you mention that "QSS" doesn't run the script the same way as FTE does. But I can't think of a reason someone would need to specify that kind of thing in a script anyway -- so pretty irrelevant anyway.

If the mapper designed the map, the mapper would put that behavior in worldspawn, and if someone wanted to override that they could always make an external .ent file.

18 ) One thing I find just slightly annoying --- having to specify the exact sky texture to emit an effect (rather than, say, sky*). A Quake compatible map can only have 1 sky texture -- usually any decent Quake 1 map compiler would refuse to compile the map if I recall. I'm just mentioning this thoroughness I'm just mentioning this. It doesn't really matter and there is a console command in Quakespasm that lists the currently used textures ("imagelist" command) so someone could figure out the sky name or opening the map with TexMex works too.