Quick question...

Does the timer state keep running even if the script directs to another state?

Example...

{code}

timer()
{
if (on == TRUE)
{
for (x = 0.2; x < y; x+=0.1)
{
llSetPrimitiveParams([PRIM_GLOW, ALL_SIDES, x]);
llSleep(t);
}
on = FALSE;
state tail;
}

{/code}

So I want the timer() state to keep running while the 'tail' state starts... will this happen?

Cheers

Timers survive state changes but not resets, a timer() event handler in the new state should receive the event fired by a timer started in the old state.

Basically you can write...

default
{
state_entry()
{ 
state new_state;
}

state_exit()
{
llSetTimerEvent(3.0);
}
}

state new_state
{
timer()
{
//handle timer event from state default
}
}

The timer() is an event handler, not a state. The event queue is cleared
by a state change and the timer() event handler will exit at the line
'state tail;' so no , your timer() event handler will exit when the tail
state is called.

However, given the timer() event handler you have in your code, it
WILL execute the for loop fully and then set on=FALSE and then go
to the tail state. Any timers that fire while in the tail state, even if
started in the default state, will need to be handled by a timer()
event handler in the tail state.

Basically you can write...

default
{
    state entry()
    {        
        state new_state;
    }

    state_exit()
    {
        llSetTimerEvent(3.0);
    }
}

state new_state
{
    timer()
    {
        //handle timer event from state default
    }
}

The timer() is an event handler, not a state. The event queue is cleared by a state
change and the timer() event handler will exit at the line 'state tail;' so no , your
timer() event handler will exit when the tail state is called.

However, given the timer() event handler you have in your code, it WILL execute
the for loop fully and then set on=FALSE and then go to the tail state. Any timers
that fire while in the tail state, even if started in the default state, will need to be
handled by a timer() event handler in the tail state.

Thanks jeredin

Another question then... can a script run multiple things at once? Basically my goal is to have the timer event make an object pulse continuously while something else happens.

{code}

// Data for heartbeat

integer on = TRUE;
float x = 0;
float y = 0.8; // The glows maximum value
float t = 0.05; // Controls speed of the pulse

// End of data for heartbeat


// Data for tail

float a = 0;
float b = 0;
float c = 0; // these are here for show really

// End of data for tail.



default
{

state_entry()
{
llSetTimerEvent(0.2);
}

timer()
{
if (on == TRUE)
{
for (x = 0; x < y; x+=0.1)
{
llSetPrimitiveParams([PRIM_GLOW, ALL_SIDES, x]);
llSleep(t);
}
on = FALSE;
state tail;
}
}

state tail
{
state_entry()
{
llSetTimerEvent(0.2);
// If I implemented more code in here, would this run while timer event ran
// or does the code run from the top down?
}

timer()
{
if (on == FALSE)
{

for (x = y; x >0.0; x-=0.1)
{
llSetPrimitiveParams([PRIM_GLOW, ALL_SIDES, x]);
llSleep(t);
}
on = TRUE;
}



}

{/code}


I've put in a little comment on the state tail - state_entry... maybe someone can help me out :/

My problem is... I want a bit of code to execute when the glow reaches a certain value. Will I have to make another script and set this script to execute it?

If that is the case, does that mean it is better to have all of this as one object with different scripts in them or is it possible for script to execute another objects script.

Thanks

Hmmm is having them all as one object and using llMessageLinked the key here?

In the lsl portal it says that llMessageLinked communicates with other scripts in the object... does that mean it is possible to execute the other scripts in the object though?

Here's what happens...

* The code placed in state_entry after llSetTimerEvent(.2); would execute first. The timer event would wait to trigger until after the code in state_entry is finished running.

* In the timer event, if code within the timer event takes longer than the next timer event trigger, the code is executed first and the timer event triggers after the code is finished running.

So, in both cases code that needs to be run is done first before a timer event is triggered. If it's not too intensive, you may be able to combine the code you need to run with the timer event to achieve your desired result. It may be necessary to put it in a separate script and send that script messages to trigger the code whenever you need it. The only way to get two things happening at once is to have two scripts running.

Yes, basically you'd write two separate scripts. The master script
would send a linked message using llMessageLinked with a linknum
of LINK_THIS restricting the message to the same prim. The child
script would implement a link_message() event handler to handle
the linked message and then perform the code you want to run
concurrently.

// in master script somewhere
// see llMessageLinked documentation
llMessageLinked( LINK_THIS, 100, "", "" );
// end master script code

// in child script
default
{
    link_message( integer sender_num, integer num, string str, key id )
    {
        // test to see if message num is the one we want to respond to
         if (num==100)
        {
            // handle linked message here
        }   
    }
}
// end child script code

I didn't use anything in the 3rd parameter of llMessageLinked
because this is a single message the scripts will use. If you had multiple
possible messages, you'd want to vary the num and/or str params of
llMessageLinked and respond accordingly. Basically if the num==100, it's
our message, no need for a string param. The 100 is arbitrarily chosen.
When sending messages to the same prim, be aware that an infinite loop
can be created quite easily, so take care in your use.