Aurora Reference
A particle system is defined in a .aur file. Each .aur file can define any number of
particle types, and they may interact with each other.
At the top of any .aur file, the following fields need to be defined -
-
particles
The number of particles to allocate for this system. This defines how
many particles the system can ever have in existence at one time. (If this number is too
small, you will probably find that your particle sprays will stop and start.)
-
maintype
The root of the particle system. Put the name of a particle type here,
and the particle system will create one particle of that type at your env_particle entity.
(It will also follow the env_particle entity at all times, and it won't die until you switch
the env_particle entity off.)
If the system is going to create any other particles, the main particle will be the one
that creates them.
After this come the particle types. The beginning and end of a particle type are marked with
{}. Between them you define a set of parameters, chosen from the following.
-
name
This is essential. Particle types are always referred to by their names.
You can use any name you want, so long as you use the same name everywhere. (I've used
capital letters to help distinguish my particle names from the other values, but this isn't
compulsory.)
-
lifetime
Particles of this type will live for this many seconds. If you leave this
undefined, or choose 0, then the particle will be immortal.
-
sprite
Particles of this type will display this sprite. If you want your particles
to be visible, this is essential.
-
startsize, endsize, sizedelta
If you want your particles to be visible, you must
define a size for them. (The default size is 0). Note that you have a choice - either
define an endsize that the particle should reach by the time it dies, or else define the
sizedelta, i.e. the rate the particle should grow every second.
-
gravity
Particles of this type will accelerate upwards by this amount each second.
(To make particles which fall, put a negative number here). The default is 0.
-
drag
Particles of this type will slow down by this proportion of their speed each
second. This allows you to make, for example, dust which gets emitted at high speed from an
explosion, then slows down as it encounters air friction. The default is 0.
-
windspeed, windyaw
Drag works by considering the speed of the particle relative to
the speed of the air it's moving through. If you set a windspeed, then instead of slowing it
down until it stops, drag will slow it down or speed it up to match the wind speed.
Currently, wind will always travel horizontally.
-
spraytype, sprayrate
Particles of this type will emit particles of the type
spraytype, and will do so sprayrate times each second for as long as they
live. (Note that if sprayrate is a random number, a different delay will be chosen for
each spraying.)
-
sprayforce, sprayyaw, spraypitch
The particles sprayed will be emitted at
this speed, travelling in this direction.
-
startalpha, endalpha, startred, endred, startgreen, endgreen, startblue, endblue
Particles of this type will be created with the given start colour and brightness, and will
fade over their lifetime to the end colour and brightness. All these fields range from 1
(brightest) to 0 (darkest). If you leave a field undefined, it will default to 1.
-
startangle, angledelta
Particles can be tilted to any angle. (But note that they
still face the player at all times). Particles of this type will be tilted at
startangle degrees when they're first created, and will rotate at angledelta
degrees per second throughout their lifetime. The default is 0 degrees.
-
startframe, endframe, framerate
Some sprites are animated. These fields allow you
to control how that animation will be displayed on each particle. Note that, like size, you
have a choice - either define a startframe and an endframe, or else define a startframe and
a framerate. The default for all these values is 0.
-
bounce, bouncefriction
If bounce is defined, particles of this type will
bounce when they hit solid objects. When bouncing off the floor, "bounce" shows how much
the particle slows down vertically, and "bouncefriction" shows how much it slows down
horizontally: 0 means it stops dead, 1 is a perfect bounce.
If you don't define "bounce" at all, or set it to be a negative number, then the particle
will pass through solid objects.
-
rendermode
This should either be "additive" (the default) or "solid". If you
choose solid, the particles will be displayed exactly like an env_sprite set to Rendermode
Solid: the last colour of the sprite palette will define the colour of the whole sprite,
and the palette position of each pixel will define its opacity. This is the only way to
create soft-edged black particles.
Things to note: in rendermode Solid, the particle's alpha value is ignored. In order to get
a Solid particle to fade out, try the trick used by blacksmoke.spr: make each
frame less and less opaque, until the last frame is barely visible. Then you can use
"startframe" and "endframe" to set opacity, instead of "startalpha" and "endalpha".
-
drawcondition
Particles won't be drawn unless their "drawcondition" matches the
contents of the position they're in. Valid drawconditions are "empty" (the particle must
be in clear air), "water" (the particle must be in water), "solid" (the particle must
be inside a solid object, most likely glass), and "special1", "special2", and "special3".
The default is for particles to be drawn at all times.
The last three are provided so that mappers can define their own particle-display zones,
for instance areas of light streaming through a window. To create such a zone, make a
func_illusionary and set its "contents" to the appropriate special value. (The special
content types have no other effect on the game.)
-
overlaytype
It's possible to have more than one particle drawn in a given place.
If a particle type has an overlaytype, then whenever a particle of that type gets created,
a second, overlay, particle will also be created. The two particles will always be drawn
together. Don't bother defining a "gravity", "drag", or "bounce" value for an overlay type
- it won't be used. Similarly, an overlay's "size" and "angle" are simply copied from the
parent particle.
However, an overlay can define its own sprite, frame, alpha, red, green, blue,
rendermode, and drawcondition.
© Laurie Cheers 2003.