Why Reset?

I've searched everywhere to find out why the Reset button exists. I can't find any answers.

The nearest I can guess is that the Save button evidently does not in some cases recompile and execute certain lines of code. In other words, a function such as llGetPos() apparently fetches an object's coordinates the first time the script executes, then does not fetch them during any subsequent recompilation/execution.

For some reason the object seems to save these coordinates as data rather than getting them afresh each time the script executes. So if you move this object, you need to click Reset to force llGetPos() to execute and store the new position data.

Am I on the right track? And if so, what other functions don't execute more than once without a forced Reset? And, finally, why this strange behavior? Why are scripts not exectuted in their entirety each time, as other languages do?

Thank you.

The biggest reason for me to use the Reset button? StackHeapCollision Which is when the script crashes due to having run out of memory.

Other than that it can be helpful just to reset the script to a default state without recompiling it, which resets all variables and all states. Even if you do not have modify permissions on a script you can still use the Reset button.

Saving a new version of a script will recompile and then reset the script, always doing the same thing as clicking the reset button. I've never seen anything like what you've described here, and I can say for sure that LSL doesn't work like that. It might help if you show us your code that's behaving oddly with saves and resets... it might just be a difficult-to-spot bug.

It's useful for when you've got a script that interacts with the world and/or users and want to test different startup scenarios.

As a cheesy example, I've got an object that contains a script and another object. When the parent object gets dropped in-world, it rezzes the contained object at a position & rotation based on the position & rotation of the parent. Having a reset button makes it pretty easy to test that my rez math is kosher.

Any time you don't need to change the script but want it to start running 'fresh' again, it's a useful button to have.

Here's my code. It moves a prim over 7 meters, then back. I use it to open a trap door temporarily. However, if I duplicate the trap door to use in a different location, the coordinates for the start postion are not correct for the new location. The duplicated prim seems to "remember" the original start position, unless I click the Reset button.

???

Thanks for any help with this. I really don't know when to use Reset and when not to. I'm assuming that rotation and size "gets" are also likely to persist until Reset is clicked.

integer seconds;
vector startLocation;

default
{
    state_entry()
    {
// find vector for the original location
                startLocation = llGetPos();
    }

    touch_start(integer total_number) //when the floor is clicked
    {

        // create a vector that moves the trap door horizontally
        vector offset = < 7, 0, 0 >;  
        vector newPosition = startLocation - offset;
        llSetPos( newPosition );   // move the trap door.


        llSetTimerEvent( 1 );  // trigger timer once a second
    }

    timer()  // This happens each trigger

    {
        seconds++;

        
        if ( seconds > 10 )  // close the trap door after this interval of seconds
        {    

                llSetPos( startLocation );

            llResetScript();  // return this script to its original state.
        }
    }
}
[\php]

Yep. Try adding this...

on_rez (integer param)
{
     llResetScript();
}

Also, I'd probably put a second or so of llSleep after the llSetPos and before the llResetScript in your timer handler. Dunno if that's needed, though.

Lauranne, please enclose your code in tags like this:

[php ]
my code
[\php]

(omitting the space before the close bracket). That way we can read the code.

Many script errors will cause the script to hang, and a reset is required. Coding bugs can easily get a script into a state where it stops working correctly, and a reset is a temporary workaround (but note that if you deliver the script without full priviliges, the next person won't be able to reset it).

To my knowledge, scripts don't execute a function once and cache the results. On the other hand, the sim may cache info, and the cache can get out of date and "dirty" and due to SL bugs the server may not find out about it. But this should be a rare circumstance and not repeatable.

Meade has the answer. When you duplicate an object, its script does not get reset -- it gets identical state information (the script's state plus all global variables, plus object attributes such as particles, sit position, and floating text.)

Remove the call to llSetPos() in the timer event, because with the on_rez handler it becomes superflous.

The on_rez() causes it to reset whenever it gets instantiated, such as by being pulled out of your inventory or shift-dragged to copy. (Note that shift-drag to copy does not duplicate particle effects, sit positions, floating text, and other object attributes.)

BTW, rather than hit the timer 10 times, just set the timeout for 10 seconds, and avoid contributing unnecessarily to lag.

Thanks but I think it's still not quite right. If the object is moved after it's dropped (does anybody ever drop things to the right spot??), the position will be off.

Maybe something sorta like this, instead...

float DELAY = 10.0;
vector startLocation;

default
{
    touch_start(integer total_number) //when the floor is clicked
    {
        startLocation = llGetPos();

        // create a vector that moves the trap door horizontally
        vector offset = <7.0, 0.0, 0.0>; 
        vector newPosition = startLocation - offset;

        llSetPos (newPosition); // move the trap door.
        llSetTimerEvent (DELAY); // trigger timer once a second
    }

    timer() // This happens each trigger
    {
        llSetPos (startLocation);
        llSleep (2.0);
        llResetScript(); // return this script to its original state.
    }
}

When you use the Shift-drag method to create a duplicate of an object, the duplicate is the one you MOVED. The new object is the one LEFT BEHIND. Its bass ackwards I know, but from my experience is true. This means that even an on_rez event will not fix your problem, since it was already rezzed.

Use Meade's code, it looks good to me =)

Good point, Meade. And excellent observation, Milambus!

Why the reset in the timer handler? Seems unnecessary, along with the delay.

BTW, I'd use a second state or some other debounce method to avoid the touch_entry() handler being called multiple times for one click. I see this a lot -- I assume it's an LL bug but perhaps it's a bug with my mouse. It only happens with my wireless mouse; the other one is fine. I don't see any mouse issues with any other programs, though.

Also, I've seen other players have the same trouble. What a pain to always have to script debounce into a touch event! (The symptom of mouse click bounce in this case is that after many uses the trap door would drift in the negative X direction.)

Here's what I would suggest:

float DELAY = 10.0;                    // how long to leave door open
vector OFFSET = <7.0, 0.0, 0.0>;   // where to move door (relatively)

vector startLocation; 

default
{ 
    touch_start(integer total_number) //when the floor is clicked 
    {
        state open;
    }
}

state Open
{
    state_entry()
    {
        startLocation = llGetPos(); 

        // move the trap door & start timer to close it
        llSetPos (startLocation - OFFSET); 
        llSetTimerEvent (DELAY); 
    } 

    timer() // time to close the door 
    {
        llSetPos (startLocation);
        llSetTimerEvent(0.0);
        state default;
    } 
} 

You might also want to add a llSetTimerEvent (0); to the timer event to stop the timer from firing again, so as to reduce unnecessary lag, perhaps ameliorated by not having a timer event in the default state.

timer () is not terminated by state changes.

Right Ed! I've updated my post above. Thanks.