Talk:LlSitTarget

Unsitting on wrong side or camera rotation

Hi, i am getting frustrated with this. I create a board and set the sit target with llSitTarget(<0.4, 0.0, 0.0>, ZERO_ROTATION); and an animation which for "standing". So while the person technical sits, she stands in front of the board. But I have a problem with that: If the board stand freely, the person unsits right through it towards the other side. I can put the board with the back facing a large wall. In the case the unsitting is correctly in front of it. But on sit down the camera rotates, so that it is behind the avatar again; on the other side of the wall.

If anyone has an idea how to fix, please tell me (even if it is just an idea where to look for more information). --Maike Short 12:41, 24 February 2008 (PST)

You could position the camera with the Camera functions. -- Strife Onizuka 04:46, 25 February 2008 (PST)

Optimization

<lsl> list GetSitTarget(integer prim, key av) {//WARNING: llGetObjectDetails can introduce an error that goes as far as the 5th decimal place.

   vector tp = llGetAgentSize(av);
   if(tp)
   {
       if(prim == LINK_THIS)//llGetLinkKey doesn't like LINK_THIS
           prim = llGetLinkNumber();
   
       list details = OBJECT_POS + (list)OBJECT_ROT;
       rotation f = llList2Rot(details = (llGetObjectDetails(llGetLinkKey(prim), details) + llGetObjectDetails(av, details)), 1);
   
       return [(llRot2Up(f = (llList2Rot(details, 3) / f)) * tp.z * 0.02638) +
               ((llList2Vector(details, 2) - llList2Vector(details, 0)) / f) - <0.0, 0.0, 0.4>, f];
   }
   return [];

}//Written by Strife Onizuka </lsl> Hi Strife! This version of your GetSitTarget, and the other version on the actual LlSitTarget page, both always return <0.000000, 0.000000, 0.707107, 0.707107> for the rotation. --MartinRJ Fayray 07:52, 21 January 2013 (PST)

I haven't touched this in 5 years but I don't see a reason why it should be doing what you say. Are you sure you are using it properly? The prim parameter specifies what prim the location will be local to. The function was written to aid in determining sit targets when making furniture. You have the avatar sit on one object and then you get it's position local to the furniture so you can program in the sit target.

Just to clarify, you are saying that when you sit on an object with the following script in it, you don't get approximately the specified value? -- Strife ^{(talk|contribs)} 20:37, 22 January 2013 (PST)

It seems to work now. No idea what I was doing wrong. Thank you strife!--MartinRJ Fayray 07:36, 3 February 2013 (PST)

<lsl> vector vOffset = <0,0,1>; rotation rOffset = <0,0,0,1>;

list GetSitTarget(integer prim, key av) {//WARNING: llGetObjectDetails can introduce an error that goes as far as the 5th decimal place!

//This is highly unlikely to be ever noticed unless compounded over time.
//Do not use while moving (like in a moving vehicle)!!!
   vector tp = llGetAgentSize(av);
   if(tp)
   {
       if(prim == LINK_THIS)//llGetLinkKey doesn't like LINK_THIS
           prim = llGetLinkNumber();

       list details = [OBJECT_POS, OBJECT_ROT];
       rotation f = llList2Rot(details = (llGetObjectDetails(llGetLinkKey(prim), details) + llGetObjectDetails(av, details)), 1);
       rotation r = llList2Rot(details, 3) / f;

       return [((llList2Vector(details, 2) - llList2Vector(details, 0)) / f) + (llRot2Up(r) * tp.z * 0.02638) - <0.0, 0.0, 0.4>, r];
   }
   return [];

}//Written by Strife Onizuka

default{

   state_entry(){
       llSitTarget(vOffset, rOffset);
   }
   changed(integer change){
       key id = llAvatarOnSitTarget();
       if(id)
           llOwnerSay("["+llList2CSV([vOffset, rOffset]) +"] ~ [" + llList2CSV(GetSitTarget(LINK_THIS, id))+"]");
   }

} </lsl>

Note: the two scripts in this paragraph are incorrect. Most notably, the position of an avatar (it's Avatar Center) is NOT dependent on the AgentSize of the seated avatar. I added another script that returns the sit target below. Timmy Foxclaw 10:31, 7 April 2014 (PDT)

Using llSetLinkPrimitiveParams for skydiving: why limited to 5m in a linked set?

llSetLinkPrimitiveParams can be used as a handy tool to adjust an avatar's position and rotation. This works perfectly when the object consists of 1 prim, with a range for setting the avatar position away to 500m easily! When there are more prims linked, this offset seems to be limited to 5m (measured with llVecDist). This is an awfull sideeffect!

Put this next script inside a prim and sit on the prim, it will bring you to 1000.0 higher then the prim. Next link this prim to another prim and try again. You will notice you are limited to 5m. My Question: why is this limited? <lsl> // by Randur Source

integer heightcnt = 0; list heights = [0.0, 1.0, 5.0, 6.0, 10.0, 100.0, 300.0, 500.0, 800.0, 1000.0];

default {

   state_entry()
   {
       llSitTarget(ZERO_VECTOR,ZERO_ROTATION); // Clear the current sittarget for a clear test
       llSetRot(ZERO_ROTATION); // set the prim to no rotation, for simple z axis movement
   }
   
   changed(integer change)
   {
       if (change & CHANGED_LINK) // detect linked prims and avatars
       {
           integer primnum = llGetNumberOfPrims(); // the avatar is the last linked prim
           if (primnum <= 1) // stop if there is only 1 prim
               return;
       
           key avatar = llGetLinkKey(primnum);
           if (llGetAgentSize(avatar) == ZERO_VECTOR) // stop if this is not an avatar
               return;
               
           // loop through the list of test heights:
           for (heightcnt = 0; heightcnt < llGetListLength(heights); heightcnt++)
           {
               float height = llList2Float(heights,heightcnt);
               llSetLinkPrimitiveParams(primnum,[PRIM_POSITION,<0.0,0.0,height>]); // set this to the wanted height using a vector z axis
               
               vector avatarpos = llList2Vector(llGetObjectDetails(avatar,[OBJECT_POS]),0); // detect the avatar position within the sim
               float distance = llVecDist(llGetPos(),avatarpos);
               llOwnerSay("Attempt to move " + llKey2Name(llGetLinkKey(primnum)) +
                          " to " + (string)height + "m high resulting to " + (string)distance + "m");
               
               llSleep(1.0);
           }
           llUnSit(avatar);
       }
   }

} </lsl>

Posted by Sylvio Runo : Answer  : The correct limit is 54 meters. You can't move a linked object more than 54 meters away from the axis of the root prim. On SecondLife (other grids like OsGrid, may works diferent) when an agent sit on prim, the agent is attached to it, so the agent is a linked prim of the link set.

More information about link rules, you will find here : http://wiki.secondlife.com/wiki/Linkability_Rules [1]

UpdateSitTarget changes?

I recently worked on a project where I used a version of this function, and it appears that it is a little off. A couple of things I noted: the Z-offset of the sit target is 0.35, not 0.4, and the avatar size doesn't seem to affect this position at all. When I used this function verbatim, I noticed discrepancies between the actual sit target and the set position call. When I changed the script as noted, I got a perfect match. Has the handling of the sit target been changed since this was written? Talarus Luan 22:57, 1 July 2009 (UTC)

Seconded. I wish I'd looked at this discussion before spending an hour on trying to figure out how the code actually behaved. -- Tonya Souther 15:11, 19 August 2009 (UTC)

This is news to me but I haven't been in world in ages :( -- Strife ^{(talk|contribs)} 22:56, 20 August 2009 (UTC)

From some quick testing in 1.40, this seems to be how the "true" offset is computed:

1. Start with offset as provided by LSL.

2. Add < 0.0 , 0.0 , 0.4 >

3. Subtract llRot2Up( rot ) * 0.05

--Gregory Maurer 20:00, 28 August 2010 (UTC)

Confirmed. The following appears to work fine:

<lsl>llSetLinkPrimitiveParams(linkNum, [PRIM_POS_LOCAL, pos + <0.0, 0.0, 0.4> - (llRot2Up(rot) * 0.05), PRIM_ROT_LOCAL, rot]);</lsl>

This of course using the new PRIM_POS_LOCAL and PRIM_ROT_LOCAL values for simplicity. If one or two others can confirm that the above code works correctly, then I can splice it into the example.
-- Haravikk ^{(talk|contribs)} 14:16, 26 December 2011 (PST)

Be sure to test it with avatars of different shapes, and shoe configurations. I recall that being an issue. Escort DeFarge would know about this best. -- Strife ^{(talk|contribs)} 22:05, 26 December 2011 (PST)

I tried with my two main avatar appearances, one average human height and one closer to 8 feet tall, and it didn't seem to make a difference. The test I used was a simple object with sit-target set, and a menu allowing it to be repositioned, causing the sit-target to move and if an avatar is seated on it, they will be repositioned using llSetLinkPrimitiveParams() as done above. In my case the position of the avatar was consistent both when sitting on the object (using the sit-target) and being repositioned. Avatar height appears to have no effect, as the sit-target seems to define the avatar's hip-location, which is seemingly the avatar's "centre" when seated. I'll try to run some more tests when I get a chance, as it's possible this behaviour may not hold true if the object doesn't have a sit-target on it. The height of the avatar does however have a marked visual impact, depending exactly what you're trying to line up where, but that's a general issue with sitting on objects.
-- Haravikk ^{(talk|contribs)} 05:38, 28 December 2011 (PST)

Sorry for my long delay in responding. Due to various RL issues and SL/LL burnout, I took a year off from SL to pursue other activities. That said, it seems to work fine to me, Haravikk; however, I have not done exhaustive testing with tons of different avs, shoes, etc. I would consider going ahead and changing it, because the version as it is right now is not correct for the majority of avatars, regardless. If Escort DeFarge or someone else wants to amend it later to include edge cases, that's great, but a better base accuracy is more important at this point. In fact, I think I will go ahead and edit it in, since it has been so long anyway.Talarus Luan 12:12, 5 July 2013 (PDT)

Holding up on the edit, further testing is revealing that if the script is in a prim other than the root, it is off by varying amounts depending on the rotation.Talarus Luan 12:39, 5 July 2013 (PDT)

OK, I think I found the error. Still need to keep the local position/rotation values for the child prim the script is in, like so:

<lsl>llSetLinkPrimitiveParams(linkNum, PRIM_POS_LOCAL, (pos + <0.0, 0.0, 0.4> - (llRot2Up(rot) * 0.05)) * localrot + localpos, PRIM_ROT_LOCAL, rot * localrot]);</lsl>

I'll hold off on the edit until I can get another verify that this code is good.Talarus Luan 12:51, 5 July 2013 (PDT)

OK. I think I have analyzed this to death today and have come to the conclusion that Strife's original code is largely correct, but the error I am seeing comes from the "magic constants" 0.4 and 0.02638. Haravikk's code is simply a reduced form of Strife's code. The 0.4 magic constant is still there, but Haravikk is using just a close, but fixed, magic constant of 0.05 instead of Strife's (size.z * 0.02638), which comes out very close to 0.5 for most normal human avs. Thus, I am concluding that the inaccuracy is in the "magic constants" themselves, and I am going to hold off on the edit until I can get some more information on the source of these constants and see if there are better, more accurate values. It is annoying that, in all these years, we still haven't gotten LL to just tell us what the damn difference is between avatar sit targets and local position offsets in a linkset. It can't be that hard for someone who is familiar with the code to look at it and document it. -.- Talarus Luan 13:24, 5 July 2013 (PDT)

Welcome back! I'd like to take credit for that but that's the part that Escort contributed. As to where 0.02638 comes from, I vaguely recall it came from Escort's testing. I was driven more by "wouldn't it be cool to write a function that..." than anything else. I do agree the values have always been not quite right. -- Strife ^{(talk|contribs)} 23:10, 5 July 2013 (PDT)

Thanks! OK, I did a bunch of empirical testing, sampling a bunch of avatars from 1.16m to 2.45m in height, as reported by llGetAgentSize. I picked the lowest and highest and one about standard height, and fitted a parabolic curve through them. I have reduced the inaccuracies to a great degree, but it still isn't 100% perfect for all sizes in that range, just the ones that I used to solve the curve equation. The rest show a *tiny* bit of movement, but they are very close. Obviously, the difference isn't parabolic, probably just some kind of discrete step function, but it works.Talarus Luan 11:16, 14 July 2013 (PDT)

<lsl>vector vCoefficients = <0.008906,-0.049831,0.088967>; float fAdjust = vCoefficients.x * size.z * size.z + vCoefficients.y * size.z + vCoefficients.z; llSetLinkPrimitiveParamsFast(linkNum,

   [PRIM_POS_LOCAL, (pos + <0.0, 0.0, 0.4> - (llRot2Up(rot) * size.z * fAdjust)) * localrot + localpos,
    PRIM_ROT_LOCAL, rot * localrot]);</lsl>

I see you mind reading abilities haven't diminished (I contemplated suggesting the tests you have done, decided to go to bed instead). Any reason not to use parentheses? It looks like something that could get optimized to an a series of FMAs (by the VM). -- Strife ^{(talk|contribs)} 21:33, 14 July 2013 (PDT)

<lsl>vector vCoefficients = <0.008906,-0.049831,0.088967>; float fAdjust = ((((vCoefficients.x * size.z) + vCoefficients.y) * size.z) + vCoefficients.z) * size.z; llSetLinkPrimitiveParamsFast(linkNum,

   [PRIM_POS_LOCAL, (pos + <0.0, 0.0, 0.4> - (llRot2Up(rot) * fAdjust)) * localrot + localpos,
    PRIM_ROT_LOCAL, rot * localrot]);</lsl>

Yeah, I thought about optimizing it a bit after I posted it, but decided to leave it unoptimized here so the path from the current function to this change was clear, for demonstrability purposes. Besides, I had to leave some room for it to be Strifed™. :P Talarus Luan 15:17, 17 July 2013 (PDT)

I appreciate the gesture :p and I'm not as bad as I use to be. I'm not going to optimize out fAdjust, it's more readable this way. This is more for myself later as my memory is crap, the reasoning behind using llRot2Up is that it solves the pesky problem of the quaternion not having a magnitude of one. While the following isn't optimal, it is cool. -- Strife ^{(talk|contribs)} 00:00, 18 July 2013 (PDT)

<lsl> size.x = (size.z * (size.y = (size.z * size.z))); float fAdjust = vCoefficients * size; </lsl>

Yeah, that is a nice way to represent it, for those used to the LSL representation for vector dot product. I'm a little less enthused about the size vector assignment chain, but that's just my general dislike for C value assignments and such. In my mind, I separate assignments from expressions, so seeing them mixed together causes a bit of a train wreck in my brain's lexical analyzer. :PTalarus Luan 10:00, 21 July 2013 (PDT)

I don't think anyone uses the LSL vector dot product. It took me three days to remember it existed and then I look up the syntax just to make sure I wasn't crazy (yes yes, I agree it's insane to think that looking up the syntax of an obscure feature is proof against insanity but I'm sticking to it, my cat agrees). I think a train wreck was my goal. -- Strife ^{(talk|contribs)} 11:13, 21 July 2013 (PDT)

Avatars Floating After Sit

The position of avatars will sometimes change, generally noticeable as a rise on the Z axis of perhaps half a meter - common triggers for this is typing or another AV sitting on the same object - though these are not exhaustive. Does anyone have a clue why this happens, and how to prevent it from happening? TaraLi Jie 21:14, 11 March 2012 (PDT)

Hmm, there are a few possible causes, but the main cause are the animations involved, so it's worth remembering that any animation overrider can potentially cause weirdness while on a sit-target, which is why most good ones can turn themselves off while seated. It's a bit difficult to describe specific problems with animations, but I think that sometimes it can be caused by animations that have a weird first frame, since it's used to calculate all the offsets etc. for the rest of the animation; normally this will be a neutral pose since you don't actually see it in the animation, but if it's something odd then it can mess with positioning. --
-- Haravikk ^{(talk|contribs)} 05:34, 12 March 2012 (PDT)

When I've had problems with this, the root cause has usually been that I've (or something has) inadvertently stopped an animation that's holding the avatar in place before starting another one. Because animations are all made differently, neither the animator with whom I work most of the time nor I have ever managed to figure out exactly what to avoid, but certainly when it happens to me, I always start debugging by looking very carefully at where I'm turning animations off and considering whether, in fact, I need to turn them off at all. Quite often, I find that simply turning off the default sit animation when my first animation starts, and then keeping the first animation going throughout, starting and stopping other ones over it, as necessary, solves the problem.

One "gotcha" is that stopping an animation and then immediately restarting it doesn't work. It confuses the viewer something horrible, and often leads to people floating in mid-air. Innula Zenovka 09:04, 12 March 2012 (PDT)

Sit Target 0.4m 'bug'

The notes say "rot affects the position of the sit-target in a buggy way way. To correct for the rot bug, simply subtract <0,0,0.4> from the position when rot is zero. See example below."

But the example script adjusts z by 0.4m when rotation is NOT zero. <lsl> if (rot!=ZERO_ROTATION) pos -=<0,0,0.4>; //here is the work around </lsl>

Which should it be?

I've just been doing some tests without any 0.4m adjustment, and I am unable to observe any difference in my z position whether rotation is zero or not. Has something changed? If so, wouldn't the change screw up some furniture? Omei Qunhua 14:09, 16 March 2014 (PDT)

You are right, there shouldn't be a test there. My understanding is that you always need to subtract 0.4 from z. Changing it would screw up furniture. -- Strife ^{(talk|contribs)} 21:02, 16 March 2014 (PDT)