Discussion: Easy Sit Target Positioner

Boss is correct, and it's easy to verify -- if you have a prim with sit target at <0, 0, 1> and AV equipped with attachment which calculates offset between llGetRootPosition() i.e. AV centre point and another prim placed in the very same spot where you place the prim your AV is sitting at... you'll notice the final offset is 1.4 m on the Z-axis (1m from sit target and 0.4 m hardcoded offset along the up vector) which is then further modified by small 3-5 cm long vector which matches opposite of rotation specified in sit target parameters.

This 3-5 cm vector varies its length depending on size of AV... strangely enough doesn't seem to have any impact on the sit target calculations which is why the simpler version of the script i posted above appears to work o.O;

Yanno what, I'm going to have to test this, but I think you have a pretty good point here. Since the 0.186 offset happens in both sit targets, they cancel each other out, and there's no need to bother with them at all in this application. They're a relic from when I was trying to land the avatar at an exact point in space, rather than just match another object's sit target.

They will only cancel out if the two prims (sensor and helper) are at the same rotation.

That's the thing; if i have the code that takes into account that small variance added, it winds up more or less wrong. If i don't bother with variance vector at all the alignment and position is perfect... no matter how the sit prim and helper prim are rotated in relation to each other.

Just weird o.O;

Hmm, that's odd... does this end up killing the effectiveness of my system?

Are you sure? The 0.186 portion was a world-relative offset.

It will appear to be a world-relative offset as long as your sit rotation is at or near ZERO_ROTATION, because that is what rotates it.

Lex, have I told you lately how much I loved you?

I don't think you understand what I meant. The 0.4 portion is rotation-relative, but the 0.186 portion is always world-relative.

<3

I love you too, Lex.

I did put the pose scripts in the sofa seat and then pulled out a copy of the sofa seat and put the helper script in it. Works like a charm!

This looks like a fantastic script, especially for vehicles. I am sure i could have used this when i was working on my chopper a while back.

I have to say, though in the defense of pose balls, that they do have something of a purpose. They let you choose which pose to take when there are multiple pose balls on an object. A couch i recently made has pose balls for that reason.

I am sure I would use this in any chair intended for a single toon as well (no need for a pose ball).

I am a fan of your scripts Lex! Keep up the great work.

Furia

I'm looking forward to trying this myself. I got some nice freebie chairs, but without sit targets!

Yes, poseballs serve a purpse. They also serve as visual cues in public places that there's something to do. But they shouldn't be needed for a simple chair or bed (PG bed, of course).

Wow, it works great! Couldn't be easier!

I did make one change: if the sit helper isn't present, it doesn't clear the sit target. The first time I goofed. Deleted the sit-helper, then when to edit the chair but accidentally touched rather than selected. Oops, do-over.

I will distribute this (for $0L) on SLExchange, if there are no objections. With credits to Lex, of course.

Cheers
Jeff

ok the last vehicle I scripted I spent 3 very painfull hours setting sit positions with rotations that never lined up right, and veroius other painfull things trying to get a car to seat 4 people without using extra prims for specific seats. The most recent one I did with your script, took 8-10 minutes, and most of that was in copy and pasting the script into SL
VERY NICELY DONE

I tried to distill this formula down to run in state_entry, to set child sittargets, instead of probing around with external objects, just rely on the parent prim for orientation. But the alignment still seems off, am I using this formula wrong?

llSitTarget((POS_OFFSET - llGetLocalPos()
   + llRot2Up(llGetRootRotation())*0.4 - llRot2Up(llGetRot())*0.4)/llGetRot(),
   llGetRootRotation()/llGetRot()*llAxisAngle2Rot(llRot2Up(llGetRot()), PI));

Yes, I know it's ugly;]

Bump, and a correction. The script above should set a pose mirroring the pose set by this script:

llSitTarget((POS_OFFSET - llGetLocalPos()
   + llRot2Up(llGetRootRotation())*0.4 - llRot2Up(llGetRot())*0.4)/llGetRot(),
        llGetRootRotation()/llGetRot());

Where POS_OFFSET is the same positional offset in the parent prim. Both scripts work as well as each other, so the troublesome formula is in the code above.

I'm sorry, Prodigal, I really don't know what's wrong with your code. With such a spew of functions all in one line like that, it's really hard to distill the essence of what you've written and make sure it's right.

It's mighty terse and tight, I do tend to write that way. Let me comment it.

llSitTarget((POS_OFFSET - llGetLocalPos()

What every sittarget in a child prim should have to line up the anim with the one in the parent.

   + llRot2Up(llGetRootRotation())*0.4 - llRot2Up(llGetRot())*0.4)/llGetRot(),

The same code I gathered from here, the root rotation being the 'helper' in your code, and the prim rot being your 'avatar'.

        llGetRootRotation()/llGetRot());

Again, should be standard in child animations.

Now I've tested this code out with a linked set of boxes all tilted to various angles, a sensor to detect the sitpos. Debug messages always shows the avatar sitting in the exact same position, but the positioning always looks a bit off, moreso the further away the boxes are dragged from each other.

Awesome work Lex! I spent months and months working on the exact same thing. I must have been running into the same bugs you did at first. Good job.

I believe I have this figured out:

llSitTarget((<0.0, 0.0, 0.1> + llGetRootPosition()
// root position plus the offset of it's sittarget

  + (0.4 * llRot2Up(llGetRootRotation())) - (0.4 * llRot2Up(llGetRot())) - llGetPos()) 
// compensation for drift on the z of the root and the child prims.

  / llGetRot(),
// divided by the child's rotation

llGetRootRotation() / llGetRot());
// Could also multiply the parent sittarget offset 

Putting this in any and all child prims will set the sittarget to within a millionth of a point of the same pos, but if the root is rotated, they'll be roughly +/- .05 off of the root position.

This means the intricate scenes I've laid out in Poser can be combined into one object without ugly and extraneous prims. And this cuts down the time in using a sit helper, since you already have the root prim to provide a point of reference, simply drop this snippet of code into all child prims.

EDIT: Spoke too soon, it still appears to be off by .05 even if the root isn't rotated. What am I missing from this script?

I think the 0.05 error might simply be intrinsic to my code. I remember seeing an error of a few millimeters, perhaps as much as 5 centimeters, and others saw it too. I think it's just more weirdness in llSitTarget that's not really easy to compensate for from the outside.

It may just be another symptom of the recent grid troubles, and it may be the good old floating point error...sometimes I got different drift values on the same prim without moving or rotating. But I compared to results using the sittarg setter and helper and found that the shorter formula was more precise.

Not sure if this is the correct place to post this, but here goes!

Fresh install of Winxp Pro, fresh install of Blender, and Python 2.4. Blender loads up fine, but when I execute script I get this:

Compiled with Python version 2.4.
Checking for installed Python... got it!
hippos!
Drawing end using token:
0
Outer is:
[(-0.5, -0.5, 0.5), (-0.25, -0.5, 0.5), (0.0, -0.5, 0.5), (0.25, -0.5, 0.5), (0.
5, -0.5, 0.5), (0.5, -0.25, 0.5), (0.5, 0.0, 0.5), (0.5, 0.25, 0.5), (0.5, 0.5,
0.5), (0.25, 0.5, 0.5), (0.0, 0.5, 0.5), (-0.25, 0.5, 0.5), (-0.5, 0.5, 0.5), (-
0.5, 0.25, 0.5), (-0.5, 0.0, 0.5), (-0.5, -0.25, 0.5), (-0.5, -0.5, 0.5)]
Inner is:
[(0, 0, 0.5)]
Drawing end using token:
90
Traceback (most recent call last):
File "Main.py", line 3981, in ?
File "Main.py", line 3502, in llNewPrim
RuntimeError: expected tuple of one item
Malloc returns nill: len=1073741824 in temp_char_accum, total 941062692

I've tried reinstalling Python 2.4, I tried 2.5. I'm kinda stumped. Anyone have any ideas?

Thank you Lex for making such a great script! It works very well on any size of prim i wanna sit on.

I'm using it on different sizes of chairs and that tells me the exact llSitTarget() parameters i need to fit on the chairs everytime as i need it to activate llAvatarOnSitTarget().

My situation here is: i tell the sitting avatar to perform 2 animations based on the llSitTarget() parameters i got from running Lex's code. One of them works well since the animation sitting position is similar to the SL default sitting position. However, the other animation is higher off the z-axis from the SL default sitting position. As a result, each time when the avatar performs the 2nd animation, he's like sitting in the air. But when he does back to the 1st animation, it works perfectly well.

i could run the 2nd animation on the "sit target helper" before i touch the "sit target setter". Thus i can get the correct parameters for the 2nd animation. However, it would obviously be inconsistent to the 1st animation and vice versa.

Is there any way to tell the avatar to sit lower in the 2nd animation (or higher the first animation) without changing anything from the animation file? (the animation files are no mod so i can't change).

Appreicate any help.