My prim runs away - why?

When I drop the following script into a physical prim, save and compile it, and then touch it, it behaves as expected.

However, when I save it in inventory and rez it later, it often takes off before I have a chance to touch it and I never see it again. Some time later, it will be returned to my lost and found folder.

Can someone please tell me why? What am I doing wrong?

Thanks in advance.


//Illustrates for loop. Each time the object is touched,
// it moves four times, sleeping 2 seconds between each
// move.
//Note: The object must be physical.

//Global variables
vector initialPosition = <0.0,0.0,0.0>;

default{
state_entry(){
llOwnerSay("Hello, Avatar!";
//Initialization
initialPosition = llGetPos();
llOwnerSay((string)initialPosition);
llOwnerSay("Initialized";
}//end state_entry

touch_start(integer total_number){
vector target;
integer cnt;
for(cnt = 0;cnt < 4;cnt++){

if((cnt)%2 == 0){
//Even
target = initialPosition + <1.0,1.0,0.0>;
}else{
//Odd
target = initialPosition - <1.0,1.0,0.0>;
}//end else
llOwnerSay((string)target);
llMoveToTarget(target,0.2);
llSleep(2.0);
}//end for loop
llOwnerSay("touch me again";
}//end touch_start

on_rez(integer start_param){
llResetScript();
}//end on_rez

}//end default

Are they young and troubled prims? They run away sometimes...

Try adding a llStopMoveToTarget() at the end of your for loop. Does that help?

You can script a failsafe into it, so that it dies if it takes off next time. Use llOverMyLand or maybe set a string variable equal to your sim's name and then test against llGetRegionName. That won't stop the object from taking off, but it will save you the trouble of chasing it or waiting for it to show up in Lost & Found.

ETA: Or maybe add a not_at_target event in which you test to see how far the object is from where it was rezzed. If the distance is greater than 10m, tell it to abort and return to where you rezzed it. That still doesn't tell you why it took off, but it puts the object on a leash.

/me still bets it will run away.

The move target, like floaty text and color and such, seems to be a property of the object. I'd bet that if he (he?) took it back into inventory, went to a different region and rezzed it at (or near) the same x/y/z, it wouldn't run away.

edit: to see this effect, just do a llMoveToTarget then, once the prim has stopped moving, edit it and move it away from the target. It'll run back to the target once you let it go.

/me will have to test this out.. Possibly add a JIRA for it, unless somebody can think of a good reason why the target should persist across a trip through inventory.

Testing movement scripts......................................

Learned the hard way, you always set to temporary in the touch event and they will poof after about 55 seconds. Once you have it working correctly then you can take the fail safe out. Alternatively you can also just right click and set temp in the edit window.

I have a workaround that prevents the object from running away. The workaround is to NOT manually set the Physical switch on the prim and to set it to physical in the touch event handler. That way it isn't physical when it is rezzed, but it is physical when the llMoveToTarget function is called.

What I don't understand is what causes it to run away in the first place when I manually make it physical and rez it from inventory. The x/y/z coordinate values displayed match the location where it is rezzed. However, then it takes off and in most cases ends up lost on some other property.

What am I missing about rezzing a physical object from inventory?

/me points to what Meade said above.

edit: and I'd add to what she said by suggesting you turn physical on in touch_start, do the movement stuff then (in this order) turn physical off and call llStopMoveToTarget at the end of touch_start.