Touch and Listen

I have a problem that I don't seem to be able to solve.

I'm writing a script that calls out a touch() and a listen().

Under the touch(), if certain integers are set, llPlaySound (9secs) and a particle fuction (ParticleStart()) are called. Depending on the integer set, a 'llSetTimerEvent() is added to to the particle function. I have the llSetTimerEvent set for 2 different times:

touch_start(integer num_detected)
{
    if (running==TRUE)
        {
            running=FALSE;
            llPlaySound("C1a", vol);
            
            {
                if(sustain == TRUE)
                {
                    llMessageLinked( LINK_ALL_OTHERS, 1, "Loopr", llGetKey() );
                    {
                        {if (off == TRUE)
                        ParticleStart();}
                        {if(always == FALSE)
                        llSetTimerEvent(30);}
                    }
                }
                
               else if(sustain == FALSE) 
                {
                    {
                        {if (off == TRUE)
                        ParticleStart();}
                        {if (always == FALSE)
                        llSetTimerEvent(9);}
                    }
                }
            }
        }
        else
        {
            running=TRUE;
            llPlaySound("C1a", vol);
            
            {
                if(sustain == TRUE)
                {
                    llMessageLinked( LINK_ALL_OTHERS, 1, "Loopr", llGetKey() );
                   {
                       {if (off == TRUE)
                        ParticleStart();}
                        {if(always == FALSE)
                        llSetTimerEvent(30);}
                }
                }
                
                else if(sustain == FALSE)
                {
                    {
                        {if (off == TRUE)
                        ParticleStart();}
                        {if(always == FALSE)
                        llSetTimerEvent(9);}
                    }
                }
            }
 
        }
    }

Under the listen(), with a chat command, I call out my ParticleStart() with no llSetTimerEvent (and with the correct integers set) to let the particles emit indefinitely until I give it a chat command to stop.

All is fine and dandy until I change the integer states and let the path go into one of the llSetTimerEvents under touch().

Once a llSetTimerEvent has been called (under touch()), it seems that the script (or prim - I'm lost at this point) is stuck using that exact call and adds it to the next time I call ParticleStart() by itself with a chat command.

I have to reset the script to clear "something" that is causing the last llSetTimerEvent to add itself to my function call.

Any and all help will be greatly appreciated trying to figure this out. Thanx

The timer() is a call for llParticleSystem([])

set timer event is a cycling call, and basically means 'run the code in timer in X seconds, and every X seconds after that'

that means 3 things
1) the timer won't trigger untill X seconds affter the call
2) the timer will continue to trigger ever X seconds after that untill stopped
3) if a new set timer event call happens it erases the old one, this includes delay till the next trigger.

the sequence for set timer event is
delay, trigger, delay, trigger, etc...

if you called llSetTimerEvent( 30.0 ) it takes 30 seconds for it to fire the first time
if you never call SetTimerEvent( 0.0 ) after starting a timer, it never stops repeating.
if you called llSetTimerEvent( 30.0 ) every 20seconds, the timer code would never fire.

Thanx Void! That esplanes a few "other" things.

I always thought that it was just a one-time call. Never thought of having to script in an additional llSetTimerEvent(0). Back to the "editor"... lol Thanx

I have not studied your script, but your use of running and sustain make me wonder if this script might have been a good candidate for multiple states.

OF COURSE, and program that has multiple states can also be implemented using global variables to represent the state, but sometimes states are more flexicle and easier to maintain in the long run (and sometimes not, of course).