Timers Events Loops I'm a little lost.

I think I've read too much about all the ways to do this - and how not to do this - and I've gone and confused myself. Here's what I want the script to feature:

Start with a simple state
That state responds to timed changes that leads to other states sequentially
Timed changes can be altered/interrupted by user action

The concept I've got going as logic (not necessarily as scriptability) runs like this:

Define states 1,2,3, and 4
Automate these states so that: 1 -> 2 -> 3 -> 4
Listen on a channel for user interaction at each state
If a user interacts at state 3, for example, revert to state 1 or 2
Following that interaction start this 'flowing' process again from where it was reverted to.


Where I'm lost is at how to structure this efficiently, and what kind of loops I should be using (for while else... huh?).

If anyone can point me in the right direction it would be really really appreciated.

I'm not sure you need any loops if I understand this properly.

Again in block pseudo code I think:

state 1
timer to move to state two
listen to move back to state 4

state 2
timer to move to state three
listen to move back to state 1

etc. should do the trick?

So, each state will have, in it's state_entry() event, an llSetTimer() call and an llListen(). It will have a timer event to move on, and a listen event to move back. No need for loops in there, but maybe I haven't understood the question?

omg that makes SO much sense! i can't believe i didn't work that out earlier.
that's definitely a LOT simpler than i was thinking i needed to do.

just one question...

when changing to a different state due to the listen function... what happens with the timer? will that still continue to count, or will it cancel out automatically upon the script changing states?

Timers, contrary to expectation, and unlike everything else, persist across state changes, but only fire usefully in the next state if there is a timer event of course.

If you want the timing to be continuous you can save a line or two of code this way. If you need the times in the different states to be different the absolutely safest way is to set the timer to 0 and then set it to the new time. (This turns it off and then on again with a new time.) If you're not using short timers I have to say I've never noticed a problem with just directly setting the new time (not setting to 0 first), but it's worth noting there can be problems with it.

cool.
i'll try and work something out.

and thanks HEAPS for clearing that up for me. i'll drop something cool in your inventory next time i'm on SL

Easiest way to reset the timers would be to have a state_exit() in each state, put the command llSetTimerEvent(0.0) in there and you will stop the timer upon leaving the state.
Then in each state have a state_entry() containing llSetTimerEvent(30.0) or whatever time you want to use.

This is good practise to be sure, however, if you have an llSetTimerEvent(30.0) in each state_entry(), it will over-ride any existing timer value, so you can get away without it, technically. e.g: if you are in state 2, and have 10 seconds left, you interrupt and go back to state 3 which sets the timer to 30 seconds, nothing will happen for 30 seconds.