multiple llParticleSystem?

list explosion = [
    PSYS_PART_FLAGS, PSYS_PART_EMISSIVE_MASK,
    PSYS_SRC_PATTERN, PSYS_SRC_PATTERN_EXPLODE,
    PSYS_PART_START_COLOR, <1,0,0>,
    PSYS_PART_MAX_AGE, 4.0,
    PSYS_SRC_BURST_SPEED_MIN, 17.0,
    PSYS_SRC_BURST_SPEED_MAX, 17.0,
    PSYS_SRC_BURST_PART_COUNT, 300,
    PSYS_SRC_BURST_RATE, 1.0
];

llParticleSystem(explosion);

is it possible in any way to decrease the PSYS_SRC_BURST_RATE without having a major
drop in the amount actual rendered particles, or rather, is it possible to somehow have two llParticleSystem functions running consecutively, maybe on two linked prims, or would linking the prims mean they'll only use the parents' scripts?

i'm currently at work so i cant really log into SL and actually test those things on my own, so.. yeah.. if anyone could help, it'd be nice.

Simple answer to your question, yes you could do what you were describing.

You can have different particle systems in linked prims. Timing them so that they fire exactly at certain intervals is a bit tricky (or maybe impossible - I haven't really experimented enough to say), but in most applications exact timing is not a key issue.

(I see we posted at the same time...)

Like everything else, it depends on the nature of the effect you want. From the looks of your particle system, it looks like you are sending out rapidly-moving pulses of lots of particles every second, which last for 4 seconds each.

The problem you are probably running into is that your emitter (the one you describe there) is getting on towards the "spammy" side of design. It uses a budget of 1200 particles, of which there is only 4096 (the default max particle count setting for the viewer, which most people don't change) available. That is TOTAL particles drawn by the viewer; yours and everyone else's combined (in the same viewable region).

As such, decreasing the burst rate value will eventually cause a noticeable drop in the amount of particles generated per burst, because you will be hitting the limit of the viewer.

Here's how to determine your "particle budget":

Particle_Budget = Burst_Count / Burst_Rate * Particle_Age

The Emitter_Age can also affect this, but most PS don't use it. Now, again, depending on the type of effect you are wanting to get, you can modify any of those 3 parameters to alter the "flow" of particles. Given that you are trying to simulate an explosion, I think you are pretty close to what you want, but maybe lowering the particle count a bit might help if you want to increase the rate.

Generally, I try to keep my particle budgets for most effects under 500. Some very temporary effects I might put up to 1000, but I try to avoid going over 1000 for any effect which is not on my own private part of my land, or is given to someone else as part of a product.

No need to experiment -- particles are purely client-side and as such can't be completely controlled by scripts. As with llTargetOmega, you can turn 'em on or off, but you can't synchronize two of them.

... well ... actually ...

Keep in mind that particles are an attributes of prims, scripts merely describe and enable those attributes.

If the prims already have particle effects defined, those particles can be seen as soon as the prims they're connected to are seen by a client computer.

When someone approaches a linked set of prims, they usually appear all together. (I want to say always appear together but can't vouche for that)

This is why the PSYS_SRC_MAX_LIFE attribute which automatically turns off a particle emitter after a specific amount of time doesn't turn the effect off permanently. Anytime someone comes close enough to see that prim again... it resets the timer, but only on the client side, not for everyone.

This can result in synchronized particle displays... UNLESS scripts try to activate or update particles AFTER an observer has arrived.

I first noticed this behavior with a flag I was working on, made by a row of emitters that were affected by wind and bounce. I expected there to be a chaotic blur of particles bouncing independently...

What I got, were 7 rows of bouncing particles trailing away from the emitter... perfectly synchronized. [edit: minus, of course, the periodic drop-out of a particle due to saturation or other factors... but the particles that followed stayed synchronized)]