llLinkParticleSystem

function

Function syntax

llLinkParticleSystem(

integer link,// Link number (1 for root, >1 for children) or a LINK_* flag. Values: Links
list rules// A list of particle system rules and data pairs [rule1, data1, ...], or a ParticleParams dictionary.

);

Energy: 10

These functions are almost entirely identical.

The big difference is that llParticleSystem acts upon the prim the script is in, llLinkParticleSystem on the other hand can act upon any prim in the object.

A particle system defined by a list of rules is set for the prim(s) link.

llLinkParticleSystem(0, []);

Specification

From the LSL definitions: ParticleParam (rule, then its arguments)

// Emitter pattern and burstPSYS_SRC_PATTERN, integer pattern  // PSYS_SRC_PATTERN_*PSYS_SRC_BURST_RATE, float burst_sleep  // seconds between bursts; 0.0 is as fast as the viewer canPSYS_SRC_BURST_PART_COUNT, integer burst_particle_countPSYS_SRC_BURST_RADIUS, float radius  // metres from the emitter; ignored with PSYS_PART_FOLLOW_SRC_MASK// Particle appearancePSYS_PART_START_COLOR, vector color_startPSYS_PART_END_COLOR, vector color_end  // needs PSYS_PART_INTERP_COLOR_MASKPSYS_PART_START_ALPHA, float alpha_start  // 0.0 to 1.0PSYS_PART_END_ALPHA, float alpha_end  // needs PSYS_PART_INTERP_COLOR_MASKPSYS_PART_START_SCALE, vector scale_start  // 0.03125 to 4.0 m per axis; z ignoredPSYS_PART_END_SCALE, vector scale_end  // needs PSYS_PART_INTERP_SCALE_MASKPSYS_PART_START_GLOW, float glow_start  // 0.0 to 1.0PSYS_PART_END_GLOW, float glow_endPSYS_SRC_TEXTURE, string texture  // inventory name or UUIDPSYS_PART_BLEND_FUNC_SOURCE, integer bf_source  // PSYS_PART_BF_*; default _SOURCE_ALPHAPSYS_PART_BLEND_FUNC_DEST, integer bf_dest  // PSYS_PART_BF_*; default _ONE_MINUS_SOURCE_ALPHA// MotionPSYS_SRC_BURST_SPEED_MIN, float speed_min  // m/sPSYS_SRC_BURST_SPEED_MAX, float speed_max  // m/sPSYS_SRC_ACCEL, vector acceleration  // m/s², region axes; -100.0 to 100.0 per axisPSYS_SRC_OMEGA, vector omega  // pattern rotation per burst, region axesPSYS_SRC_ANGLE_BEGIN, float angle_begin  // half angle in radians; ANGLE patternsPSYS_SRC_ANGLE_END, float angle_end  // half angle in radians; ANGLE patternsPSYS_SRC_TARGET_KEY, key target  // needs PSYS_PART_TARGET_POS_MASK or _LINEAR_MASKPSYS_SRC_INNERANGLE, float angle_inner  // deprecated: use PSYS_SRC_ANGLE_BEGINPSYS_SRC_OUTERANGLE, float angle_outer  // deprecated: use PSYS_SRC_ANGLE_END// LifetimePSYS_PART_MAX_AGE, float duration_particle  // seconds per particle; at most 30.0PSYS_SRC_MAX_AGE, float duration_system  // seconds the emitter runs; 0.0 is forever// FlagsPSYS_PART_FLAGS, integer flags  // PSYS_PART_*_MASK, combined with |

Defines a particle system that sets the state of the particle emitter within the prim that contains the script. Any other scripts, in the same prim, that call this function will modify the state of the same particle emitter. As such, the particle system defined by this function is a prim property, just like its size, shape, color, etc.

Each prim has only one (1) particle emitter, located at its geometric center, and aligned along the prim’s local Z-axis, pointing in the positive Z direction.

This is the one of the only functions which alters the state of the prim’s particle emitter; thus, if you wish to change the emitter to a different state (i.e., emitting a different particle system entirely, or shut off the emitter completely), just call the function with the parameters of the new particle system you wish to render instead. Specifying an empty list (i.e., llParticleSystem([]); ) turns the emitter off.

Particles are essentially 2D sprites and are always rendered facing the viewer’s camera (except when PSYS_PART_RIBBON_MASK is enabled).

The rule / data values are defined below.

Shared wiki article

This page transcludes LlParticleSystem. The following text is from that archived revision.

Caveats

When using particle systems that have a non-zero emitter age (PSYS_SRC_MAX_AGE) setting, you may notice that the particle system may restart without any scripted trigger going off. This is due to a bug which causes the emitter to “reset” when any of the prim properties are updated or otherwise sent to the viewer. As a result, you may have to use a timer or a forced sleep and then clear the particle system once the age has expired. Debbie Trilling has posted a work-around here: https://forums-archive.secondlife.com/54/fa/260031/1.html#post1996465
The spin defined by PSYS_SRC_OMEGA is relative to the region coordinate system, NOT the prim’s local coordinate system.
New non-zero vector values for PSYS_SRC_OMEGA will not re-align the emitter with the prim before they take effect. The viewer will continue rotating the emitter with the new omega values, starting from the last known orientation of the emitter. The emitter’s current orientation is determined by the viewer, not the simulator, and two people looking at the same effect may see different results. To re-align the emitter with the prim, create an effect with PSYS_SRC_OMEGA set to ZERO_VECTOR long enough for the viewer to have a chance to render it.
Particles moving towards a humanoid avatar, specified by PSYS_SRC_TARGET_KEY rule and setting the PSYS_PART_TARGET_POS_MASK flag, will end up at the geometric center of the avatar’s bounding box which, unfortunately, make them appear to be striking the person in the groin area. If you want them to end up at another point on a target avatar, you instead have to place a target prim that is moved to the position where you wish them to end up, and use the key of that prim for the value of the PSYS_SRC_TARGET_KEY rule.
The Second Life viewer uses optimizations in culling objects which are too small to see at certain distances. If your emitter is very small, and is culled due to distance, the particle system associated with it will not be rendered either.
Particles will also be culled beyond a maximum distance depending on their own scale. If particles are desired to be visible from further away yet be visually smaller, a larger scale and a texture with empty padding space are needed. If using PSYS_PART_RIBBON_MASK, make sure the Y scale is set properly, as it is used for this calculation even the rendering of the ribbon particles themselves ignores it.
When PSYS_PART_FOLLOW_VELOCITY_MASK is enabled, particles with zero velocity (e.g. generated by the DROP pattern, without acceleration, wind or target position following) are not rendered at all. Particles following their source via PSYS_PART_FOLLOW_SRC_MASK does not count as having a velocity, even if the source is moving.

Examples

Example 1

This example produces an effusion of glowing red spheres:

llParticleSystem( [
        PSYS_PART_FLAGS,       PSYS_PART_WIND_MASK | PSYS_PART_EMISSIVE_MASK,
        PSYS_SRC_PATTERN,      PSYS_SRC_PATTERN_EXPLODE,
        PSYS_PART_START_COLOR, <1.0, 0.0, 0.0>
    ] );

Helper functions

Useful functions for storing/retrieving color and alpha values to/from integers:

integer ColorAlphatoRGBA(vector color, float alpha) {
    return (((integer)(alpha   * 255.0) & 0xFF) << 24) |
           (((integer)(color.x * 255.0) & 0xFF) << 16) |
           (((integer)(color.y * 255.0) & 0xFF) <<  8) |
            ((integer)(color.z * 255.0) & 0xFF);
}

vector RGBAtoColor(integer rgba) {
    return < ((rgba >> 16) & 0xFF) / 255.0, ((rgba >> 8) & 0xFF) / 255.0, (rgba & 0xFF) / 255.0 >;
}

float RGBAtoAlpha(integer rgba) {
    return ((rgba >> 24) & 0xFF) / 255.0;
}

Notes

Other Notes

The default particle count for the client is normally set at 4096. That is the max particle count the client will render for ALL active particle systems within view range. Good particle system design is key to avoid “spamming” everyone with your particles, and starving out other people’s particle systems. As such, if you are experiencing trouble getting your particle emitter to emit as many particles as you like, it may be the victim of particle starvation. Client/viewer lag (low frame rates) can also cause this issue, as particles are a rather low priority for rendering. The best solution for this is to move to a less laggy environment relatively free of other particle systems when designing and testing your own.
Once particles are emitted, their direction of motion can only be affected by PSYS_SRC_ACCEL, the PSYS_PART_TARGET_POS_MASK flag, or the PSYS_PART_FOLLOW_SRC_MASK flag. As such, there is no good way to create the “swirling vortex” effect (like the one used in the viewer to indicate an object talking, begin derezzed, or when an avatar leaves the sim/grid). The effect can be created with a moving particle source (E.G. An orbiting script.)
Although the declared particle sizes are always in multiples of 0.03125 meters, PSYS_PART_INTERP_SCALE_MASK allows smooth transitions between the start and end values. This also applies to a size of ZERO_VECTOR, e.g. scaling a particle from or to nothing.
https://wiki.secondlife.com/wiki/User:Talia_Tokugawa/concept/CrazyParticle Something Talia realised that blew her mind, Documenting experiments with particles, including tutorial of how to do video particles, and how to (disputably) massively exceed the 8192 Limit in terms of how many particles SL can render at one time. (Whilst rendering video on particles is not new just (until now) undocumented, I am fairly confident in saying the method to exceed the particle limit is new.)

History

Date of release llParticleSystem 21-02-2007 or 14-03-2007
Date of release llLinkParticleSystem29-03-2010

Known issues

From the issue templates included by the wiki article:

SVC-1640 (nf): Particle Glow Parameters for llParticleSystem
SVC-4897 (nf): llSetSyncTime() - a function for synchronising client side effects
SVC-185 (bug): llParticleSystem (and others) anal about types

The original wiki page documents these functions together with this one:

llParticleSystem

Original wiki source

Some wiki templates and tables need their original context. View this article on the Second Life Wiki. Technical wording and examples are retained from the source; historical guidance may differ from current behavior.