Compute Relative llSitTarget

I've got two unlinked prims. You sit on one and position and rotate as desired. You then touch the other one and it computes its sit target so that when you sit on it, you end up in exactly the same place with exactly the same orientation as when you sat on the first prim.

Except the offset I'm computing isn't correctly accounting for the first prim's rotation. I can't figure out where I'm going wrong. Any input would be greatly appreciated.

Here is the script I'm using:

touch_start(integer count)
{
    llSensor("SitTargetHelper", NULL_KEY, PASSIVE, 5.0, PI);
}

sensor(integer count)
{
    
    // get detected prim position and rotation
    vector dpos = llDetectedPos(0);
    rotation drot = llDetectedRot(0);
    
    // get my position and rotoation
    vector mpos = llGetPos();
    rotation mrot = llGetRot();

    // actual sit position after accounting for detected prim's 
    // sit target offset and rotation
    vector apos = dpos + (<0.0, 0.0, 0.1> * drot); 
    
    // sit offset is relative to me with adjustment for my rotation
    vector off = (apos - mpos) * (ZERO_ROTATION / mrot);
    
    // sit rotation compenstates for my rotation
    rotation rot = drot * (ZERO_ROTATION / mrot);
    
    // set my sit target
    llSitTarget(off, rot);
    
}

I think you need to just use * mrot not (ZERO_ROTATION / mrot)

Nothing wrong with the math here. Then why doesn't it work?

Consider the following... if we were being rational, it should keep the sitter in the same "place" relative to the prim no matter how the prim is rotated (then touched to set the new sit target), right? ...erm ...try it!

default {
    touch_start(integer number) {
        llSitTarget(<0.0, 0.0, 1.0> / llGetRot(), ZERO_ROTATION / llGetRot());
    }

}

**start edit**
The target rotation center now seems to be offset by 0.4m from the target position, this is a bug and I reported it as bug #496343.

One workaround is to set the target sit position to <0, 0, -0.4> to void the effects of an offset rotational center (which you can't do anything about).

The wiki notes on llSitTarget has a "cancel rotation" example which also doesn't work any more/at the moment.
** end edit **

How far off is it? Say, about half a meter every time, regardless of how far away the helper prim is? Is it off in a different direction depending on what the absolute rotations of the helper and the base are?

See, I ask because I once wrote a helper very much like this, and despite the fact that I knew my math was correct (and it was almost exactly the same as yours), I couldn't get the sit targets the same. My conclusion after a few hours of intensive hair-pulling was that llSitTarget() has some kind of bug... and I couldn't nail it down to even figure out how to compensate for it.

So now I continue to do my sit targets by hand. Annoying, eh?

Not correct. What would perhaps be more proper is "/ mrot", which is equivalent to "* (ZERO_ROTATION / mrot)".

OK this is proof of the bug (i.e. it is Eye Ree's script modified to work as things are currently, but it is NOT recommended for any use as when the bug is fixed, this will break). For a workaround it would be far better to use a sit target pos of <0, 0, -0.4> for now...

default {
    touch_start(integer count) {
        llSensor("SitTargetHelper", NULL_KEY, SCRIPTED | PASSIVE, 5.0, PI);
    }
    
    sensor(integer count) {
    
        // get detected prim position and rotation
        vector dpos = llDetectedPos(0);
        rotation drot = llDetectedRot(0);
        
        // get my position and rotoation
        vector mpos = llGetPos();
        rotation mrot = llGetRot();
        
        // actual sit position after accounting for detected prim's
        // sit target offset and rotation
        vector apos = dpos + (<0.0, 0.0, 0.1> * drot);
        
        // sit rotation compenstates for my rotation
        rotation rot = drot / mrot;
        
        // sit offset is relative to me with adjustment for my rotation
        vector BUG_CORRECTION = <0.0, 0.0, 0.4> - <0.0, 0.0, 0.4> * rot;
        vector off = (apos - mpos - BUG_CORRECTION) / mrot;
        
        // set my sit target
        llSitTarget(off, rot);
    }
} 

Come to think of it, I wonder if it hasn't always been this way, as changing this would break every existing sit target in the game... so maybe - even if a bug - it's one that will never be fixed...

Thanks for confirming it is a bug. I wasn't sure if I was just missing something or if things were not working as they should.

The amount it is off by depends on how much the detected prim has been rotated. At zero rotation things line up perfectly. It doesn't seem to depend on how far away the prims are from each other.

Escort, how did you figure out the the amount of correction? The script still isn't working when the prim running the script has been rotated. I'll see if I can figure out what other adjustments are necessary.

I'm pretty sure I was seeing this behavior prior to 1.13. Perhaps it has always worked the way it is now?

I answered the question. Given the information I have already provided it's not too hard to update your script to account for a rotation in the scripted prim. *sigh*. If you need help doing that then you should know that my rates are highly unreasonable.


I am pretty sure you are right here.

Here is a script that works correctly even when both prims are rotated:

touch_start(integer count)
{
    llSensor("SitTargetHelper", NULL_KEY, PASSIVE, 5.0, PI);
}

sensor(integer count)
{
    
    // get detected prim position and rotation
    vector dpos = llDetectedPos(0);
    rotation drot = llDetectedRot(0);
    
    // get my position and rotoation
    vector mpos = llGetPos();
    rotation mrot = llGetRot();
    
    // actual sit position after accounting for detected prim's 
    // sit target offset and rotation 
    vector apos = dpos + (<0.0, 0.0, 0.1> * drot);
     
    // sit rotation compenstates for my rotation 
    rotation rot = drot / mrot; 

    // sit offset is relative to me with adjustment for my rotation and
    // the 0.4m adjustment llSitTarget makes to the target rotation center
    vector dadj = <0.0, 0.0, 0.4> - (<0.0, 0.0, 0.4> * drot); 
    vector madj = <0.0, 0.0, 0.4> - (<0.0, 0.0, 0.4> * mrot);
    vector adj = dadj - madj;
    vector off = (apos - mpos - adj) / mrot; 
    
    // set my sit target
    llSitTarget(off, rot);
    
}

Thanks again to everyone who helped work this out!

Wow, what a mess. I did some of my own studying off in the eastern wastelands of Suffugium sim yesterday. I took Escort's script that always sets the sit target 1m up, and put it in an object that is shaped like a set of coordinate axes. Then I started rotating it and plotting a green prim where the avatar should have ended up, and a red prim where they did end up. At one point I ended up plotting a bunch of prims that showed the drift as the object's rotation is brought through progressive 10-degree incremental rotations around the X axis.

The result is a circle of red prims that shows exactly what was found above: the position drifts as a function of the rotation of the object. The only thing is, while I hadn't gotten a chance to try to fit a corrective formula to it, it looked like it was going to end up being more like "<0,0,0.2> - <0,0,0.4>*llGetRot()"... I'll have to look at it more closely.

As to whether or not LL would actually make this "correct", considering the fact that it would kill a bunch of existing scripts? Well, they did fix a bug in llXorBase64Strings(), but since that would have killed a lot of existing scripts that relied on the incorrect behavior, they made the fixed one llXorBase64StringsCorrect(). Maybe we could get llSitTargetCorrect().

What I really want, though, is a friggin user interface to sit-targets. They're just too widely used not to have one.

It's actually rather funny..I designed something to have the end result similar to the goal of this yesterday.

Basic operation of mine, however, was you put the main script and an object inside the seat you're programming the sit target for. You then click the item and it rezzes a ball. After that, all you do is sit on the ball and move yourself to where you want to sit and rotate it appropriately. So essentially you're moving yourself into the desired sitting position. Once you have this stand up and click on the object. It then informs you of the llSitTarget() command required to produce the result.

My only problem with this was I had to set a sit target other than <0,0,0> in the sphere so that you would actually sit on it (and set a <0,0,0> to clear it out of the seat itself), and I'm having to reprogram the math to compensate for this offset.

I'm not trying to hijack the thread or anything, but I was rather curious since me and the OP are doing the same thing at about the same time. I'm not any good at the complex math parts of LSL, but I had thought that I could just directly remove the sit target loc from the one calculated by the prim, but evidently it doesn't really work.

Strangely enough....it was fine on 2 of the axis, but was too far back on X when actually sitting. I have no idea why this would miscalculate that one axis when all 3 are changed by the same offset.

Lex, I did pretty much the same thing when I was trying to work this out. Check out http://www.flickr.com/photos/54667375@N00/313439589/.

Tiarnalalon, I'm going for almost the same thing as you as well. I'm thinking it would be cool if the seat allowed each AV to configure their own position and rotation for a set of poses stored in the seat. Upon return the AV could touch the seat to prepare it for him/her/it, and then sit. I hope to post the scripts for this to the scripting library once I have them finished. Shouldn’t be too hard now that the offset issue has been resolved.

From my trials, it looks like my correction is more like the following:

vector corrected = ((relative_pos + <0,0,0.186>) / llGetRot()) 
                            - <0,0,0.4>;

So to set a sit target exactly 1 meter above the object, I do this:

llSitTarget((<0,0,1> + <0,0,0.186>) / llGetRot() - <0,0,0.4>,
                 ZERO_VECTOR / llGetRot());

I'm not sure why my world-based offset is <0,0,0.186> while Escort's is <0,0,0.4>. The only thing I can think is that mine is more accurate because I cancelled the sit animation (which includes some offset) and played an animation that has no offset.

I canceled sit for my tests and 0.4m still seemed to be pretty accurate. Could it be related to AV size? My AV is about as tall as the sliders allow.

I tested your script... works fine - well done!

However, as you were wondering, AV height is absolutely a factor. I ran a quick test with setting an AV to max height and min height... Sit orientation remains correct, but the position *appears* incorrect.

Isn't it based on the hip? so if you have a small or large avatar their hip is still in the same spot, but it's your other body parts that seem to be out of place?

For my money it is definitely 0.4 in z.

Here's how I found it.

1) Set the sit pos target to <0,0,1.0>. Set the sit rotation to (llEuler2Rot) each of <0, 0, 0>, <0, PI_BY_TWO, 0>, <0, PI, 0>, <0, -PI_BY_TWO>, 0>. Use an avatar attachment that reports llGetPos. Note the reported differences from this and average them. It always comes to 0.4 in z.

2) Set the sit pos target to <0, 0, -0.4>. Repeat the rotations as above.... etc. The differences are now zero.

/esc

I sure hope not I put on my super-tall av to try it out, and there was no difference whatsoever. I also tried shrinking the base object I was using.

Hmm... I haven't been using llGetPos() because I wasn't so sure it was going to be accurate. I've been going only off of the way the av appears (with an object attached to my pelvis and its attachment-local position at <0,0,0>, without the default sit animation playing. The thing is, my numbers in my script work beautifully and always put me in exactly the position I want to be sitting, regardless of the animation. Either this actually does have something to do with the height of the av in question, or something weird is going on here. I don't see how I could be making a mistake if my implementation produces a sit target system that works correctly...

It definitely factors in the av size. The smaller the av, the larger the offset, too.