Help with llSitTarget()

My goal here is to be able to set a Sit Target, so that no matter the object's current rotation, the target is a location at <0,0,1> in global terms.

So far, I've come up with this snippet, which only works in local terms.

adjusttarget() {
curRot = llGetRot();
rotation sitRot = ZERO_ROTATION / curRot;
vector pos = (<0,0,1> / curRot);
llSitTarget(pos,sitRot);
}

Any help would be muchly appreciated.

that snippet should do what you want

Unfortunately not. When used, the code I posted only works in the local coordinates. I end up positioned some distance along the local Z-axis.

Have you tried doing this?

sitOffset * llGetRot()

Yes, I did. When using llSitTarget, the object's rotation is already applied to the vector of the offset. By applying the inverse as in my script above, I negate the rotation in local terms. I am attempting to find a formula that will negate the rotation in GLOBAL terms.

Kyree's llSitTarget problem can be reproduced using this overly complex experiment:

Note that the vector 'TEST_POSITION' in the following scripts should be replaced with a location where you know you can work in peace. Your roof, for instance.

Create a 5x5x5 sphere and put the following script in it:

vector TEST_POSITION = <179,16,65>;

default {
state_entry() {
llSetAlpha(0.0,0);
llSetTimerEvent(1.0);
}

timer() { llSetText((string)(llGetPos() - TEST_POSITION) + "\n" + (string)llGetRot(),<1,1,1>,1.0); }
}

Attach this sphere to your pelvis, where it will display the position and rotation of your bottom.

Next, create an ordinary 5x5x5 cube. Drag a bright, easily seen texture to the top facet of the cube and leave the rest a dull wooden texture. Put the following script in the cube:

vector TEST_POSITION = <179,16,65>;
vector SIT_POSITION = <0,0,1>;
// vector SIT_POSITION = <0,1,0>;
integer CHANGE_ROTATION = FALSE;
// integer CHANGE_ROTATION = TRUE;

default {
state_entry() {
llSetPos(TEST_POSITION);
llInstantMessage(llGetOwner(),"I went to " + (string)TEST_POSITION + " at " + llGetRegionName());
rotation rot = ZERO_ROTATION;
if (CHANGE_ROTATION) rot = ZERO_ROTATION / llGetLocalRot();
llSitTarget(SIT_POSITION,rot);
}
}

Sit on the cube. Your bottom should report (depending on the length of your body):
<0.00000, 0.00000, 1.35844> & <0.00000, 0.00000, 0.00000, 1.00000>

Change the vector SIT_POSITION to <0,1,0> and repeat the test. Your bottom should report:
<0.00000, 1.00000, 0.35844> & <0.00000, 0.00000, 0.00000, 1.00000>

Change the integer CHANGE_ROTATION to TRUE and repeat the previous two tests. Your bottom should again report:
<0.00000, 0.00000, 1.35844> & <0.00000, 0.00000, 0.00000, 1.00000>
<0.00000, 1.00000, 0.35844> & <0.00000, 0.00000, 0.00000, 1.00000>

Finally, edit the cube. In the 'rotation' section, change the 'X' value to '90', rotating the cube 90 degrees. Repeat the previous four tests with this new rotation. Your bottom now reports (quite to our collective surprise):
<0.00000, -1.35845, 0.00000> & <0.70711, 0.00000, 0.00000, 0.70711>
<0.00000, -0.35845, 1.00000> & <0.70711, 0.00000, 0.00000, 0.70711>
<0.00000, -1.40000, -0.04156> & <-0.00002, 0.00000, 0.00000, 1.00000>
<0.00000, -0.40000, 0.95844> & <0.00000, 0.00000, 0.00000, 1.00000>

You will notice that the rotation of the cube changes where you will sit in relation to the cube, often dramatically. None of us (there are several of us working on this project) know why this is happening, whether it is a bug, or what the workaround is. While this is not a problem for cubes, this can become a serious issue when assigning sit targets to toruses or cylinders, which must be placed and rotated in specific ways to build stylish furniture.

Normally, one would use pose balls for this, but the purpose of this project is to build quality, animated furniture with a minimum of prims and scripts. This, in turn, has endless applications in SecondLife, including saving the prims on a plot of land and allowing more passengers in a vehicle.

PHP tags, Tamaria, PHP tags... See my post.

Anyways, this might work if you multiplied by the inverse rotation, using this function:

rotation rotInverse( rotation in )
{
    return < -in.x, -in.y, -in.z, -in.s >;
}

I believe that should work.

Last one should be in.s

and ZERO_ROTATION / in works as well.

Okay. I was admittedly off in my assumptions in my earlier posts. However, here is the current problem.

When the base prim has a rotation along the X-axis, the resultant sit position tends to be incorrect in the Y axis. The same goes for rotation along the Y axis.

This difference is the same, irregardless of the offset we desire. For every one degree of rotation, the sitTarget is off by 0.007m, up until you reach 30 degrees. At thirty degrees of rotation, the error becomes 0.2m in total. At 90 degrees of rotation, the error is 0.4m.

Bug report this - I get this too, have since 1.4. Not sure if it's a math error, or if it's soemthing wierd about sit targets.