Particle System Guide

A particle system suggestion. Would it be possible to add PositionColorFlipbookAndAlignVector dataChannelFormat?

Unnecessary, as PositionColorAndAlignVector already includes support for flip books.

Thanks, I didn't know it.

@bgolus - first off WOW - the first decent documentation for modding PA. Very nice and a big thank you for taking the time to put it together.

However..

Where is the documentation for writing server mods and everything else? Does this documentation mean you feel the effects modding won't be changing for awhile?

Server mods are totally outside of my purview or knowledge. I can't give you any kind of information on it at all. I did the documentation for the particles in part for myself, and most of it was written on my own time and as a way to codify some of the particle system's internals while I do some related work.

As for if I feel the effects modding "won't be changing for a while". I'm not exactly sure what you're trying to ask. The way you make effects is what it is, and there isn't going to be a tool beyond your text editor of choice for working on them. Over time we've added a few extra features and fixed a few bugs (many of which I came across and fixed more of during writing this documentation), but I wouldn't expect huge new features, no.

Sorry I meant that you don't expect any changes to the particle/emitter system that would warrant edits/rewrites of this documentation.

I had assumed that the reason we have no documentation for things like the server modding is because the system is not fleshed out enough yet.

I have a question, how exactly is the drag coefficient applied to particles? I am talking about a frame by frame basis here. Is it like this (so frame rate influences the speed at which particles slow down):
new_velocity = old_velocity * drag
Or is it like this (frame rate shouldn't influence slow rate bar floating point error):
new_velocity = old_velocity * pow(drag, time_delta)
Where time_delta is sim's next simulation step size.

I believe it is neither.

If I remember correctly it's the naive "velocity -= velocity * drag * time_delta", which is framerate dependent but not as horribly as straight "velocity = velocity * drag".

The above is incorrect. We do drag and acceleration at a constant tick rate.

The short version of the pseudo code is:

Code:

float fixedStep = 1/60;
int count = dt / fixedStep;
float currentDrag = drag;
for( i=1; i < count; i++)
{
    currentDrag *= drag;
}
velocity *= currentDrag;

The real code also keeps a time delta accumulation to deal with the missed time. Fixed time step stuff like this is really common in games even if it might not be as accurate as using a power.

edit: fixed typo in pseudo code

Is the last line supposed to be velocity *= currentDrag? This actually makes sense, though it does make the drag parameter very 'strong' at slowing down particles.

So if I wanted to slow down a particle by about half speed in one second, I would use pow(0.5, 1/60) as the drag parameter?

Yes, and yes.

This may be a good thing to mention in the doc! xD, this way the drag is more deterministic to the user.

Or I should change drag now to be 0.5 means reduce speed by half a over a second... hmm, choices.

Well, anything to avoid writing more complicated docs right? xD

So I think I stumbled upon a bug in the particle system. If you have an emitter with a delay, everything will work as documented. As soon as you switch the spec.shape to 'string', the system ignores the delay and the particles are generated immediately.

If this isn't a bug, then perhaps this is worth mentioning in the docs~ I was kinda pulling my hair our assuming I was doing something wrong xD.

Yep, bug. Support for emitter delay was missing for string emitters. Fixed.

<3 <3 <3 Thanks a lot! :3

The fixes discussed so far are live in the PTE (build 77398).
plus a little something extra, check out Anchors and Sniper Bots

BEAM PARTICLE TYPE HYPE

So can the beam weapon be given a certain distance for it's ending vertex?


If yes..........

Spoiler