Timing?

So I need some help with the timer function please.

I'd like to be able to do the following

Set texture 1
wait 4.03 secs
set texture 2
wait 4.03 secs
loop


I have tried various ways using the llSetTimerEvent with timer,
doing 4.03 and then a 8.06.
But obviously, that got me nowhere.

Is there a way to do this?

Hoping for help.
Brota Kornfeld

You can do something like this.

list myTextures = [
        "a9a32bf2-7085-98f2-ab25-ac5c6854bd19",   // library zebra skin
        "e98661c3-8c05-30c5-06ad-897e933b4c45"    // library tie die
    ];
integer textureTurn = 0;

default
{
    state_entry() {
        llSetTimerEvent(4.03);
    }
    
    timer() {
        llSetTexture(llList2String(myTextures, textureTurn), ALL_SIDES);
        textureTurn = 1 - textureTurn;
    }

}

(should mention, if these are your own uploaded textures, that LlSetTextureAnim would be a nice alternative.)

Please note that with timers and llSleep() the only thing you can take for granted is that at *least* the desired amount of time passes. It all depends on how busy the sim is.

Like this:

default
{
    state_entry()
    {
        llSetTexture( "one", 0);
        llSetTimerEvent(4.03);
    }
    timer()
    {
        state second;
    }
}

second
{
    state_entry()
    {
        llSetTexture( "two", 0);
    }
    timer()
    {
        state default;
    }
}

??

Thanks for the response, but the problem is,
I already have a llSetTextureAnim running,
and want it to change the texture being animated after 4.03 secs.

Is that possible to do?

Thanks in advance

Brota Kornfeld

That looks like it would work

*log's in to check it out*

Okay, so.
I tried Dora Gustafson's method, and I could not get it to work
Viktoria Dovgal's method updated okay, but as Squirrel Wood said
I think the problem is with the timer function, sadly.

I would like some in-game help if anyone has the time to spare?
Please send an IM if you do, your help would be much appriciated
(and paid at a reasonable price).

Brota Kornfeld

edit*
Added a state infront of "second" from Dora's method, and it changes.
But timing is awful with both.

Yuck. If you can't let dilation accumulate, I think you'll have to poll llGetGMTClock() and compare against a marker that you increment by your 4.03, and remember that at midnight you're going to drop back to 0. The polling will be less awful if you still insert a shorter sleep between polls and can accept that some updates will be late, but at least you'll lose the drift.

Ok, that sounds like it would give a more accurate swich, though it sounds too hard for me to do myself, I'll have to hire someone to do it, but thanks alot for answering.
If you are interested, please let me know, IG or here.

Thanks again
Brota Kornfeld

While still not exact, you can get a decent approximation that takes time dilation into account with llSetTimerEvent(llGetRegionTimeDilation()*PERIOD). Note that you'll want to re-evaluate this each timer event in case time dilation changes.

EDIT: You'll also want to set the timer event at the BEGINNING of your timer event handler, so that it doesn't set the next event out your calculated period AFTER the script delay of llSetTexture(). So basically:

float PERIOD = 4.03;
default
{
    state_entry()
    {
        llSetTimerEvent(llGetRegionTimeDilation()*PERIOD);
    }

    timer()
    {
        llSetTimerEvent(llGetRegionTimeDilation()*PERIOD);
        llSetTexture(...);
    }
}

There is no timer set in the second state though, so it may not work. I'm not sure if timers work across states but I doubt it.

Only thing I noticed.

Yes, timers persist across state changes. In fact it is good practice to always put llSetTimerEvent(0.0) in a 'state_exit' handler for any state where you use a timer unless you are purposefully designing your script to make use of them across states and consider carefully how state changes and your timers will intermix.

Alrighty cool, thanks for explaining ^_^