Pause particle emitter

[GavotteValentine]

I'm trying to create a water faucet so that it drips a group of X water particles each burst, pause for X seconds, then drip again. As far as I know it's not possible to do this with particle settings alone (_BURST_RATE and _BURST_PART_COUNT etc) because setting _BURST_PART_COUNT to say 20 will only cause all 20 particles to be stacked into 1 particle (no idea why it does this as it seems pointless to me) instead of a stream of 20 particles. So the only thing I can think of is to have _PART_COUNT set to 1 and _BURST_RATE set to 0, emit particles for say 2 seconds, then pause for 2 seconds, and loop it.

The problem is how do I achieve this? I've tried llSensorRepeat and it doesn't work at all when inside an if statement.

list MENU_CHOICES = ["HIDE","drip","stop"];

//menu creator code

listen(integer channel, string name, key id, string choice)
   { 
    
     if (choice == "HIDE") {
        //hide
     }
     else if (choice == "drip") {
        llSensorRepeat("", "", SCRIPTED, 0, 0, 2);     
}
     else if (choice == "stop") {
        //stop water drip
     }

...
...

sensor(integer number_detected) {
//particle script
}

 Thanks.

[Emily Aries]

I would use a timer and 4 variables.

 

is_on

current_time

time_on

time_off

 

Start a timer at say 0.5 second intervals or lower if you need more fine grain control. Set time on and time off to how many half seconds you want the dripping to be of or off. Then each tick of the timer increment current time and check if it is >= to time off, if so turn on the particle emitter and set is on to true. If it is on then increment the current time until it matches time on and then turn off again.

 

On my phone at the moment so can't really write any code right now so hope thus helps. I can post some example code later if you are still having problems.

[Qie Niangao]

This is probably not close enough to the effect you have in mind, but it illustrates why the _PART_COUNT parameter isn't completely pointless:

default{    state_entry()    {        llParticleSystem([]);    }    touch_end(integer num_detected)    {        llParticleSystem(            [ PSYS_PART_FLAGS, FALSE            , PSYS_SRC_PATTERN              , PSYS_SRC_PATTERN_ANGLE            , PSYS_SRC_ANGLE_BEGIN, PI            , PSYS_SRC_ANGLE_END, PI            , PSYS_SRC_BURST_RATE, 2.0            , PSYS_SRC_BURST_PART_COUNT, 10            , PSYS_SRC_BURST_SPEED_MIN, 0.1            , PSYS_SRC_BURST_SPEED_MAX, 0.5            , PSYS_SRC_ACCEL, <0.0, 0.0, -1.0>            , PSYS_PART_START_SCALE, <0.05, 0.05, 0.0>            ]);    }}

You're wise to seek ways to create effects strictly within the particle system itself because that not only stops the script from having to keep running in a timer loop, it also obviates sending object updates once the particles are started. So its a big win, but only if it does what you need.

[Emily Aries]

integer is_on = FALSE; // Are the effects currently on or off?integer time_on = 2; // Time for the particle effects to be on.integer time_off = 8; // Time for the particle effects to be off.integer time_current = 0; // The current elapsed time.effects_on(){    llOwnerSay("Test On");    // Turn on particle effects and sounds.}effects_off(){    llOwnerSay("Test Off");    // Turn off particle effects and sounds.}default{    state_entry()    {        llSetTimerEvent(0.5); // Timer fires every half second so divide time_current by 2 to get work out the seconds.        // Decrease this if you want finer control but remember to increase time_on and time_off to compensate.    }    timer()    {        time_current += 1; // Increment elapsed time.                if(is_on)        {            if(time_current >= time_on)            {                effects_off();                                time_current = 0; // Important!                is_on = FALSE; // Toggle            }        }        else        {            if(time_current >= time_off)            {                effects_on();                                time_current = 0; // Important!                is_on = TRUE; // Toggle            }        }    }}

 And I have access to a computer now woo. I hope this is roughly what you are looking for. Its exceptionally simple but I'm sure you can add in everything that you need.

[GavotteValentine]

Thanks for the example.

I already have a timer() in my script though, and I don't think two can be used? What should I do in this situation? Use llSensorRepeat and sensor()?

[GavotteValentine]

---

Qie Niangao wrote:

This is probably not close enough to the effect you have in mind, but it illustrates why the _PART_COUNT parameter isn't completely pointless:

default{    state_entry()    {        llParticleSystem([]);    }    touch_end(integer num_detected)    {        llParticleSystem(            [ PSYS_PART_FLAGS, FALSE            , PSYS_SRC_PATTERN              , PSYS_SRC_PATTERN_ANGLE            , PSYS_SRC_ANGLE_BEGIN, PI            , PSYS_SRC_ANGLE_END, PI            , PSYS_SRC_BURST_RATE, 2.0            , PSYS_SRC_BURST_PART_COUNT, 10            , PSYS_SRC_BURST_SPEED_MIN, 0.1            , PSYS_SRC_BURST_SPEED_MAX, 0.5            , PSYS_SRC_ACCEL, <0.0, 0.0, -1.0>            , PSYS_PART_START_SCALE, <0.05, 0.05, 0.0>            ]);    }}

You're wise to seek ways to create effects strictly within the particle system itself because that not only stops the script from having to keep running in a timer loop, it also obviates sending object updates once the particles are started. So its a big win, but only if it does what you need

 

Your script only works if the particle is being emitted from the root prim (no I'm not talking about llParticleSystem vs llLinkedParticleSystem). Mine doesn't do that as it's controlled through menu. I tried your particle script and all the particles are dripped sideways cause they're aimed at the object's root prim. Been tinkering for an hour and there doesn't seem to be a way to remove this nonsensical behaviour. The particle system is extremely limiting which is why I need the help of other functions.

[Emily Aries]

How often is you current timer firing? It should be relatively easy to work it in to your current script. If the current timer is faster then just increase the time_on and time_off to compensate. If it is slower then speed it up to work with the particle emitter and use an increment value also for whatever is it currently doing to keep it at the same time.

[LepreKhaun]

---

GavotteValentine wrote:

I'm trying to create a water faucet so that it drips a group of X water particles each burst, pause for X seconds, then drip again. As far as I know it's not possible to do this with particle settings alone (_BURST_RATE and _BURST_PART_COUNT etc) because setting _BURST_PART_COUNT to say 20 will only cause all 20 particles to be stacked into 1 particle (no idea why it does this as it seems pointless to me) instead of a stream of 20 particles. So the only thing I can think of is to have _PART_COUNT set to 1 and _BURST_RATE set to 0, emit particles for say 2 seconds, then pause for 2 seconds, and loop it.

The problem is how do I achieve this? I've tried llSensorRepeat and it doesn't work at all when inside an if statement.

list MENU_CHOICES = ["HIDE","drip","stop"];//menu creator codelisten(integer channel, string name, key id, string choice)   {          if (choice == "HIDE") {        //hide     }     else if (choice == "drip") {        llSensorRepeat("", "", SCRIPTED, 0, 0, 2);     

} else if (choice == "stop") { //stop water drip }

 

...

...

 

sensor(integer number_detected) {

//particle script

}

 Thanks.

---

 

You're just using the wrong event handler is all. It's no_sensor not sensor when setting up a secondary timer. Everything else is just getting your particle emitter tuned. [ETA] Oh, and look for "RootBeerDrinking Lampshade" to make certain no_sensor gets triggered all the time! :smileyvery-happy:

 

Hope that helps!

[RootBeerDrinkingLampshade]

---

LepreKhaun wrote:

---

GavotteValentine wrote:

I'm trying to create a water faucet so that it drips a group of X water particles each burst, pause for X seconds, then drip again. As far as I know it's not possible to do this with particle settings alone (_BURST_RATE and _BURST_PART_COUNT etc) because setting _BURST_PART_COUNT to say 20 will only cause all 20 particles to be stacked into 1 particle (no idea why it does this as it seems pointless to me) instead of a stream of 20 particles. So the only thing I can think of is to have _PART_COUNT set to 1 and _BURST_RATE set to 0, emit particles for say 2 seconds, then pause for 2 seconds, and loop it.

The problem is how do I achieve this? I've tried llSensorRepeat and it doesn't work at all when inside an if statement.

list MENU_CHOICES = ["HIDE","drip","stop"];//menu creator codelisten(integer channel, string name, key id, string choice)   {          if (choice == "HIDE") {        //hide     }     else if (choice == "drip") {        llSensorRepeat("", "", SCRIPTED, 0, 0, 2);     

} else if (choice == "stop") { //stop water drip }

 

...

...

 

sensor(integer number_detected) {

//particle script

}

 Thanks.

---

 

You're just using the wrong event handler is all. It's

no_sensor

 not

sensor

 when setting up a secondary timer. Everything else is just getting your particle emitter tuned. [

ETA

] Oh, and look for "

RootBeerDrinkingLampshade

" to make certain

no_sensor

gets triggered all the time! :smileyvery-happy:

 

Hope that helps!

---

Ahem.

[Rolig Loon]

This is why I always search for Bill the Pirate and I never look farther than 0.1m from my object.  Unlike RootBeerDrinkingLampshade, who is a gregarious fellow, pirates never come that close, so the servers don't have to waste much time looking for Bill.  :smileytongue::smileysurprised:

[Qie Niangao]

---

GavotteValentine wrote:

 I tried your particle script and all the particles are dripped sideways cause they're aimed at the object's root prim. Been tinkering for an hour and there doesn't seem to be a way to remove this nonsensical behaviour. The particle system is extremely limiting which is why I need the help of other functions.

---

Limiting, yeah, and I'm not surprised it didn't work for you. Just for completeness, it's not that the particles are "aimed at the root prim" per se, but rather they're emitted in the prim's local "downward" (-Z) direction (because the _BEGIN and _END angles are PI) yet they accelerate in the region downward direction, so if the emitter is rotated such that its local Z isn't aligned with the world, the particles will spray before falling, as you observe. So, yeah, if you can't re-orient the emitter so it (always) points (globally) downward, there's only so much that can be done by tweaking the emission angle (always a direction perpendicular to the prim's X axis).

Even if that were all aligned, the "drips" are at best suggestive of the effect you want because the within-burst particles are all emitted at once, and only spread out because they can travel at a range of speeds.

[Fenix Eldritch]

You might still be able to use the burst and rate settings. How about having the height of the particle elongate over time? Could ribbons help here?

[Madelaine McMasters]

I like your elongation idea, Fenix, but it would be the reverse of what you suggest, and the contraction completes long before the end of the drops journey. Particle scale changes occur linearly over the particles lifetime, so the contraction would complete at the end of the drip.

I do think each drip must be made entirely within one call to llParticleSystem. In that case the timer has only one thing to do, launch the drip.