Library: message loop friendly MoveToPos()

////////////////////////////////////////////////////////////////////////////////////////////////
// Message loop friendly MoveToPos!
// We're using a timer to call llSetPrimitiveParams([PRIM_POSITION...so as to allow other // events to be responded to.
// THIS SCRIPT IS A TOTAL FREEBIE! Change it, sell it, call it your own, slather it in CheeseWhip,...I care not. Although if try to say wrote it everyone will know you lie
////////////////////////////////////////////////////////////////////////////////////////////////

vector g_vDestination = <0,0,0>;// Our destination...<0,0,0> is just the default

// Call MoveStart just ONCE to start movement
MoveStart(vector vDestination)
{
g_vDestination = vDestination;
llSetTimerEvent(0.3);//start the timer. It will call MoveToPos until g_vDestination is reached. 0.3 sec is a good value to use in llSetTimerEvent so as to allow other events to be triggered.
}


// No need to call MoveToPos() as it will be called by timer
MoveToPos()
{
vector vPos = llGetPos();
vector vMoveBig = g_vDestination - vPos;
float fDistance = llVecMag(vMoveBig);
if(fDistance > 10)// distance is greater than llSetPrimitiveParams can handle, so just 10m toward destination
{
vector vNewPos = vPos + llVecNorm(vMoveBig)*10;
llSetPrimitiveParams([PRIM_POSITION,vNewPos]);//moving
}
else //Yay! Almost there..just this one last move
{
llSetTimerEvent(0);// Stop the timer. You could also use llResetScript
llSetPrimitiveParams([PRIM_POSITION,g_vDestination]); //moving
g_vDestination = <0,0,0>; // reset to default
}
}



default
{
state_entry()
{
llSay(0, "Aztral Aeon says Hello!";
}


// For test purposes i just used touch_start to cause movement.
touch_start(integer total_number)
{
vector vDest = <150,111,35>; //obviously you should change this to where YOU want to move
MoveStart(vDest);
}

// will call MovePos until destination reached and timer is ended. Must be used in your script
timer()
{
MoveToPos();
}
}

library bump.

I'm grave digging, I know, but I see something in this script which may mislead some people. llSetPrimitiveParams carries with it a 0.2 second delay, manditory. If the only thing you are doing with it is moving, it would probably be alot better to just use llSetPos as it doesn't have this delay.

From here you have two options: Speed up your timer so that it gets to the destination quicker, or leave the timer as is so you have more time to execute other events. Either way, it's a win-win situation.

I don't see what advantage there is in using llSetPrimitiveParams here without stacking calls like warpPos does. (putting multiple PRIM_POSITION calls all in one list will make them all execute with only the single 0.2 second delay, getting to a destination over 10m instantly.)

Also, while all the extra math is useful to know, in this case it is unnecessary, as just putting in the final destination is sufficient. SL itself will cap the movement to 10 meters for you. Taking all of that out and replacing it with just a simple llSetPos(vDest) in a loop will reduce the amount of code being executed, adding to the two choices above. A simple version would be something like this:

default
{
  state_entry()
  {
    //destination where you want to go.
    vector vDest = <150,111,35>;

     //if our current position is not within 0.1 meters...
    while(llVecDist(llGetPos(),vDest)>0.1)
    {
       //then move, otherwise we exit the while loop.
      llSetPos(vDest);
    }
  }
}

or an event friendly version would be the following timer:

//destination you want to move to.
vector vDest=<127,127,40>;

default
{
  state_entry()
  {
    //Start the move. bigger number for slower movement
    //or more time to fire other events.
    //I wouldn't go much smaller than this though.
    llSetTimerEvent(0.1);
  }


  timer()
  {
    //move towards the destination, SL will cap it at 10 meters for you.
    llSetPos(vDest); 

     //check to see if our destination is within 0.1 meters of our current position.
    if(llVecDist(llGetPos(),vDest)>0.1)
    {
       //if it is, then stop the timer. We have arrived.
      llSetTimerEvent(0);
    }
  }
}

Note: llSetPos does have a 0.2 second delay.

Sorry about that. your correct it does have a 0.2 second delay. So the delay time savings won't be recovered by using llSetPos, but I still stand by the rest. I see no advantage to using llSetPrimitiveParams for something as simple as this. Not bashing the author, just providing a script example alternative that some people may find easier to understand.

Leaving my post above unedited to maintain continuity in posts and corrections made by Tyken. Thanks for pointing that out, I should have known that.

Helloz All,

Just getting back to SL after awhile.

Anywayz, thank Del for the post. There was a reason (i think) i used setprimparam over SetPos, i just forgot now Also, I'm not seeing much of difference in terms of complexity between the 2 options...I mean one extra CONSTANT param to enter?

And the MAIN point of the post was be message loop friendly (check the thread title). Most movetopos, warppos (whatever) functions I've seen wrap the setpos call up in a for loop...which will block retrieval of any sent messages. Now, you may be able to get these back when movement loop exits, but maybe not. If the number of messages the system can hold is exceeded (forgot the number, or maybe it's memory constraints)

So, this function won't block. You can receive and respond to messages using this method as your heart desires.

~AZ

All submissions are warmly greeted Aztral, especially from new people here in the Scripting Forum(although I guess you could nearly be called a new oldbie). Hope to see more participation or even questions from you.

Have you looked at posJumP yet? It will all excute in one server frame. Support for it isn't exactly official but we are hoping to change that. It is actually a much more elegant way to do a warp:

http://wiki.secondlife.com/wiki/PosJump

Hey thankz!

I havent seen this, but I'm planning on trying out very soon

Yup, newbie/oldbie/whatever, somehow that silly white dot is back over head and I'm too lazy to fix it atm

~Az

There's a sentence on the page about jumppos which seems to say the bug that allowed it to work has been fixed.

Is that correct?