Don't click here unless you want to be banned.

LSL Wiki : llSetPos

HomePage :: PageIndex :: RecentChanges :: RecentlyCommented :: UserSettings :: You are crawl423.us.archive.org
llSetPos(vector pos)

Moves the prim to position pos. If the calling script resides in a single prim or the root of a linked object, then pos is in region coordinates, which are relative to the simulator's southwest corner. If the script resides in a child prim in a link set, the pos is relative to the root prim of the link set.

Notes


Examples

llSetPos(<128, 128, 25>);

This moves the object to the center of the simulator, at 25m height (unless it's more than 10m away from that point, or the ground is higher than 25m there).

while (llVecDist(llGetPos(), targetposition) > 0.001) llSetPos(targetposition);

Note: this does not work for a child prim because llGetPos always returns the location in region coordinates.

Note: There is a rare error here that can occur with multiple prim objects. It the object is moved to a position where part of it is below the ground level llGetPos() will never reach targetposition. The script will hang in an infinite loop recognizable by the fact that whenever you try to move the object it will snap back to its original position. A safer method inserts an escape if there is no change on llSetPos(). As here:

object_move_to(vector position) {
    vector last;
    do {
        last = llGetPos();
        llSetPos(position);  
    } while ((llVecDist(llGetPos(),position) > 0.001) && (llGetPos() != last));
}

Child Objects

For child prims in a linked set, the position is relative to the parent prim's position (object-local coordinates). This relative position can be retrieved using llGetLocalPos.

Example:
llSetPos(<0, 0, 1>);

This moves the child prim to a position 1m upwards along the Z-axis of the parent object.

Q: Shouldn't this be:
llSetPos(llGetPos() + <0, 0, 1>)?
A: No, not for child prims -- their position is always relative to the parent. If you want to move it relative to its current offset from the parent, you'd use:
llSetPos(llGetLocalPos() + <0, 0, 1>);.

Q: Can I use llSetPos on an attachment?
A: Yes, as of SL 1.7 this is possible. Note that relative positioning applies to them as well, including HUD attachments.

Q: It says that in the parent, llSetPos repositions the entire object, and in a child prim, the position is relative to the parent's. Does this mean that there's no way to reposition the parent relative to all the other children?
A: Correct. You could theoretically do something with linking and delinking the parent, but the easiest way to deal with this situation is to not get into it. Design your object in such a way that the parent need not be repositioned relative to its children.

Q: I need to set both the rotation and position of a prim at once. My object looks jerky and weird without it.
A: You want llSetPrimitiveParams.

Q: On a linked prim, how do I calculate the local coordinate from a script in the root?
A: It is anti-intuitive, but like this:
key keyObj = llGetLinkKey(i);
list a = llGetObjectDetails(keyObj,([OBJECT_POS])); <-- returns region coordinate
vector savedp = llList2Vector(a,0) - llGetRootPosition();
and later you can use this to set another prim to that location using:
llSetLinkPrimitiveParams(i,[PRIM_POSITION,savedp]); <-- expects local coordinate



This article wasn't helpful for you? Maybe the related article at the LSL Portal is able to bring enlightenment.

Functions | Dynamics | Link
Comments [Hide comments/form]
I'd rather see something like this used for the long-distance llSetPos loop:
setPos(vector dest)
{
    float dist = llVecDist(dest,llGetPos());
    vector prevPos;
    while(dist > 0)
    {
        prevPos = llGetPos();
        llSetPos(dest);
        if(llGetPos() == prevPos) // Yipes! The object didnt move! Occurs with float error.
        {
            llSay(0,"Float error detected and recovered from.");
            return; // return from this function immediately.
        }
        dist = llVecDist(dest,llGetPos());
    }
}
-- ChristopherOmega (2004-02-17 21:10:11)
Darn, forgot to post the reasons ^_^ Well, for one, the function above only compares one float, versus three, reducing the possibility of floating point error. Also, it doesn't freeze the script in the event of the aformentioned error.
-- ChristopherOmega (2004-02-17 21:12:35)
Being a stupid newbie, I managed to lose the previous version of this comment while attempting to edit it. So, here it is again...

Another wrinkle with the long distance movement loop given in the main article is that if the destination location is computed (say, as 1/3 of the way between two known positions) it might turn out to be a position you can't precisely llSetPos() to. You won't notice that in most cases, but your script will be in an infinite loop attempting to get from x=1.234 to x=1.23403127 or whatever. This is obviously bad: the sim won't thank you, and your script won't be able to go on and do whatever it was supposed to do next.

My version of the long distance llSetPos() loop is more like this:

float delta;
 do {
    llSetPos(pos);
    delta = llVecDist(llGetPos(), pos);
 } while (delta >= 0.001); // round again if at least 1mm to go

If you wanted to take ChristopherOmega's comment above into account as well, you could use his code but with while (dist >= 0.001) or something like that instead of just while (dist > 0).
-- AlexanderDaguerre (2004-07-28 08:20:56)
Found what looks like a bug with llSetPos applied to child prims. If you're sitting on the child prim when it moves, you don't move with it - you're left sitting in mid-air, and the child prim appears to go phantom.
-- SeifertSurface (2005-07-29 02:18:18)
Closing italics. Dallas' link is http://forums.secondlife.com/showthread.php?t=55932.
-- CatherineOmega (2005-08-01 16:20:42)
I have a whole forum about the issues SeiferSurface mentioned at http:forums.secondlife.com/showthread.php?t=55932 Someone explained the sit thing, however the bug with some child prims going phantom after they are moved its still unsolved.
-- DallasWilliamson (2005-08-03 14:22:26)

Italics correction.
-- ChristopherOmega (2005-08-04 01:03:27)
the post noted above by DallasWilliamson corrected: http:forums.secondlife.com/showthread.php?t=55932
-- NonnuxWhite (2005-08-25 01:54:37)
Erm... not quite. Sit Explanation
-- KeknehvPsaltery (2005-08-25 13:20:37)
When using llSetPos(llGetLocalPos() + <0, 5, 0>); (to move a child prim). The child appears to move relative to the rotation of the Parent. You 'see' it moving as you would expect it to, but in an unvisible way it actually moves relative to the local grid. Try llSetPos(llGetLocalPos() + <0, 5, 0>); Sleep(5); llSetPos(llGetLocalPos() - <0, 5, 0>); with a linked pair of boxes in a touch event. It works as expected, but then rotate the linked pair 90 degrees. It APPEARS to move the child in a plane 90 degrees rotated from before, but invisibly to you it doesn't! The child actually moves in the same plane as before the rotation only it appears to move relative to the root prim's rotation. You can walk around and bump into the actual invisible location while walking through the box's apparent location as if it were phantom.
-- CandyPeart (2005-11-19 15:35:16)
I can confirm that something very strange is happening with Candy's example. When I tried it, again if the root prim has default rotation all is well. If I turn it 90 degrees, then the child prim appears to move to the correct position, but it's actual position (the thing I can bump into and not walk through) is 180 degrees from where it was when the root prim rotation was ZERO_ROTATION.
-- SeifertSurface (2005-11-19 22:20:33)
The child prim bounding box bug seems to have been fixed, as of 1.7.4(5): bug fix - * Child objects that move now have the correct collision box
-- SeifertSurface (2005-11-21 10:44:37)
Didn't see why the link to Globalcoordinates needed to exist when it redirected to globalcoordinate, so I fixed it. Hopefully no problems.
-- MalarthiBehemoth (2006-04-04 22:44:11)
My experience suggests that this function fails in a terribly unfriendly way when it is used to request that a linked primitive move outside legal linking range from its siblings. This isn't very surprising, but I'd like it to be explicitly mentioned on this page nonetheless--it would have saved me some trouble!
-- JeremiahSansome (2006-04-23 16:30:05)
Attach a comment to this page: