llGetRot() == llGetRootRotation() - a bug?

In a linked set, I'd expect llGetPos() and llGetRot() to return the rotation and position of the object. What I'm seeing is that they are returning the position and the rotation of the root prim. (as does the edit window)

position two cubes corner to corner, link them and throw this script in to see the problem. You can edit linked parts and rotate the root prim and still get matching results.

default
{
    touch_start( integer n)
    {
        llOwnerSay("Object Pos: " + (string)llGetPos() );
        llOwnerSay("Root Pos: " + (string)llGetRootPosition() );
        llOwnerSay("Object Rot: " + (string)llGetRot() );
        llOwnerSay("Root Rot: " + (string)llGetRootRotation() );
    }
}

This looks like a bug to me, otherwise the llGetRootxx functions seem redundant. A good trawl through the forums and wiki didn't turn up any rezzers doing fancy things with getting the geometric centre, so I'm guessing this used to work. Am I just missing something or is this, as I suspect, a bug?

Your script and get everything ll works fine. You need to check "edit linked parts" and put a copy of the script into the child prim also.

Reading between the lines.. So the object position and rotation is the same as the root prim?

Ah.. found it.. it does say that on the llGetGeometricCenter wiki entry.

I've added the info to the llGetPos wiki page to save anyone else scratching their head over this behaviour

Reading the llGetPos page again, it should probably be completely overhauled and all mentions of "object" purged. Just saying it returns the position of the prim the script is in makes things a lot clearer and avoids all the explantion about child prims etc.

llGetPos() called from child prim of linked set returns equivalent of llGetRootPos() + llGetLocalPos()

llGetRot() called from child prim of linked set attached to AV returns rotation of the AV combined with local rotation of the prim, equivalent of llGetLocalRot() * llGetRootRotation() ... while llGetRootRotation() returns rotation of the AV itself, i.e. equivalent of llGetRot() / llGetLocalRot()

I finally figured out what you were refering to.

Per the wiki;
vector llGetPos()

Returns the OBJECT's position

rotation llGetRot()

Returns the OBJECT's rotation.

and yes you would be right in that the wiki is wrong in both cases. The term OBJECT is a poor choice of words. But you will also find that llGetGeometricCenter does not return what you are looking for either. To get the numbers shown at the top of the screen you need to get the center of the bounding box and there is no function that gives that. You have to get the bounding box and start adding limits and divide by two. Took me 3 months to finally figure out how to get those exact numbers on top of the screen. Here is a little script I cobbled together one day to show those numbers:

default{
    touch_start(integer total_number){
        vector pos = llGetPos();
        key thiskey = llGetKey();
        list box = llGetBoundingBox(thiskey);
		vector min = llList2Vector(box, 0); 
        vector max = llList2Vector(box, 1); 
        vector offset = (min + max) / 2;
        llSetText((string)box + "\n" + (string)offset.x + " , " +(string)offset.y + " , " + (string)offset.z + "\n" + 
        (string)pos.x + "," + (string)pos.y + "," + (string)pos.z, <0,0,0>,1);
        state next;
    }
}
state next{
    touch_start(integer total_number){
        llSetText("", <0,0,0>,0);
        state default;
    }
}

From the wiki, http://lslwiki.com/lslwiki/wakka.php?wakka=object



I can see how this would imply that "object" refers to either an unlinked prim, or a collection of linked prims, but does not specify that linked prims are also objects unto themselves for some purposes. For example, if the script in a child prim executes llDie(), the entire link set poofs, not just the prim with the script.

Yes but in that same quotation it says a single prim is called an object but ALSO that a linkset is also called an object. llGetPos does not give the position of an object which is a linkset. That's why I said it is a poor choice of words.