Particles on/off

I have an attachment which makes particles when triggered by a chat command. However. it was also emmitting the particles whenever the attachment was first rezzed, or approached or when teleporting. I stopped this by putting a blank Particle call in the state_entry. Is there a better way to make the particles appear only when commanded?

default
{
        state_entry()
        {
            //llListen(5,"",llGetOwner(),""); //only owner can change it.
            llParticleSystem([]);
            llListen(5,"","",""); //anyone can change it.
        }
        listen(integer chan, string name, key id, string msg)
        {
               
//------------------------------------------------------
//------------------------------------------------------
                if(msg=="on")
                {
                llParticleSystem([PSYS_PART_FLAGS, 0, PSYS_PART_START_ALPHA, 0.800, PSYS_PART_START_COLOR, <1.000, 1.000, 1.000>, PSYS_PART_START_SCALE, <1.200, 1.150, 0>, PSYS_SRC_BURST_RATE, 0.10, PSYS_SRC_BURST_PART_COUNT, 5, PSYS_PART_MAX_AGE, 4.000, PSYS_SRC_PATTERN, PSYS_SRC_PATTERN_ANGLE_CONE, PSYS_SRC_INNERANGLE, 0.100, PSYS_SRC_OUTERANGLE, 0.000, PSYS_SRC_BURST_SPEED_MIN, 1.000, PSYS_SRC_BURST_SPEED_MAX, 1.000, PSYS_SRC_ACCEL, <0.000, 0.001, -1.000>, PSYS_SRC_MAX_AGE, 10.0
                ]);
                }
                
                //------------------------------------------------------
                {
                //etcetera for other settings
                }

        }
}

Hi, I rarely put any code in state_entry as that is only called on compile, reset script, and believe it or not state_entry ( callng default from somewhere else )

I normally use something like this

init()
{
  do all your stuff
}

default
{
  state_entry()
  {
	init();
  }
  on_rez( integer r ) 
  {
	init();
  }
etc
etc

That way the script goes through initialisation ( init ) whenever it is rezzed as well.

( you can add init to changed for inventory changes etc etc )
( you can also add little flags to tell init where it came from - eg true state_netry , rez, changed etc so that your initialisation does other stuff for the various start types )

I quite often do something similar to Adriana, but there's nothing wrong with the state_entry call for it.

Particles are something of a special case (there are others, like looped sounds, hoverttext etc.) in that you can take the script out of the prim completely and they will persist - they're properties of the prim once established.

That's why your particles persist across reseting the script and don't set off the new particles until commanded to. The other thing you could consider is an off command as well as an on command.

No, there is no better way; the blank particle call is the only way to turn it off (unless you set the particles to completely transparent, but you have to make the 'llParticleSystem()' to do that anyway and all it is going to do is use up processing power on the client so...WHY?). You are doing exactly the right thing, except that it sounds like you want the same blank partical call when you get other events such as 'on_rez', 'changed' with CHANGED_TELEPORT, etc.

EDIT: Actually, it doesn't sound like exactly what you want, but you COULD instead/also set the lifetime of the particle source, so the particles would only be emitted for a certain period for each client. Of course, coming into range IS going to start them; this doesn't give the do-not-turn-on behavior, it gives the be-visible-for-a-while-then-stop-until-someone-asks-for-more-for-all-of-us behavior.

If you use PSYS_SRC_MAX_LIFE to make the generation of particles 'time out' after a period of time then anytime that object comes into view for someone it restarts the particles. Whether it's rezzing, crossing sim boundaries or just someone coming into range.

I typically use a combination... I'll use PSYS_SRC_MAX_LIFE to force the particles off however many seconds after they start, and then I'll have a timer function sent for some period of time slightly longer which calls llParticleSystem( [ ] ); to force the particles generation all the way off.

As already mentioned, particles are a property of a prim and will fire whenever that prim first rezzes for any given viewer.

For various reasons, putting the empty particle call ( llParticleSystem([]) ) in state_entry or on_rez() is not guaranteed to turn off the particles.

I've found the only reliable method is to reset the particle property for the prim some time after the initial call that started the particles. ie: setup a one off timer...

timer()
{
   llParticleSystem([]) ;
   llSetTimerEvent( 0.0 );
}

If you are doing short run particle effects (<30s) the best bet is to use the max age call for the particles. In fact, to be really honest, use EVERY way you can to persuade the things to turn off.

I made a steam burst that lasted about 3 seconds for someone. It took an age to get it to reliably stop - none of the methods (resetting the script, timer and max age were 100% reliable, about 90% for each). All 3 together worked reliably enough.

THere is on other thing you might like to know about "PSYS_SRC_MAX_AGE, 10.0" in your script. Granted it turns on for only 10 seconds when you say "on", but every time some one comes into visble range of the object they will also see it come on for 10 seconds while you will not. If you don't want this to happen use some simple like llSleep(10.0) after Particle then call llParticleSystem([]); after the sleep. then you won't need to have it in your state entry

or somthing like this so you don't have to wait for a sleep to end.

default
{
    state_entry()
    {
        //llListen(5,"",llGetOwner(),""); //only owner can change it.
        llListen(5,"","",""); //anyone can change it.
    }
    listen(integer chan, string name, key id, string msg)
    {
        if(msg=="on")
        {
            llParticleSystem([PSYS_PART_FLAGS, 0, PSYS_PART_START_ALPHA, 0.800, PSYS_PART_START_COLOR, <1.000, 1.000, 1.000>, PSYS_PART_START_SCALE, <1.200, 1.150, 0>, PSYS_SRC_BURST_RATE, 0.10, PSYS_SRC_BURST_PART_COUNT, 5, PSYS_PART_MAX_AGE, 4.000, PSYS_SRC_PATTERN, PSYS_SRC_PATTERN_ANGLE_CONE, PSYS_SRC_INNERANGLE, 0.100, PSYS_SRC_OUTERANGLE, 0.000, PSYS_SRC_BURST_SPEED_MIN, 1.000, PSYS_SRC_BURST_SPEED_MAX, 1.000, PSYS_SRC_ACCEL, <0.000, 0.001, -1.000>, PSYS_SRC_MAX_AGE, 10.0
            ]);
            llSetTimerEvent(10.0);
        }

    }
    timer()
    {
        llSetTimerEvent(0);
        llParticleSystem([]); 
    }
} 

I usually try to make the timer 2-3 seconds longer than the PSYS_SRC_MAX_LIFE, especially for very short lived displays otherwise the timer may try turning off the particles before they've had a chance to appear. (there can be a delay between the script starting particles, and when clients actually see them.) Of course, this may just be a superstitious practice too.

I am pretty new to scripting and this is all a bit over my head, but I am trying to use the advice offered, and I appreciate everyone who has contributed comments. In the revised script below I have tried to implement the timer. Does it look like I am doing it correctly? It seems to work in SL.

default
{
    state_entry()
    {
        llListen(69,"",llGetOwner(),""); //only owner can change it.
        //llListen(69,"","",""); //anyone can change it.
    }
    on_rez(integer rez_num)
    {
        llResetScript();
    }
    listen(integer chan, string name, key id, string msg)
    {
        if(msg=="on1")
        {
                llParticleSystem([ PSYS_PART_FLAGS, 0,
                    PSYS_PART_START_ALPHA, 1.000,                                    PSYS_PART_START_COLOR, <1.000, 1.000, 1.000>,
                    PSYS_PART_START_SCALE, <0.250, 0.100, 0>,                        PSYS_SRC_BURST_RATE, 0.300,
                    PSYS_SRC_BURST_PART_COUNT, 1,
                    PSYS_PART_MAX_AGE, 4.000, 
                    PSYS_SRC_PATTERN,
                    PSYS_SRC_PATTERN_ANGLE_CONE,
                    PSYS_SRC_INNERANGLE, 0.000,
                    PSYS_SRC_OUTERANGLE, 0.000, 
                    PSYS_SRC_BURST_SPEED_MIN, 1.000,
                    PSYS_SRC_BURST_SPEED_MAX, 1.000, 
                    PSYS_SRC_ACCEL, <0.000, 0.001, -1.000>,                          PSYS_SRC_MAX_AGE, 6.0 ]);
                llSetTimerEvent(8.0);
        }

//----------------------------------
                if(msg=="on2")
                {
                llParticleSystem([ PSYS_PART_FLAGS, 0,
                    PSYS_PART_START_ALPHA, 1.000,
                    PSYS_PART_START_COLOR, <1.000, 1.000, 0.500>,
                    PSYS_PART_START_SCALE, <0.150, 0.100, 0>,
                    PSYS_SRC_BURST_RATE, 0.0500,                                     PSYS_SRC_BURST_PART_COUNT, 1,                                    PSYS_PART_MAX_AGE, 2.000,                                        PSYS_SRC_PATTERN,                                                PSYS_SRC_PATTERN_ANGLE_CONE, 
                    PSYS_SRC_INNERANGLE, 0.000,                                      PSYS_SRC_OUTERANGLE, 0.000, 
                    PSYS_SRC_BURST_SPEED_MIN, 1.000,                                 PSYS_SRC_BURST_SPEED_MAX, 1.000, 
                    PSYS_SRC_ACCEL, <0.000, 0.001, -1.5000>,                         PSYS_SRC_MAX_AGE, 6.0 ]);
                    llSetTimerEvent(8.0);
                }
//---------------------------------
      
        if(msg=="off")
                {
                    llParticleSystem([]);
                }
                          

        }
    timer() 
    {
        llSetTimerEvent(0);
        llParticleSystem([]); 
    } 
}

Yes, that looks fine to me. The acid test is does it work of course, but there's nothing obviously wrong about the timer parts.

One little thing... not relevant atm. llSetTimerEvent(8.0); and llSetTimerEvent(0.0); actually take less memory in your compiled code believe it or not! (saves typecasting the integers to floats if I understood the conversation correctly). In a script this size it's of no importance, but as your scripts get bigger it might just help, and it's a good habit to get into now... same in vectors and rotations, <1.0, 1.0, 1.0> takes less memory than <1,1,1> for white....

Ah. I thought I would mention this one. There is one absolutely SURE way to turn off particles: delete the prim that has them turned on. Thus you might be able to get away with rezzing a temporary object that emits the particles and sets a timer to call 'llDie()' after a given period. It won't work well in some situations, like when the object is intended to be an attachment that moves with the avatar and such. But if it is a stationary object that emits particles for a while and then shuts off, this can be a great way to go!

This script seems to be working fine now. My thanks to everyone who offered advice.