Do listens and timer persit when changing state?

If I have different states in an script and set up listens or timers in each state, will they interfere with each other?

Thanks
Leon

According to the Wiki, listens are automatically removed on a state change, timers persist across state changes until a script reset.

Timers carry over into other states, but listens do not. If you want to make sure timers don't interfere with different states, put a llSetTimerEvent(0.0); (or another length if you do want a timer to start with the state) into each state's state_entry(). There is only one timer per script, so calling a new llSetTimerEvent(), even in a different state than the first call, will stop the previous timer first.

As always, thank you for such prompt an fantastic responses!!!

Leon

I've written a bare-bones script to experiment with listens & timers in different states.

It is a 3 state script; default, state1, & state2. The default state has a timer (30secs) & listen 'event'. A dialog menu can be used to switch to state2, but if this doesn't happen the timer will fire and the script will change to state1.

Neither state1 nor state2 has a listen or timer 'event'.

Now, what I found was that the transistion to state1 happens as expected. I had thought from the comments that if the script was in state2 that eventually the timer (in default) would be triggered and the state would change to state1.

This doesn't happen and sort of makes sense as there is no 'timer' in state2 to capture the timed event?!

The questions now are. Does the script timer in default still fire every 30 secs? Does it matter if you aren't timer()'ng it in the other states? Would it be better to switch the timer off when entering non default states or doesn't it matter in the least?

Thanks
Leon

Here is the code I've used (I'm using client 1.9.0 (21))

integer gMenuHandle;
integer gMenuChannel;

default
{
    on_rez(integer start_param)
    {
        llSleep(1.0);
        llResetScript();
    }
    
    state_entry()
    {
        llWhisper(0, "Entering default state.");
        llSetTouchText("Command");
        llSetTimerEvent(30.0);

    }

    timer()
    {
        llWhisper(0, "Timer fired!");
        state state1;
    }
 
    touch_start( integer iTouched )
    {
        llListenRemove(gMenuHandle);
        gMenuChannel = -260 - llFloor(llFrand(2147483000.0));
        gMenuHandle = llListen(gMenuChannel, "", NULL_KEY, "");
        llDialog(llDetectedKey(0),  "Go to", ["State2", "Help"], gMenuChannel);
    }

    listen(integer channel, string name, key id, string message)
    {
        if (message == "State2")
        {
            state state2;
        } else if (message == "Help")
        {
            llWhisper(0, "You selected help, but you can not be helped! ;-)");
        }
    }

    state_exit()
    {
        llWhisper(0, "Leaving default state.");
    }

}

state state1

{
    state_entry()
    {
        llWhisper(0, "Entering State1.");
    }    

    state_exit()
    {
        llWhisper(0, "Leaving State1");

    }

}

state state2
{
    state_entry()
    {
        llWhisper(0, "Entering State2.");
    }

    state_exit()
    {
        llWhisper(0, "Leaving State2");
    }
}

Yes, since there is no handler for a timer event in the other two states, timer events (should they occur) will not be passed to your script. As to whether it is inefficient for a script to 'leave' a timer pinging away whilst ignoring it, that will depend on the internals of LSL's runtime environment, to which we are not (officially) privy. For tidiness, though, and as good coding practice, since you explicitly requested the timer, you should explicitly switch it off when you know you don't need it any more.

Sounds eminently sensible.

So, just to check, switching a timer off is done via llSetTimerEvent(0.0)? That is the wiki answer I believe

Thanks
Leon

Yup, that will do it