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)
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)
- 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>
- 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)
- 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
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)