Timer/particle confusion

Can anyone think of why this script won't turn off after the 3 seconds, or rather will do so sometimes but not always? I've chopped out the updateParticles() function - not relevant and it works nicely. It's the turning off that's intermittent.

default
{
    state_entry()
    {
        llParticleSystem([]);
    }
    link_message(integer sender, integer num, string message, key id)
    {
        if(message =="Steam")
        {
            llSetTimerEvent(3.0);
            updateParticles();
        }
    }
    timer()
    {
        llParticleSystem([]);
        llSetTimerEvent(0.0);
    }
}

What does the script look like that's sending the link-message to that grouping of code?

here's something that should work

***the transmitter***

default
{
    state_entry()
    {
        // listen on channel zero for any chat spoken by the object owner.
        llListen(0,"",llGetOwner(),"");
    }
    
    listen(integer channel, string name, key id, string message)
    {
        // check if the message corresponds to a predefined string.
        // llToLower converts the message to lowercase.
        // This way, "HELLO", "Hello" or "HeLLo" will all work the same way.
        // Now if there was only a llToL33t so that H3ll0 goes to Hello we'd be grooving
        if (llToLower(message) == "on")
        {
            // if the message from the owner is "on", send out the value 1 to the child prims.
            llMessageLinked( LINK_ALL_OTHERS, 1, "", NULL_KEY );
        }
       
       llSleep(10); //waits 10 seconds before executing the next line
            llMessageLinked( LINK_ALL_OTHERS, 0, "", NULL_KEY ) ; //Sends out the value 1 to the child prims
    
    }
}

***This is the particle "Switch" that goes with the particle engine***

default
{
    state_entry()
    {
    }
        link_message( integer sender, integer num, string message, key id )
    {
        if( num == 0 ) //turns off the particle system when the number 0 is transmitted
        {
            running=TRUE;
        llSetText(" ", <0.0, 1.0, 0.0>, 0.5);
        llParticleSystem([]); //Stop Particle effect
        }
        
        else //Turns the particle system on when any other number is transmitted
        {
            running=FALSE;
        llSetText(" ", <0.0, 1.0, 0.0>, 0.5);
         ParticleFallsEffect(); //Start particle effect
       }
    
    }
}

if it's a prim starting the effect, you can have it transmit a string on some channel (in a different script) other than 0 and have the transmitter effect thingy listen for that string rather than the owner saying a command.

Kenn, the link message is one of several (there are options for other effects). Basically it's a touch script that pops up a dialog box with the options and passes them around the object overall so the right bits respond to the right messages. No timer, no repeat sending of the message etc.

That part works fine, and timers attached to other things than particle systems seem to work fine too.

The thing that confuses me is that the failure is intermittent. I have two steam producing prims using identical scripts. They both turn on perfectly well. Sometimes both will turn off, sometimes one, sometimes none. It strikes me it's an intermittent failure in updating the particle system to the new settings, but I've never heard of that before, which is why I was asking if anyone can see anything else that might be going wrong.

Since posting yesterday I've also noticed that recomiling the script doesn't always stop the particles if they're being incorrectly produced - more evidence to my mind that turning the particles off isn't working quite right.

I encountered that exact same problem when adding a particle effect to one of my hovercrafts: even though the on/off command was being sent properly (verified through some debugging code), every now and then 1 or 2 of the 4 hoverjets wouldn't turn on or off (always random which one and wether the on or the off was bjorked). strangely enough the problem went away on it's own. Look at posts 4 and 5 here.

Eloise, your code looks great, and the fact that the default start_entry isn't always working either seems strange - just to confirm, try dropping an llOwnerSay into the timer event. If you see that and the particles continue, I would have to say either a bug or you're having some network related issues. How's you packet loss?

EDIT: or what Senuka said

It's the particle system not updating, tested again, with the llOwnerSay() in place. All of the prims receive the link message and fire as expected. All enter the timer event as expected, about 30% of the time the particle systems don't turn off (that's 3/10 that I tried today, yesterday it was closer to 50%, but you can't tell for sure, the numbers of tests are so small).

I've bug reported it, along with the script.

aww... I'm afraid I'm misreading you but.. Why don't you use "PSYS_SRC_MAX_AGE, 3.0"?
I don't think it is efficient to stop llParticleSystem itself like llSetText.

I'll give it a go, but it becomes a balance, is it more efficient to turn a source on and off entirely (if it works) or turn it off that way and then reset the script. I tend to the former by intuition rather than any hard data.

I second Seagel's proposition

I think the original problem may be caused by race conditions / unexpected delays between the two particle updates sent to your client. You might get different results on two different computers, maybe re-test the thing with another person watching and see if (s)he sees anythign different ?

The race condition thing is an excellent suggestion. You can test for that problem easily by keeping a global shared counter and printing and incrementing it in each of your event handlers (along with a message to tell which handler you are in). If you find the counter incrementing out of the order you expect, it's because of race conditions.

I went in earlier today my time (last night SL time) and amended some of the scripts as per Seagel's suggestion. To my surprise and intense annoyance those scripts and the ones with the llParticleSystem([]); line worked reliably and well over 50 times on the trot.

However I've taken the precaution of changing them all to the max life approach, one to remember for the future. So, my next question is, does anyone know how much of a hit it puts on the sim's resources to reset a script?

A particle update is, AFAIR, a full object update, so it's like loading the object again from the asset server / sim asset cache (or just the prim which has the particlels, hopefully).