keeping rotation while state change

[Rhiannon Arkin]

Hi

I am building myself a countdown script and it all works fine, except, that the object rotation seems to reset it's start position when the script changes to another state. 

I am using this for starting the rotation,

llTargetOmega(llRot2Left(llGetLocalRot()),-PI/10,1);

but during a state change the object still snaps to a start position and starts its rotation there instead of continuing where it left off before the state change. 

wicked

R

[Rolig Loon]

It's tempting to suggest that the obvious solution is to rewrite your script so that it doesn't involve a state change.  I don't know what the rest of the script looks like, though, so I don't know how practical that is.  Without seeing the script, it's hard to tell what else may be affecting llTargetOmega besides the state change. Some changes in prim properties may, in fact, trigger a reset.

[Innula Zenovka]

The state change on its own shouldn't have any effect.   Since llTargetOmega is a client-side visual effect (that is, llTargetOmega tells the simulator to tell people's GPUs to draw the object as spinning rather than tells the simulator actually to rotate the object), anything that changes the object's appearance is going to have the effect you describe -- does the state change involve a change in the object's size, colour, texture or transparency?

[Rhiannon Arkin]

oh interesting. 

yes i do change the color of the object in the state_entry of the new state. That can cause a reset ? hmmm...

I do change colors a few times within the first state, but that doesn't have any effect on it's rotation it seems. 

[Rhiannon Arkin]

8 hours ago, Rolig Loon said:

It's tempting to suggest that the obvious solution is to rewrite your script so that it doesn't involve a state change.  I don't know what the rest of the script looks like, though, so I don't know how practical that is.  Without seeing the script, it's hard to tell what else may be affecting llTargetOmega besides the state change. Some changes in prim properties may, in fact, trigger a reset.

I think i have to change a state, because i am triggering a timerevent within a timer event, and it works, but i'd like to think that is very inefficient because it gets triggered over and over again this way. 

[Rolig Loon]

1 hour ago, Rhiannon Arkin said:

I think i have to change a state, because i am triggering a timerevent within a timer event, and it works, but i'd like to think that is very inefficient because it gets triggered over and over again this way. 

That's one common reason why scripters decide that it's necessary to change states.  Sometimes a state change is the easiest solution, but it can create more problems than it solves.  Take a look at this overview of ways for creating multiple timers >>>

I doubt that your trouble with llTargetOmega has anything to do with changing states itself, but since you raised the issue, you might as well look at other ways the structure your code.

[Rhiannon Arkin]

Thanks Rolig

The only reason i didn't have the timer tick every second is that i only need the minutes for the most part of my countdown. A tick per second i only need at the last minute. That's where i switch to another timer.

But maybe i am wrong in my assumption that a timer tick every second uses more cpu power then a time tick every minute. not sure how it works inside. it might not matter. If it doesn't matter i'll use a timer that ticks every second but only trigger my display of the countdown every minute. 

BUT: i get the idea: avoid state change.

All my testing so far point to the state change as the moment that resets the rotation of my object. I muted everything and it still does it, on exactly that moment. 

 

 

[Rhiannon Arkin]

bang. it's so easy. 

just use llSleep instead of a timer. It seems accurate enough for counting minutes. 

integer min;
integer sec=10;
integer starttime=3; //minutes
integer counter;
float sleeptime = 60.0;
integer nowtime;
integer finishtime;

default
{

    state_entry()
    {   
            llTargetOmega(llRot2Left(llGetLocalRot()),-PI/10,1);     
            nowtime = llGetUnixTime();
        for (counter=starttime;counter>1;--counter)
            {llSleep(sleeptime);}
            finishtime=llGetUnixTime();
        llOwnerSay(((string)(finishtime-nowtime))); //just to check if it's really one minute
        llSetTimerEvent(1.0); //use timer only for seconds counter 
    }    
    timer()
    {--sec;
        llOwnerSay("second: "+((string)sec));
        if (sec==0)
            {llOwnerSay("gameover");
                llSetTimerEvent(0.0);
                llTargetOmega(ZERO_VECTOR,-PI/10,0);}  //stop it
    }
    
}

 

[Rolig Loon]

That certainly works. It's generally not a good idea to use llSleep for more than a second or two, because it really does put your script to sleep.  In your case, the script is doing absolutely nothing for a whole minute anyway, so that's a moot point.  However, if you can't trust that simply setting the timer to 60.0 seconds initially is going to work, it might be better to write something like
 

default
{
    state_entry()
    {
        llTargetOmega(llRot2Left(llGetLocalRot()), -PI/10.0,1.0);
        llResetTime();    // Reset the script's internal clock
        llSetTimerEvent(50.0);    // Run the timer once for "almost" a minute
    }

    timer()
    {
        if (llGetTime() > 49.0)   // Check to tell whether the timer interval is fast or slow ...
        {
            if (llGetTime() < 60.0)
            {
                llSetTimerEvent(1.0);    //Speed up the timer
            }
            else
            {
                llTargetOmega(ZERO_VECTOR,0.0,0.0);
                llSetTimerEvent(0.0);
            }
        }
    }
}

Personally, I wouldn't bother resetting the timer at all.  Just set it to 60.0 seconds in state_entry.  When the timer fires, stop llTargetOmega. 

Incidentally, your loop

for (counter=starttime;counter>1;--counter)
            {llSleep(sleeptime);}

might as well just be replaced by llSleep(starttime *sleeptime).  In my formulation, that means setting llSetTimerEvent(starttime * 60.0 - 10.0) and making a similar adjustment in the timer event.  But I'd still prefer just firing the timer one time with llSetTimerEvent(starttime * 60.0).

 

Edited July 15, 2017 by Rolig Loon

[Rhiannon Arkin]

so you wouldn't be concerned about firing the llSetTimerEvent within the timer ? this resets and restarts the timer every second. I haven't noticed any extra lag that comes with it when i tried it, so maybe it's ok. 

[Rolig Loon]

It's standard practice.  No lag involved.  As I said, though, I really don't see a good reason for firing the timer more than once anyway.