how to loop a script

Hello, I was wanting to make a dance light. When I give the command, I was wanting to have it loop through the light colors but I have no idea how that is done. I saw nothing that I could insert in the script that would do this.
I was silly, I tried llResetScript () in the start but it did what I thought it would do.
Can anybody offer any help for looping?
Thank you

start()
{
    llSetPrimitiveParams([PRIM_POINT_LIGHT, TRUE, <1,1,1>, 1.0, 20.0, 0.00]);
    llSetPrimitiveParams([PRIM_POINT_LIGHT, TRUE, <1,0,0>, 1.0, 20.0, 0.00]); 
    llSetPrimitiveParams([PRIM_POINT_LIGHT, TRUE, <0,1,0>, 1.0, 20.0, 0.00]); 
    llSetPrimitiveParams([PRIM_POINT_LIGHT, TRUE, <0,1,1>, 1.0, 20.0, 0.00]); 
    llSetPrimitiveParams([PRIM_POINT_LIGHT, TRUE, <0,0,1>, 1.0, 20.0, 0.00]); 
    llSetPrimitiveParams([PRIM_POINT_LIGHT, TRUE, <1,0,1>, 1.0, 20.0, 0.00]); 
}
stop()
{
    llSetPrimitiveParams([PRIM_POINT_LIGHT, FALSE, <0.5,0,0.25>, 1.0, 20.0, 0.00]);
}


        default
{
    state_entry()
    {
        key id = llGetOwner(); 
        llListen(999,"",id,""); 
    }
    
    listen(integer channel,string name,key id,string message) 
    {
        if (message == "start")
            start();
            llResetScript ();
            
        if (message == "stop")
            stop();
        
    }
    changed(integer change)
    {
        if (change & 128)
        {
            llResetScript();
        }
  } 
}

One solution would be to set a timer event. Every time the timer is called it increments a variable and changes the lights according to this variable - a bit of cycle logic would be needed to keep within the range.

Not able to test from here so only fragments:

define the colours as a list

list colours[<1,0,0>,<0,1,0>,<0,0,1>,<1,1,1>,<0,0,0>];
vector currentcolour;

and your colour "pointer":

integer pointer=0;

then set a timer event - like every quarter second:

llSetTimerEvent(0.25);

the timer itself should look like this:

timer() {
   pointer=pointer+1;
   if (pointer >= llGetListLength(colours)) {
      pointer=0;
   }
   currentcolour=llList2Vector(colours,pointer);
   //
   // and now set the faces with currentcolour
   ///
}

Since I assume you want rapidly changing lights you need a fast timer and since this puts some load on the server I'd recommend adding either a menu or a touch event to start and stop this thing.

Alternately you can switch between states with llSleep delays and use a change state event in each and every state_entry command - should work as well - without a timer. No guarantee, though - test needed.

My recommendation would be to create a second state which refers back to the default state.

quick example:

default

(do a buncha shit)
(state two

state two
{
(state default


Basically when you would want to loop is when you'd jump to state two, which in turns bounces to state default. This will cause state_entry to be run in the default w/o resetting script and this way you holdd any varibles etc.

timers work great as mentioned above, depending on what they are being used for.

I went with states, seemed the best way for what i was doing. Now I have another problem with it. It won't turn off. I've asked a few people in the world and they said that they didn't know what was stopping it from turning off.
One person said that I should put a wait in the repeats. but that didn't work. It starts up just fine now, and loops perfect. Just can't turn it off without reseting the script.

start()
{
        llSetPrimitiveParams([PRIM_POINT_LIGHT, TRUE, <1,1,1>, 1.0, 20.0, 0.00]);
        llSetPrimitiveParams([PRIM_POINT_LIGHT, TRUE, <1,0,0>, 1.0, 20.0, 0.00]); 
        llSetPrimitiveParams([PRIM_POINT_LIGHT, TRUE, <1,1,0.0>, 1.0, 20.0, 0.00]);
        llSetPrimitiveParams([PRIM_POINT_LIGHT, TRUE, <0,1,0>, 1.0, 20.0, 0.00]); 
        llSetPrimitiveParams([PRIM_POINT_LIGHT, TRUE, <0,1,1>, 1.0, 20.0, 0.00]); 
        llSetPrimitiveParams([PRIM_POINT_LIGHT, TRUE, <0,0,1>, 1.0, 20.0, 0.00]); 
        llSetPrimitiveParams([PRIM_POINT_LIGHT, TRUE, <1,0,1>, 1.0, 20.0, 0.00]); 
}
stop()
{
    llSetPrimitiveParams([PRIM_POINT_LIGHT, FALSE, <0.5,0,0.25>, 1.0, 20.0, 0.00]);
}
default
{
    state_entry()
    {
        stop();
        key id = llGetOwner(); 
        llListen(4,"",id,"");
        
    }
listen(integer channel,string name,key id,string message) 
{
    if (message == "start")
    {
        state repeate;
    }
    if (message == "stop")
    {
        state off;
    }
}
  } 
state repeate
{
    state_entry()
    {
        start();
        state repeate2;
        llSleep (0.25);
    }
}
state repeate2
{
    state_entry()
    {
        state repeate;
        llSleep (0.25);
    }
}
state off
{
    state_entry()
    {
        stop();
    }
}

Don't do this. Go the timer route. Your problem here is you can't stop it because you go into a state where you aren't listening for the stop. Stay in one state and use llSetTimerEvent() to fire an event every x seconds, and cycle the colors.

Speaking of, I have never found a good use for states. They seem like a waste. You can handle things in a more controlled and predictable manner just doing smart programming. Anyone have any examples of where using states is really helpful and clean where managing state yourself would be messy or poor?

Bane Darrow

Preface: I'm a beginner hack coder

I use states for a dialogue menu, where clicking a button gives you a different menu.

For example you have 2 buttons foo and bar, hit foo and you go to state 'foo', hit bar and you go to state 'bar'. Inside these states are a few items as well as the ability to change the colour of the associated attachment. If you click the ChangeFooColour or ChangeBarColour button, they both send you to another state namely the state of 'colour' and pass a value to that state on which channel to talk on. This way I only had to have the commands for colour changing once. It is easier to me at least, instead of having a million if statements.

I use this for a menu that now has a bunch of embedded menus (states), many of which I can reuse like 'colour' by passing common variables to them. Clicking the home button on any menu takes you back to the default state which gives you the starting menu again.

Hi - the problem is that listeners are not kept when you switch states, entering a new state turns off all listeners created in the previous state. So - in order for this to work you'd need a listener in each and every state you use.

I think you probably do use states. You just call them global variables.

No other language I can think of has parallel state machines as a built in primitive. Makes things seem a little odd for people from other environments. But saying they are a waste is like saying that if-then-else statements are a waste. (Old-time FORTRAN programmers used to say that all the time .