Jump to content

llresetscript is resetting another script ???


You are about to reply to a thread that has been inactive for 385 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Hello:

Need a little help.

I have two scripts in a a mesh text that rotates around an object.

One script is for the rotation.

The other script is to blink the bright texture on/off.  This script has llresetscripr in it.  For some reason, the reset script in this blinker script is resetting the rotation script and causing the rotation to reset to it's starting point per the blinker script timer.

Why is it doing this as these are two totes different scripts?

If I // the llsleep & llresetscrip the blinker script does one off/on timer cycle, stops and stays on bright but the rotation script will works fine. If I activate these commands, it resets the rotation script. again

The blinker script works on its own in a test cube. 

Thank you for the help.

 

ROTATION SCRIPT

//Z axis / slow rotate clockwise/toward left
default {
    state_entry() {   // when script starts..
    llTargetOmega(<0.0,0.0,-0.03>,PI,1.0);   // do a rotation movement in z axis. Y and Z is set to 0.
    }
}

 

 

BLINKER SCRIPT


// Set here how quick the sign should blink. It blinks now every 2.0 seconds
float blinkrate = 2.0;

// Under this line there is no need to change anything


default
{
    
    state_entry()
    {
        llSetTimerEvent(blinkrate);
        llSetPrimitiveParams([PRIM_FULLBRIGHT,ALL_SIDES,TRUE ]);
        
    }
    
    timer()
    {


 llSetPrimitiveParams([PRIM_FULLBRIGHT,ALL_SIDES,FALSE ]);
     llSleep(2.0);
    llResetScript();
        
    }


}
 

 

Link to post
Share on other sites

I don't know why the other script is being reset, but resetting this script is a very inefficient way of doing things. I would suggest creating a global variable isBright, toggling it between 1 and 0, and in the timer, either set things bright or dull according to the toggle

 

// snippets only, not a full script

integer isBright;

state_entry()
{
	// just after you have set primitive params for fullBright

		isBright = 1;

}

timer()
{
	if( isBright == 1)
    {
         // set primitive params to dull
         isBright = 0;
    }
    else
    {
        // set primitive params to bright
        isBright = 1;
        // and delete that sleep(2.0), it's superfluous, the timer will activate every 2 seconds
        // and delete the resetscript as well.
    }
}

Note that there is a faster way of writing it where you invert the value of isBright and also a shorter way of writing the test line but it is probably clearer as I have suggested.

 

Note also, biggest gotcha of this class of language, the use of == inside the test value, losing one of them will result in isBright always being set to 1 :)

 

Making these changes to the script will at least solve your problem with the other script resetting with the added bonus of being more efficient.

Edited by Profaitchikenz Haiku
  • Thanks 1
Link to post
Share on other sites

This is a guess, but I'm fairly sure the reason why the spinning is "reset" is because the object's appearance is being changed.

There's no problem when the last two lines in the Blinker script are removed, because in that case llSetPrimitiveParams will just keep applying the same property... which changes nothing. But when the script is reset and fullbright changes, the spinning restarts because of the way the viewer displays the spin.

The only fix is to not use llTargetOmega.

Edited by Wulfie Reanimator
  • Thanks 1
Link to post
Share on other sites

Thank you PROFAITCHIKENZ!

That worked! Yay!

And thanks for the explanation, Wulfie.  I kind of thought that might be related to the problem because of the prim parameters being called on but still weird that it affected another script.

Really appreciate your help!

I''m leaving the full script here if anyone wants to use it or tinker with it.


// Set the blink time here.  2.0 = It blinks now every 2 seconds
float blinkrate = 2.0;

// Under this line there is no need to change anything

integer isBright;

default
{
    
    state_entry()
    {
        llSetTimerEvent(blinkrate);
        llSetPrimitiveParams([PRIM_FULLBRIGHT,ALL_SIDES,TRUE ]);
        
        isBright = 1;
        
    }
    
timer()
{
    if( isBright == 1)
    {
        llSetPrimitiveParams([PRIM_FULLBRIGHT,ALL_SIDES,FALSE ]);
         isBright = 0;
    }
    else
    {
        llSetPrimitiveParams([PRIM_FULLBRIGHT,ALL_SIDES,TRUE ]);
        isBright = 1;

    }
}

}

Edited by Pixels Sideways
correction
Link to post
Share on other sites

To be really efficient about this, I wouldn't touch PRIM_FULLBRIGHT at all but instead cel animate an emissive alpha texture. Both texture animation and llTargetOmega spin are viewer-side prim properties, so once the properties are set the script(s) can be removed and the effect persists.

Of course, folks who still haven't turned on Advanced Lighting Model won't see the emissive effect at all, but I consider that a feature, cuz after all, screw 'em. 😋

  • Like 1
Link to post
Share on other sites
12 hours ago, Pixels Sideways said:

The other script is to blink the bright texture on/off.  This script has llresetscripr in it.  For some reason, the reset script in this blinker script is resetting the rotation script and causing the rotation to reset to it's starting point per the blinker script timer.

As Wulfie says, the reason the rotation is resetting is that you're using llTargetOmega to rotate the object.

llTargetOmega is client-side, which means when you call it, the simulator sends a message to your CPU and GPU telling them to draw the object as if it's rotating smoothly until further notice.      

When you blink the light on and off, that sends a new message to your computer, telling it to redraw the object with the light at the new setting, along with all the other object properties the simulator has stored, including the object's rotation.   

It also over-writes the llTargetOmega call, so the object stops moving unless you explicitly tell it to keep on rotating by calling llTargetOmega again.

If anyone ever needs to do this, and wants to avoid having the object flip back to the starting rotation each time llTargetOmega gets turned off, you need to keep on periodically updating the object's actual rotation on a timer each time the omega changes by 10 or 15 degrees or so, to ensure the object stays visually more or less in synch..

Link to post
Share on other sites

llTargetOmega sets rotation, and that's supposed to be persistent, but it isn't reliably persistent. You can't start up a fan or a windmill and expect it to run forever, over sim restarts, logouts, edits, unrelated changes, etc. It's good for vehicle wheel rotation, where the speed gets changed now and then via occasional llTargetOmega calls.

Since this is viewer-side, it's possible for different viewers to be seeing it in different positions, or not rotating.

Link to post
Share on other sites
21 hours ago, Wulfie Reanimator said:

This is a guess, but I'm fairly sure the reason why the spinning is "reset" is because the object's appearance is being changed.

Good point, that escaped me entirely when I first read the post.

Thinking about this, omegas also stop when you grab an object to inspect it, don't they? There might be a wider range of things that freeze updates on the client.

  • Like 1
Link to post
Share on other sites
12 hours ago, Profaitchikenz Haiku said:

Good point, that escaped me entirely when I first read the post.

Thinking about this, omegas also stop when you grab an object to inspect it, don't they? There might be a wider range of things that freeze updates on the client.

That's why, if you want to snap an object back to the original visual rotation when you stop llTargetOmega, you need to do something that forces the viewer to re-redraw the screen -- Calling llSetText with the opacity set to 0.0 and then clearing it will do the trick.   So does switching the colour of a hidden face.

  • Thanks 1
Link to post
Share on other sites
You are about to reply to a thread that has been inactive for 385 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...