Quakespasm on Steriods

[Baker]

This post is longer than I prefer, but contains mostly minor questions.

And thoughts on mostly 2 things. Apologizes for wall of text in advance, I try to avoid big posts.

1) that would appear to be the difference between sv.max_edicts and sv.num_edicts when combined with debuggers preventing heap memory from being default-zero-filled, hence why I didn't notice it.
nice catch. bugger.
always plan for another release... or something...
go find other stuff, if you've time.

I've seen instances where the console buffer prints some impossible text (the text looks like C code "#ifdef UNSUPPORTED") to the console if a particle script contains unknown keywords and then complains each line contains an unknown command.

I don't know if this is a buffer overflow, bad pointer or what not or something I could somehow be doing.

If I see it again --- and I will -- I'll post a screenshot and provide enough info to recreate. Never happens when the particle script is fine.

(note that even if you are using protocol 15, the 'fte' thing means that its merely a 'base' protocol, or in other words, its completely roflstomped over for quakespasm clients in a way that will be (mostly) invisible to every other type of client. hurrah. thus those client-only extensions probably still apply, at least when connecting with the same build as the (dedicated?) server).

I record a demo using protocol 15 or -15 and it wouldn't playback in GLQuake, which I found slightly confusing because I thought the point of -15 and -666 was to allow that.

Having said that:
1) The ability to record a true protocol 15 demo is very important.
1a) I think "-15" should be "15". There's no reason to use protocol 15 except as a server or if trying to record a demo that another client can play.
2) The ability to record a protocol 666 demo is not important at all.

I consider protocol 666 to be a good effort, but incomplete as it cannot do what is intended --- you can't coop a bigmap game reliably. Believe me, I know

So I would suggest the following:
1) Call this "666" something else.
2) Have it be maybe "700". And make it the default.

Because a name should mean something. If FitzQuake 0.85 can't play the demo and Quakespasm can't play the demo, it shouldn't really be 666.

The engine can playback 666 demos and that's important.

But honestly, I don't think even being able to connect to a 666 server is important. I'm just expressing that I feel, like you seem to believe, that this essentially completes what 666 was designed to do and makes 666 obsolete.

3) half a particle doesn't make sense. for rain/surface emitters, you can use rainfrequency which will scale up/down the frequency of emission effects (where count remains the number of particles spawned with each 'puff', which is useful with eg sparks).

a) What does rainfrequency apply to and not apply too. If I have a pent emit particles like some of the brief demos I made, does rainfrequency apply to that? (I asked about the interval because "emitinterval" sounded like something that would control that)

b) I get "count 1" or "count 50" but is the emission rate per frame? I don't know what interval it uses. I just know it doesn't seem to be per second.

c) There are quite a few different commands, some of them seem redundant so it just takes time to figure out what they do --- and some of them even reading the source code I can't figure out what they do. ramp and rampdelta in particular is an example. And some of the ones that have an (XY) and then a (Z) parameter.

d) Has Socked asked if pixel particles that don't distance scale or ever change angle are possible? I'm just wondering for tutorial purposes, but it doesn't matter to me if they do or don't exist really.

So, baker, how long until you port this stuff to one of your engines?

I'll have to satisfy myself with read the code, at least for quite a while.

But yeah, I've read a fair amount of it.

My short term goal is doing what I can to make sure this engine gets put to use -- and receives testing, and to the extent you are willing -- polish. Both the particle scripting and the server features, because I recognize the value of each. I'd like see the QuakeC extensions get used, but that isn't down my alley.

Obviously, I think what you have done is incredible, and it I have some different plans running through my head.

/I think I'll have the opportunity to put it through some serious coop testing this weekend

Extra:

a) When time permits I want to bring up thoughts on game/gamedir
b) Don't want to make this any more of a wall of text, but out of curiosity does FTE have banning ability for IPv6? I just am curious. As far as I've ever heard, banning someone on IPv6 is a real PITA (from website operators saying that). Yeah, I noticed that bantest is disabled in the source, made me think of that. (This is a curiosity only).


c) Please, please see keys.c and find this line and make insert the default cursor behavior (make it default true instead of false).

I saw that change by MH in the Remake Quake engine --- and it brought me pause back at the time --- I'm uber-conservative but MH does not make changes on a whim either. So I tried it out and thought about it and after some testing, I tried to imagine any scenario I wouldn't want it on and there were none. Makes using the console a complete delight. I think goldenboy or ijed were the ones that asked MH.

int key_insert = true; //johnfitz -- insert key toggle (for editing)

/Damn that's a long post. Too long for my liking, but it's too late now.

[Spike]

I have no idea how you'd get C code appearing on the console, unless you were actually trying to exec it somehow. '#ifdef UNSUPPORTED' does appear inside r_part_fte.c but not within any strings, specifically I annotated the parts that I couldn't be bothered to fix after porting the particle system from fte with that.
specifically, stain maps (gah! rendering!), model-particles (which are limited and lame and use fte's qw-derived effects system rather than the particle system), and viewspace particles (yuck, matrix maths combined with no csqc to avoid latency).

protocols and stuff...
quakespasm supports FTE, 15, 666, and 999.
'FTE' is (for me) actually defined as extensions to an underlying protocol rather than a specific protocol itself. If a client and server both support a subset of their extensions then only that subset is used (yay handshakes). When those extensions are not mutually supported then the result is that it falls back to the base protocol.
This means that an extended client can connect+benefit from it, without excluding crappy clients like proquake, which was a significant issue with the uptake of 666 for instance.
sv_protocol FTE+15 uses 15 as a base and enables extensions
sv_protocol -15 (or 15- if you prefer to write it that way) uses 666 and disables other extensions
sv_protocol 15 uses 15 and doesn't enable nor disable extensions
This means that you can easily (by default) switch between 15/666/999 as before for other clients without crippling engines that support the extensions.
While if you want compatible demos, '-15' blocks all extensions (although it may still use larger packets, because LOCAL, I didn't change that part of quakespasm, I was under the impression that demo playback allows larger unreliable packets of 8k).

particles and rates, the count actually varies a bit.
with trails, you should use step instead, which gives 1 particle per X qu
with surface emitters, the engine spawns a point effect at X qu^2 per second (I don't remember the exact surface area), with count particles per point. rainfrequency on the top-level effect changes the rate at which they spawn (which can be handy in combination with assoc to define multiple identical effects with different rates).
model emitters (ie: r_effect) spawn count particles per second
if you're using countabsolute(dp) or countextra(fte) on a trail or r_effect, or you use fractional 'count' (aka: multiplier) arguments with the pointparticles builtin, then you're an idiot that loves framerate dependant spawn rates. if you're using nextthinks of < 60fps then you're probably also inducing framerate dependant particle counts thanks to the lack of sv_gameplayfix_multiplethinks or whatever it was.
there's a 'spawnchance' property that you can tweak to give a random (decimal) percentage change to skip spawning at all, or you can just give a two args for count.

so if you want a single large particle as a sort of corona, count 0; countextra 1; die 0; means that it'll re-spawn a single particle every single frame.

if you want particles to not rotate then you can just set their 'rotation $startanglemin $startanglemax $avelmin $avelmax'.
scalefactor 1 will use normal scaling. scalefactor 0 should keep the particle a fairly constant size regardless of how far away it is.
with 'nearesttexture' instead of 'texture' to get nearest sampling.
or something.

FTE's penalty (read: ban) system can deal with ipv6, yes.
that said, the general unavailability of ipv6 by ISPs makes it somewhat hard to actually test.
with native ipv6 probably need to ban an entire /64, thanks to various privacy mechanisms randomizing the last 64 bits of the client's address.
there are also MANY automatic ipv6-over-ipv4 gateway mechanisms, so if you're banning someone and have ipv6 enabled, you probably want to ban all of those routes too (which is slightly easier than banning tor, at least). but yes, more addresses, more possible routes, more difficult to ban.

changing key_insert is the sort of thing you should raise with someone else. I was trying to avoid too many user-visible behavioural changes (unless it had obvious/longterm compat/crippleware issues).
besides, if I fixed everything, there'd be no reason to use fte

[Baker]

I have no idea how you'd get C code appearing on the console, unless you were actually trying to exec it somehow. '#ifdef UNSUPPORTED' does appear inside r_part_fte.c

I'll post some stuff late tonight. Actually, I don't think it is C code, I think it could be shader code, which would make more sense. Mentally I put investigating that on the backburner, I wanted to at least get some particle scripts --- perfect or imperfect -- working.

FTE's penalty (read: ban) system can deal with ipv6, yes. that said, the general unavailability of ipv6 by ISPs makes it somewhat hard to actually test.

if you're using countabsolute(dp) or countextra(fte) on a trail or r_effect, or you use fractional 'count' (aka: multiplier) arguments with the pointparticles builtin, then you're an idiot that loves framerate dependant spawn rates

I'll post some examples late tonight, I don't want to tutorialize things in a way that promotes bad examples.

I've been trying to understand what all of the options do and use them in examples.

I definitely don't want frame rate dependent spawn rates, that wouldn't be right at all.

[Baker]

1) If I use this command line
c:\quake\quakespasm-spike.exe +r_particledesc high +map dm3

2) And use "high.cfg" from quakespasm-spike-r4.zip is placed in quake\id1\particles

I get this result with quakespasm spike r4 ... screenshot attached ...

[Baker]

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

I have a suspicion this particle script is not optimal at all. And is probably bad technique.

This is derived from studying haze.cfg.

And also studying the FTE wiki, a doc on DarkPlaces particles and looking through the engine code.

Any suggestions or corrections would be welcomed.

// Emit myst

r_effect "progs/invulner.mdl" te_pent   // If this model appears, have it emit this effect.  invulner = Pentagram of Protection

r_part te_pent
{
    //texture "particles/smoke"         // Uncomment: if you want it to use an external texture
    type smoke                          // Select smoke particle
    rainfrequency 1
    count 32                            // Number of particles to emit
    scale 40                            // Size of particles
    scalerand 15                        // Randomly increase the size of a new particle by adding 0.0 to 15.0 to the size
    scalefactor 1                       // Multiplier
    scaledelta -15
    alpha 0
    die 2                               // Lifespan of a particle in seconds.
    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 -20 0 0                   // Uncomment me for it to blow to the side
    veladd 50                           // Add this to the X/Y direction
    //veladd 50 -20                     // Use this instead to get smoke more "all directional"
    rgb 255 255 255                     // RGB red green blue (0-255)  (255, 255, 255) is white  (255, 0, 0) is red, etc.
    rgbdelta 0 -11 -5                   // Rate of change for each color component
    blend alpha                         // Alpha blend
    spawnmode box                       // Spawn the particles in a box of the size ...
    spawnorg 10 5                       // X/Y size of box, Z size of box
    
    spawnvel 6 0                        // Spawn velocity (X/Y) and Z
    up 30                               // Move the spawn box up by 30 (30 is what unit?)
    //    assoc cu_torchbits            // For firing off another effect, we aren't doing that here.
    rampmode delta                      // I don't know what this does, but the options are none|absolute|delta
    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
}

[Spike]

that 'c' code is embedded glsl from an embedded shader in the particle config that you're trying to use. naturally, shaders and glsl is not something I was willing to implement due to the amount of work it would have been (as well as how much it would likely have broken everything else).
yes it would be nice if it got handled a bit more nicely, but that's true of many things.

'type smoke' is invalid, smoke makes no sense in terms of transforming that into geometry. special hacks to have the particle do different things just because its 'smoke' or something is silly.
'rainfrequency' is used on a non-surface particle
'scalerand' should be folded into the previous scale (ie: scale $min $max)
'alpha 0' is generally a bizzare initial value.
'die 2' makes the particle actually live quite a long time
'blend alpha' is invalid. premul_blend is commonly a better choice. or premul_add if you want slightly better defined behaviour (no ordering issues then)
'up' is deprecated. use orgbias to set a fixed world-position bias.
'assoc' is somewhat deprecated. the internal machanism + property still exists, but it is muuuch easier to use it automatically via adding additional effects with a leading + in their name. (ie, r_part foo {}; r_part +foo {}). the + serves to not nuke any previous effect with the same name - a handy way to test effects in fte is to just re-exec the config, while qss needs you to change r_particledesc to something and then back or something thus this feature can be quite important.

regarding ramps, you might find that 'rampmode lerp' has the simplest behaviour, which easily allows you to do predictable rainbow effects or pulsing sizes or whatever. 'rampnode nearest' may also be interesting if you want odd effects.
delta ramps override the type's various delta values temporarily, which makes them more awkward to control, especially with large values and possibly inconsistent frame timings. note that with delta ramps, the alpha+scale values are per-second, so you would have to plan ahead to get it to fade out to 0 or whatever at about the same time that the particle dies.

remember that fte's particles are not dp's particles. if you try using dp's particles then you don't have access to any of the spawn modes, which limits them a fair amount (oh noes! no spiral trails!... etc).

fte's particle system isn't perfect, but it gets the job done. note that its the only part of my patch where I added ifdefs (... iirc).
I expect that if I wrote a particle system from scratch now then it'd be quite different, but I'm a sucker for compatibility as well as versatility... and I cba to test rewritten code either (the actual writing I don't mind so much, but it does need testing as its getting implemented just to make sure the bugs get fixed before the code gets complicated).
fnar.

[Baker]

that 'c' code is embedded glsl from an embedded shader in the particle config that you're trying to use. naturally, shaders and glsl is not something I was willing to implement due to the amount of work it would have been (as well as how much it would likely have broken everything else).

My bad, I now see that is deep in an otherwise very, very long script file.

One I don't use, btw. I don't use high.cfg but it seems to default to that for some reason.

Didn't expect #ifdef in a particle script. My bad.

[Baker]

I've numbered these so you can do
"1) No, do this instead ..." instead of having to quote stuff.

'type smoke' is invalid, smoke makes no sense in terms of transforming that into geometry. special hacks to have the particle do different things just because its 'smoke' or something is silly.

1) I agree with that. Just omit, correct? What is the default type? Is it "static"? Or is just omitting it entirely the proper action?

'rainfrequency' is used on a non-surface particle

2) So rainfrequency is just for textures, right?

'scalerand' should be folded into the previous scale (ie: scale $min $max)

3) I'll try to merge scalerand in.

'alpha 0' is generally a bizzare initial value.

4) I'll try removing it. I'm pretty sure I have tried removing it and it changes the appearance.

'die 2' makes the particle actually live quite a long time

5) Die is 2 seconds, right? What am I missing about why that is a long time?

'blend alpha' is invalid. premul_blend is commonly a better choice. or premul_add if you want slightly better defined behaviour (no ordering issues then)

6) "blend alpha" ... DarkPlaces wiki page said options were alpha, add, invmod so I tried to use a name that is commonly known like "alpha blending", but ok ... will change to the premul_blend

7) kill up, use orgbias x y z. I was looking for something like that.

'assoc' is somewhat deprecated. the internal machanism + property still exists, but it is muuuch easier to use it automatically via adding additional effects with a leading + in their name. (ie, r_part foo {}; r_part +foo {}). the + serves to not nuke any previous effect with the same name - a handy way to test effects in fte is to just re-exec the config, while qss needs you to change r_particledesc to something and then back or something thus this feature can be quite important.

8 ) Too complicated for me to figure out right now, but maybe if I read it again later it'll sink in. I don't know what "qss" is. Typo? or means "Quake scripting system" or something?

9) Does re-executing a config work? I thought I had to restart the map. But nevertheless, if you say it works that way you should know, you wrote it. For some reason I didn't think it worked that way.

10) Dumb question: How do I re-execute a config? AFAIK, typing r_particledesc "high" does not do that.

regarding ramps, you might find that 'rampmode lerp' has the simplest behaviour, which easily allows you to do predictable rainbow effects or pulsing sizes or whatever. 'rampnode nearest' may also be interesting if you want odd effects.

11) NO!!! The page says possible modes are "none", "absolute", and "delta" And I don't even know what any of those do! Now there is another two called "lerp" and "nearest"? Aw hell ... Anyway, I guess I'll ask more about that later.

delta ramps override the type's various delta values temporarily, which makes them more awkward to control, especially with large values and possibly inconsistent frame timings. note that with delta ramps, the alpha+scale values are per-second, so you would have to plan ahead to get it to fade out to 0 or whatever at about the same time that the particle dies.

12) I'll have to get back to you on ramps. I understand it vaguely, the particles change. But I don't know what the interval is. I don't know whether the parameters are relative or absolute or multiply or what.

13) Big question: In this script above, when is it spawning particles? Is it every frame? Or is it some other interval?

[Baker]

changing key_insert is the sort of thing you should raise with someone else. I was trying to avoid too many user-visible behavioural changes (unless it had obvious/longterm compat/crippleware issues).
besides, if I fixed everything, there'd be no reason to use fte

I see how you are

You'll break bobbing because you hate it.

But if I ask for a "false" to be changed to "true" because I'm using the console all the damn time for testing, that's too much

In all seriousness --- bobbing is broken. Empty Quake folder with pak0.pak, pak1.pak, Quakespasm spike and the 485 DLLs that Quakespasm needs for music codecs. Start up engine ---> no bobbing.

[Spike]

2) rainfrequency is just surface emitted by surfaces, yes. its ignored otherwise.
4) you probably want alpha 1 as a default, which is implied if omitted, iirc.
5) yes, 'die' is the time until it dies. you can use two args which is the minimum age and maximum age. if they differ then particles are actually pre-aged for their alpha values (and probably a few other fields) on spawn, so that they fade out when the particle is meant to be dying. this can also be handy for delta ramps.
6) dp's alpha blend on particles is equivelent to 'blend premul_blend' in fte. you should generally use premultiplied alpha, but its a big ugly because fte didn't originally do it.
qss='quakespasm-spiked', but meh.
10) "r_particledesc classic; r_particledesc high" will reload particle scripts in 'qss'.
if the mod/map name their effects explicitly then it doesn't actually matter which config you tell it to load, as the namespaces thing causes particle configs to be loaded as needed if the user didn't want to override them.

11) rampmode: none, nearest (just copy the value over), lerp (interpolate the value between the two nearest ramp settings), absolute(aka nearest), delta (default, provides alternative delta values (per second).
so if you want a particle to fade from a starting value to target value, you can use lerp with those values, or delta with the (targetvalue-startvalue)/(maxage/rampentries). so you should be able to see why I say to use lerp in that case. note that delta is the only one that can actually deal with randomized starting values though.
you can specify the ramps themselves with ramp(rgb values), rampindex(palette values), rampindexlist(palette values with a single line to generate multiple ramp entries). obviously indexed values won't work too well with deltas.
you'll need to use ramps if you want to mimic classic quake's rocket trails properly.

13) with r_effect, PScript_RunParticleEffectState is called with a partial value each frame, along with a 'trailstate' that is used to track things between frames (like fractional particle counts that got rounded).
the trailstate *should* track fractional values such that the resulting count value is per second. obviously random counts may be problematic, while countextra will be framerate-dependant (which may be desired if you have die 0, for instance).

bobbing - oops, wasn't my intention, I thought it was working. probably the onground flag got fucked somehow.
I ought to check that gun kicks work too.

[Baker]

2) rainfrequency nexttime is 10000/(area * quantity * frequency) so that must be for a flat surface. Looks like per triangle.

8 ) Ok, QuakeSpasm Spike
10) Reload works. Sure is better than reloading the map, although what I've actually been doing is loading a savegame.

13) If "count 32", does this relate to the area like rainfrequency seems to? Like this a density thing?

[Baker]

14) If I have the console open for a bit typing stuff, and then close the console ... this script generates a big puff of smoke.

As if it is trying to "catch up". Is there a timer or clock that isn't right? cl.time shouldn't be advancing when console is up because the game is paused, right?

I'm just bringing this up to be thorough.

Add:

2) I can "confirm" that increasing the size of a box decreases the perceived effect speed, so area must be involved in spawnmode box. At least confirm to myself, since you already know this.

1) "type smoke" ... if I comment this line this out, it doesn't look the same as it did before. I'm going to roll with "type static" I guess.

[Baker]

6) "blend premul_blend" is not same as "blend alpha" in FTE --- not at all. Can't use that as a substitute. "blend alpha" will hit the "catch all" and not set premul to 1. It is behaviorally different, I guess I will use "blend blendalpha" since that is explicit.

			else if (!strcmp(value, "premul_blend"))
			{
				ptype->looks.premul = 1;
				ptype->looks.blendmode = BM_PREMUL;
			}
			else
				ptype->looks.blendmode = BM_BLEND;	//fallback

[Baker]

15) What do I need to do to cause a particle to die if it hits a solid surface. I'm making the grenade launcher emit mist and it goes through the floor.

[Baker]

Particles don't die when they hit stuff. Couldn't figure out a way to make that happen.

Otherwise, I think this is well documented. Let me know if anything obvious is wrong.

I understand the idea of ramps, a change occurs. But I've a bit vague on that, people can play with that and fine tune.

Look this over and see what you think of "Version 2.0" of the effect.

Version 2.0 - Pretty well documented and should follow all your advice.

// Emit myst

r_effect "progs/invulner.mdl" te_pent   // If this model appears, have it emit this effect.  invulner = Pentagram of Protection

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 static                         // 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.    
        
    // 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
}