Particles

[Tattooshop]

Hello! I make a particle system and I need the particles to go in opposite directions strictly along one straight line. But when the particles rotate, the straight line breaks, it becomes swirl. How to make the particles go straight even if object rotates?

EDIT : particles follow the source but breaks on rotation.

llParticleSystem([PSYS_PART_MAX_AGE,1.48,
PSYS_PART_FLAGS, 307,
PSYS_PART_START_COLOR, <1.00000, 1.00000, 1.00000>,
PSYS_PART_END_COLOR, <1.00000, 1.00000, 1.00000>,
PSYS_PART_START_SCALE,<0.75863, 0.75704, 0.00000>,
PSYS_PART_END_SCALE,<0.75256, 0.75978, 0.00000>,
PSYS_SRC_PATTERN, 4,
PSYS_SRC_BURST_RATE,0.00,
PSYS_SRC_BURST_PART_COUNT,1,
PSYS_SRC_BURST_RADIUS,0.00,
PSYS_SRC_BURST_SPEED_MIN,0.00,
PSYS_SRC_BURST_SPEED_MAX,1.00,
PSYS_SRC_ANGLE_BEGIN, 1.57,
PSYS_SRC_ANGLE_END, 1.57,
PSYS_SRC_MAX_AGE, 0.0,
PSYS_SRC_TEXTURE, "8803a2bd-ea85-48e7-7d1c-baf07d2cfc45",
PSYS_PART_START_ALPHA, 0.50,
PSYS_PART_END_ALPHA, 0.50]);

This is how I need it to look even when spinning... if its possible.

That's how it looks when it rotates now...

Edited July 7, 2020 by Tattooshop

[Madelaine McMasters]

What you desire is not possible with particles. Once a particle exits the emitter, it is decoupled from the emitter's position and rotation and follows a trajectory determined by it's initial velocity (both magnitude and emission direction), potential gravitation, wind, and possible attraction to a target object. Imagine spraying water from a garden hose. Once the droplets leave, they don't care how you swing the hose, they're on their own.

It might be possible to place two transparent target prims in the rotating linkset, and have two emitters in your object that emit particles towards them. Even if that works, it will not look much like what you have in mind.

Animated textures would also, I think, not get you where you want to go.

I wish I had an idea that would work, Tattooshop.

Edited July 7, 2020 by Madelaine McMasters

[Tattooshop]

1 hour ago, Madelaine McMasters said:

What you desire is not possible with particles. Once a particle exits the emitter, it is decoupled from the emitter's position and rotation and follows a trajectory determined by it's initial velocity (both magnitude and emission direction), potential gravitation, wind, and possible attraction to a target object. Imagine spraying water from a garden hose. Once the droplets leave, they don't care how you swing the hose, they're on their own.

It might be possible to place two transparent target prims in the rotating linkset, and have two emitters in your object that emit particles towards them. Even if that works, it will not look much like what you have in mind.

Animated textures would also, I think, not get you where you want to go.

I wish I had an idea that would work, Tattooshop.

Thanks anyway!

 

[Fenix Eldritch]

There is a way to achieve the desired effect - or at least come pretty close. It won't look exactly the same, but maybe that's tolerable? It requires splitting your object into a single emitter for each side, and having each emitter target an invisible child prim off to the sides with PSYS_SRC_TARGET_KEY and PSYS_PART_TARGET_LINEAR_MASK.

llParticleSystem([PSYS_PART_MAX_AGE,1.48,
PSYS_PART_FLAGS, 0
    |PSYS_PART_INTERP_COLOR_MASK
    |PSYS_PART_INTERP_SCALE_MASK
    |PSYS_PART_FOLLOW_SRC_MASK
    |PSYS_PART_FOLLOW_VELOCITY_MASK
    |PSYS_PART_EMISSIVE_MASK
    |PSYS_PART_TARGET_LINEAR_MASK		//add this flag to make particles beeline to the target, even if orbiting
    ,
PSYS_SRC_TARGET_KEY,      llGetLinkKey(2), //specify the key of the target prim. (assumes emitter is root and target is link #2)
                  
PSYS_PART_START_COLOR, <1.00000, 1.00000, 1.00000>,
PSYS_PART_END_COLOR, <1.00000, 1.00000, 1.00000>,
PSYS_PART_START_SCALE,  <0.75863, 0.75704, 0.00000>,
PSYS_PART_END_SCALE,    <0.75256, 0.75978, 0.00000>,
PSYS_SRC_PATTERN, 1,			//changed to drop pettern (for use with targeting)
PSYS_SRC_BURST_RATE,0.25,		//dialed this back since we're emitting particles from only one side now.
PSYS_SRC_BURST_PART_COUNT,1,
PSYS_SRC_BURST_RADIUS,0.00,
PSYS_SRC_BURST_SPEED_MIN,0.00,
PSYS_SRC_BURST_SPEED_MAX,1.00,
PSYS_SRC_ANGLE_BEGIN, 1.57,
PSYS_SRC_ANGLE_END, 1.57,
PSYS_SRC_MAX_AGE, 0.0,
PSYS_SRC_TEXTURE, "8803a2bd-ea85-48e7-7d1c-baf07d2cfc45",
PSYS_PART_START_ALPHA, 0.50,
PSYS_PART_END_ALPHA, 0.50]);

I left comments where I added or altered your original particle script. You must link an extra prim to the emitter to serve as the target (and update the PSYS_SRC_TARGET_KEY as appropriate. You can then duplicate this for the other side and link them all together, again, making sure you keep your link targets correct for each emitter.

Sidenote: you have some extra stuff in there that is being unused and thus can be removed. You don't change the color, so you can remove PSYS_PART_INTERP_COLOR_MASK and the associated start/end parameters. Also, since you don't use pattern 4, you can remove the stuff relating to that as well (PSYS_SRC_ANGLE_BEGIN, PSYS_SRC_ANGLE_END, etc).

Edit: removing PSYS_PART_FOLLOW_VELOCITY_MASK may look better with the above script as well.

Edited July 7, 2020 by Fenix Eldritch
additional suggestion

[Madelaine McMasters]

43 minutes ago, Fenix Eldritch said:

There is a way to achieve the desired effect - or at least come pretty close.

What you describe is what I mentioned, I think. The particles will converge at the center of the invisible target prims. In the example shown, there is no convergence, the particles take parallel paths. If particle lifetime is short with respect to the movement of the target prims, they would trace a fairly straight path, but always converge at the target prim center. If the particles were emitted as a ring, normal to the path between the invisible target prims, I think that would create cones. If their lifetimes were long, you'd start to see swirl.

To achieve the look shown, you'd need quite a few emitters, with zero burst radius, arranged in a square, with an equal number of target prims, to ensure that the trails retained the square cross section.

Or, I'm missing something?

Edited July 7, 2020 by Madelaine McMasters

[Fenix Eldritch]

5 minutes ago, Madelaine McMasters said:

The particles will converge at the center of the invisible target prims. In the example shown, there is no convergence, the particles take parallel paths.

Normally yes, you would be correct. However we have a very specific edge case here, due to the nature of the particle texture being used. The texture is a square with multiple colored dots scattered around which gives the effect of multiple streams at once. Because of that, we can have a single emitter produce a single stream of this textured particle which gives the appearance of multiple streams. And that single stream can easily target a child prim on the same local axis to create the effect OP was looking for.

[Madelaine McMasters]

6 minutes ago, Fenix Eldritch said:

Normally yes, you would be correct. However we have a very specific edge case here, due to the nature of the particle texture being used. The texture is a square with multiple colored dots scattered around which gives the effect of multiple streams at once. Because of that, we can have a single emitter produce a single stream of this textured particle which gives the appearance of multiple streams. And that single stream can easily target a child prim on the same local axis to create the effect OP was looking for.

I hadn't thought of that! That does create another problem, which I think the "ribbon" effect might address, though I'm doubtful. Normal particle textures are always normal to the camera. You want the textures to always be normal to the path.

 

Edited July 7, 2020 by Madelaine McMasters

[Love Zhaoying]

It's the "peeing in the wind" effect!

[Love Zhaoying]

8 minutes ago, Madelaine McMasters said:

You want the textures to always be normal to the path.

Technically, I thought that particle textures are always "normal" to the viewer, so that the user can "see" them.

[Fenix Eldritch]

Unfortunately no, using the ribbon flag would totally wipe out the layered 3D effect you get from staking multiple particles together normally like that. Here's a gif of what it looks like using my suggested settings. I think it's reasonably close.

[Madelaine McMasters]

16 minutes ago, Fenix Eldritch said:

Unfortunately no, using the ribbon flag would totally wipe out the layered 3D effect you get from staking multiple particles together normally like that. Here's a gif of what it looks like using my suggested settings. I think it's reasonably close.

That's as perfect as I could imagine here, Fenix

How did you set the particles normal to the path, not the camera?

ETA: Oooh, maybe they are still normal to the camera?

ETA2: Yep, the red particles shift orientation with respect to the center prim as the linkset rotates. Nevertheless, it's a really good approximation.

ETA3: As I look at the original example, with dots of various colors, it's clear I looked completely past the obviousness of a single large texture containing the entire array of multi-colored particles.

I need more sleep.

Edited July 7, 2020 by Madelaine McMasters

[Fenix Eldritch]

17 hours ago, Madelaine McMasters said:

ETA: Oooh, maybe they are still normal to the camera?

Yup, it just happens to work out in our favor this time. Here's the contraption at a better angle

Edited July 8, 2020 by Fenix Eldritch
typos

[Tattooshop]

3 hours ago, Fenix Eldritch said:

There is a way to achieve the desired effect - or at least come pretty close. I won't look exactly the same, but maybe that's tolerable? It requires splitting your object into a single emitter for each side, and having each emitter target an invisible child prim off to the sides with PSYS_SRC_TARGET_KEY and PSYS_PART_TARGET_LINEAR_MASK.

llParticleSystem([PSYS_PART_MAX_AGE,1.48,
PSYS_PART_FLAGS, 0
    |PSYS_PART_INTERP_COLOR_MASK
    |PSYS_PART_INTERP_SCALE_MASK
    |PSYS_PART_FOLLOW_SRC_MASK
    |PSYS_PART_FOLLOW_VELOCITY_MASK
    |PSYS_PART_EMISSIVE_MASK
    |PSYS_PART_TARGET_LINEAR_MASK		//add this flag to make particles beeline to the target, even if orbiting
    ,
PSYS_SRC_TARGET_KEY,      llGetLinkKey(2), //specify the key of the target prim. (assumes emitter is root and target is link #2)
                  
PSYS_PART_START_COLOR, <1.00000, 1.00000, 1.00000>,
PSYS_PART_END_COLOR, <1.00000, 1.00000, 1.00000>,
PSYS_PART_START_SCALE,  <0.75863, 0.75704, 0.00000>,
PSYS_PART_END_SCALE,    <0.75256, 0.75978, 0.00000>,
PSYS_SRC_PATTERN, 1,			//changed to drop pettern (for use with targeting)
PSYS_SRC_BURST_RATE,0.25,		//dialed this back since we're emitting particles from only one side now.
PSYS_SRC_BURST_PART_COUNT,1,
PSYS_SRC_BURST_RADIUS,0.00,
PSYS_SRC_BURST_SPEED_MIN,0.00,
PSYS_SRC_BURST_SPEED_MAX,1.00,
PSYS_SRC_ANGLE_BEGIN, 1.57,
PSYS_SRC_ANGLE_END, 1.57,
PSYS_SRC_MAX_AGE, 0.0,
PSYS_SRC_TEXTURE, "8803a2bd-ea85-48e7-7d1c-baf07d2cfc45",
PSYS_PART_START_ALPHA, 0.50,
PSYS_PART_END_ALPHA, 0.50]);

I left comments where I added or altered your original particle script. You must link an extra prim to the emitter to serve as the target (and update the PSYS_SRC_TARGET_KEY as appropriate. You can then duplicate this for the other side and link them all together, again, making sure you keep your link targets correct for each emitter.

Sidenote: you have some extra stuff in there that is being unused and thus can be removed. You don't change the color, so you can remove PSYS_PART_INTERP_COLOR_MASK and the associated start/end parameters. Also, since you don't use pattern 4, you can remove the stuff relating to that as well (PSYS_SRC_ANGLE_BEGIN, PSYS_SRC_ANGLE_END, etc).

Edit: removing PSYS_PART_FOLLOW_VELOCITY_MASK may look better with the above script as well.

It works! Thank you so much!

 

 

[Tattooshop]

On 7/7/2020 at 7:37 PM, Fenix Eldritch said:

There is a way to achieve the desired effect - or at least come pretty close. It won't look exactly the same, but maybe that's tolerable? It requires splitting your object into a single emitter for each side, and having each emitter target an invisible child prim off to the sides with PSYS_SRC_TARGET_KEY and PSYS_PART_TARGET_LINEAR_MASK.

llParticleSystem([PSYS_PART_MAX_AGE,1.48,
PSYS_PART_FLAGS, 0
    |PSYS_PART_INTERP_COLOR_MASK
    |PSYS_PART_INTERP_SCALE_MASK
    |PSYS_PART_FOLLOW_SRC_MASK
    |PSYS_PART_FOLLOW_VELOCITY_MASK
    |PSYS_PART_EMISSIVE_MASK
    |PSYS_PART_TARGET_LINEAR_MASK		//add this flag to make particles beeline to the target, even if orbiting
    ,
PSYS_SRC_TARGET_KEY,      llGetLinkKey(2), //specify the key of the target prim. (assumes emitter is root and target is link #2)
                  
PSYS_PART_START_COLOR, <1.00000, 1.00000, 1.00000>,
PSYS_PART_END_COLOR, <1.00000, 1.00000, 1.00000>,
PSYS_PART_START_SCALE,  <0.75863, 0.75704, 0.00000>,
PSYS_PART_END_SCALE,    <0.75256, 0.75978, 0.00000>,
PSYS_SRC_PATTERN, 1,			//changed to drop pettern (for use with targeting)
PSYS_SRC_BURST_RATE,0.25,		//dialed this back since we're emitting particles from only one side now.
PSYS_SRC_BURST_PART_COUNT,1,
PSYS_SRC_BURST_RADIUS,0.00,
PSYS_SRC_BURST_SPEED_MIN,0.00,
PSYS_SRC_BURST_SPEED_MAX,1.00,
PSYS_SRC_ANGLE_BEGIN, 1.57,
PSYS_SRC_ANGLE_END, 1.57,
PSYS_SRC_MAX_AGE, 0.0,
PSYS_SRC_TEXTURE, "8803a2bd-ea85-48e7-7d1c-baf07d2cfc45",
PSYS_PART_START_ALPHA, 0.50,
PSYS_PART_END_ALPHA, 0.50]);

 

Let me please raise this topic again, but is there any way to unite everything in one system of particles in one script for both emitters? Like for particle prim 1 - llGetLinkKey(2) and for particle prim 2 - llGetLinkKey(4)? If that makes sense...

 

[Fenix Eldritch]

Sure, llLinkParticleSystem will let you create multiple particle emitters in a link set from a single, central script. You can even use the same base particle list, and just add the target specific stuff like [PYS_SRC_TARGET_KEY, <uuid>] for each independent call.

default
{
    state_entry()
    {
        llLinkParticleSystem(LINK_SET, []);
        list partList = [
            PSYS_PART_MAX_AGE,1.48,
            PSYS_PART_FLAGS, 0
                |PSYS_PART_INTERP_SCALE_MASK
                |PSYS_PART_FOLLOW_SRC_MASK
                |PSYS_PART_FOLLOW_VELOCITY_MASK
                |PSYS_PART_EMISSIVE_MASK
                |PSYS_PART_TARGET_LINEAR_MASK
            ,
            PSYS_PART_START_SCALE,  <0.75863, 0.75704, 0.00000>,
            PSYS_PART_END_SCALE,    <0.75256, 0.75978, 0.00000>,
            PSYS_SRC_PATTERN, 1,
            PSYS_SRC_BURST_RATE,0.1,
            PSYS_SRC_BURST_PART_COUNT,1,
            PSYS_SRC_BURST_RADIUS,0.00,
            PSYS_SRC_BURST_SPEED_MIN,0.00,
            PSYS_SRC_BURST_SPEED_MAX,1.00,
            PSYS_SRC_ANGLE_BEGIN, 1.57,
            PSYS_SRC_ANGLE_END, 1.57,
            PSYS_SRC_MAX_AGE, 0.0,
            PSYS_SRC_TEXTURE, "8803a2bd-ea85-48e7-7d1c-baf07d2cfc45",
            PSYS_PART_START_ALPHA, 0.50,
            PSYS_PART_END_ALPHA, 0.50
            ];
        
        llLinkParticleSystem(1, partList+[PSYS_SRC_TARGET_KEY, llGetLinkKey(2)]);	//update both link numbers here
        llLinkParticleSystem(3, partList+[PSYS_SRC_TARGET_KEY, llGetLinkKey(4)]);	//update both link numbers here

    }

}

As always, it is up to you to keep track of which link number is which and update them accordingly.

Edit: one other thing to be aware of is that particle systems are prim properties, which means they persist. This is important because if you take the object into inventory and re-rez it, all prims will have new uuids, and the persisting particle property will retain the old values - which means the particles won't target anything until you call the particle functions again to update the targets (or reset the script, depending on how the final script is written).

Edited July 10, 2020 by Fenix Eldritch

[Tattooshop]

Amazing! Thank you so much @Fenix Eldritch again! 👍

 

Edited July 11, 2020 by Tattooshop

[Tattooshop]

@Fenix Eldritch @Madelaine McMasters 

Hello there!

Sorry to bother you again.

I added a particle system to the main script and found a rather strange behavior. When moving forward, the particles bend forward by the letter V past the prim to which they must move. But as soon as the sim crossing occurs, the particles are aligned in a straight line. Why this may happen?

startParticlesF(integer link)
{
        llLinkParticleSystem(link, []);
        list partList = [
            PSYS_PART_MAX_AGE,1.50,
            PSYS_PART_FLAGS, 0
                |PSYS_PART_INTERP_SCALE_MASK
                |PSYS_PART_FOLLOW_SRC_MASK
                |PSYS_PART_EMISSIVE_MASK
                |PSYS_PART_TARGET_LINEAR_MASK
            ,
            PSYS_PART_START_SCALE,  <0.50000, 0.50000, 0.00000>,
            PSYS_PART_END_SCALE,    <0.50000, 0.50000, 0.00000>,
            PSYS_SRC_PATTERN, 1,
            PSYS_SRC_BURST_RATE,0.1,
            PSYS_SRC_BURST_PART_COUNT,2,
            PSYS_SRC_BURST_RADIUS,0.00,
            PSYS_SRC_BURST_SPEED_MIN,0.50,
            PSYS_SRC_BURST_SPEED_MAX,1.00,
            PSYS_SRC_MAX_AGE, 0.0,
            PSYS_SRC_TEXTURE, "8803a2bd-ea85-48e7-7d1c-baf07d2cfc45",
            PSYS_PART_START_ALPHA, 0.50,
            PSYS_PART_END_ALPHA, 0.50
            ];        
        llLinkParticleSystem(FRONT_PARTICLES_1, partList+[PSYS_SRC_TARGET_KEY, llGetLinkKey(11)]);   
        llLinkParticleSystem(FRONT_PARTICLES_2, partList+[PSYS_SRC_TARGET_KEY, llGetLinkKey(12)]);     
}

I tried to use link numbers instead of FRONT_PARTICLES_1, but no changes...

 

EDIT: And the greater the speed, the more the particle line bends.

EDIT2: Oh by the way I used prims 11,12  for another particle system also, but as emitters, to save prims, and they turned to 45 degrees... Could that be a reason?

 

Edited July 15, 2020 by Tattooshop

[Love Zhaoying]

Sim crossings? Wow!!! Good luck ❤️

 

[Fenix Eldritch]

First up, when and how often are you calling that startParticlesF function? I see you are passing a single integer into this function, but only using that to clear the particle emitter on that single link. In my previous example, I started with clearing the particles from the entire LINK_SET simply as a shortcut for the demo. If you have the link numbers of the emitters already saved, and they aren't going to change, you can use that instead. My main point is that looking at this function in isolation, it seems you aren't properly cleaning up. (but that is tangential to the current issue you're seeing)

Secondly, if the desired behavior is shown in picture 2 (after region crossing) and you aren't repeatedly calling startParticlesF on a region crossing, then it's probably safe to assume you have the correct link numbers stored and the problem isn't with them.

I'm not able to reproduce your issue, but perhaps you could try removing the extra particle parameters that are not being used.

Failing that, my guess is that it might be a viewer/networking issue. Maybe. Hard to tell. I've experienced a similar oddity with a vehicle that is supposed to have a short lived particle exhaust that follows the source emitter. In practice, I will see that the particles be drawn ahead of the actual emitter - but the behavior corrects itself on a region crossing. Been meaning to write up a JIRA on that, but I need to make a demo that reliably produces the issue.

This might not help, but see if your viewer has "velocity interpolate objects" and "ping interpolate object positions" enabled (look under Develop > Networking menu items)

Edited July 15, 2020 by Fenix Eldritch
region, not sim :)

[Love Zhaoying]

Suggestion: Detect sim crossing, and restart / rerun particle script.

[Tattooshop]

17 minutes ago, Fenix Eldritch said:

First up, when and how often are you calling that startParticlesF function? I see you are passing a single integer into this function, but only using that to clear the particle emitter on that single link. In my previous example, I started with clearing the particles from the entire LINK_SET simply as a shortcut for the demo. If you have the link numbers of the emitters already saved, and they aren't going to change, you can use that instead. My main point is that looking at this function in isolation, it seems you aren't properly cleaning up. (but that is tangential to the current issue you're seeing)

Secondly, if the desired behavior is shown in picture 2 (after region crossing) and you aren't repeatedly calling startParticlesF on a region crossing, then it's probably safe to assume you have the correct link numbers stored and the problem isn't with them.

I'm not able to reproduce your issue, but perhaps you could try removing the extra particle parameters that are not being used.

Failing that, my guess is that it might be a viewer/networking issue. Maybe. Hard to tell. I've experienced a similar oddity with a vehicle that is supposed to have a short lived particle exhaust that follows the source emitter. In practice, I will see that the particles be drawn ahead of the actual emitter - but the behavior corrects itself on a region crossing. Been meaning to write up a JIRA on that, but I need to make a demo that reliably produces the issue.

This might not help, but see if your viewer has "velocity interpolate objects" and "ping interpolate object positions" enabled (look under Develop > Networking menu items)

Thank you very much for your reply!

Yes "velocity interpolate objects" was enabled and "ping interpolate object positions" is enabled now.

 

It’s even stranger that when the vehicle moves ( before sim crossing ) and I’m just right click it > Edit > and rotate it to any angle or just drag a side - particles getting aligned...

[Tattooshop]

6 hours ago, Fenix Eldritch said:

In my previous example, I started with clearing the particles from the entire LINK_SET simply as a shortcut for the demo. If you have the link numbers of the emitters already saved, and they aren't going to change, you can use that instead. My main point is that looking at this function in isolation, it seems you aren't properly cleaning up. (but that is tangential to the current issue you're seeing)

I decided to rewrite the startParticlesF function but I can’t make it to work for two pairs emitter - target in one system as in your example.

startParticlesF(integer link)
{
llLinkParticleSystem(link, [PSYS_PART_MAX_AGE,1.50,
PSYS_PART_FLAGS, 419,
PSYS_PART_START_COLOR, <1.00000, 1.00000, 1.00000>,
PSYS_PART_END_COLOR, <1.00000, 1.00000, 1.00000>,
PSYS_PART_START_SCALE,<0.50000, 0.50000, 0.00000>,
PSYS_PART_END_SCALE,<0.50000, 0.50000, 0.00000>,
PSYS_SRC_PATTERN, 4,
PSYS_SRC_BURST_RATE,0.10,
PSYS_SRC_BURST_PART_COUNT,2,
PSYS_SRC_BURST_RADIUS,0.00,
PSYS_SRC_BURST_SPEED_MIN,0.50,
PSYS_SRC_BURST_SPEED_MAX,1.00,
PSYS_SRC_ANGLE_BEGIN, 1.57,
PSYS_SRC_ANGLE_END, 1.57,
PSYS_SRC_MAX_AGE, 0.0,
PSYS_SRC_TEXTURE, "8803a2bd-ea85-48e7-7d1c-baf07d2cfc45",
PSYS_PART_START_ALPHA, 0.50,
PSYS_PART_END_ALPHA, 0.50,
PSYS_SRC_TARGET_KEY, llGetLinkKey(3)]);
}

EDIT: Just tried with only one pair - the same effect...

Edited July 15, 2020 by Tattooshop

[Fenix Eldritch]

14 hours ago, Tattooshop said:

but I can’t make it to work for two pairs emitter - target in one system

By "one system", do you mean a single call to llLinkParticleSystem? If so, that is not possible. The particle system functions are not like the llSetPrimitiveParams functions which can let you target multiple discrete prims at once via the PRIM_LINK_TARGET in the parameters list. There is no equivalent for llLinkParticleSystem. Your only options for that are to use the single link number parameter which can be a specific number or one of the special LINK_* flags. If you want to turn link #3 and #5 into particle emitters, then you need two separate calls to llLinkParticleSystem, specifying the appropriate link each time.

That is why I split things up the way I did in my example. The majority of the particle parameter list was identical between the two, so I created that separately and then made an ad hoc list appending the unique parameters (the target) when actually calling each llLinkParticleSystem.

Edited July 16, 2020 by Fenix Eldritch
typos, of course