Rotating an attached PRIM towards an avatar

[fastblock]

I researched and tested many hours without success. What I've done so far is to rotate a PRIM in the direction to an avatar,
so that the PRIM looks at the target avatar.

2 Solutions

a)
    // get the traget position
    vector targetPos = llList2Vector( llGetObjectDetails( KEY, [OBJECT_POS]), 0);
    llLookAt(targetPos,1,1);

b)
    vector startPos =  llGetPos();
    float distance=llVecDist(<targetPos.x,targetPos.y,0>,<startPos.x,startPos.y,0>);                  
    rotation rot = llRotBetween(<1,0,0>,llVecNorm(<distance,0,targetPos.z - startPos.z>)) * llRotBetween(<1,0,0>,llVecNorm(<targetPos.x - startPos.x,targetPos.y - startPos.y,0>));
    llSetRot(rot);

Both methods work great if the PRIM is on the ground and not attached to an avatar.
Now the tricky part, I need the same behavior when the PRIM is attached on my avatar (eg. on pelvis or center point, ...).
I know the above methods are not suitable for this case. I've tried a lot to adapt method b) for my needs using llGetLocalPos(),
llGetLocalRot(), llSetLocalRot() in combination with llGetPos() and llGetRot() but without success. My PRIM looks always in the wrong direction.
Meanwhile Im lost in this rotation jungle. Would be great if someone can help.

Edited December 23, 2018 by fastblock

[steph Arnott]

That is just an attached child prim.

Edited December 23, 2018 by steph Arnott

[chibiusa Ling]

7 hours ago, fastblock said:

I researched and tested many hours without success. What I've done so far is to rotate a PRIM in the direction to an avatar,
so that the PRIM looks at the target avatar.

2 Solutions

a)
    // get the traget position
    vector targetPos = llList2Vector( llGetObjectDetails( KEY, [OBJECT_POS]), 0);
    llLookAt(targetPos,1,1);

b)
    vector startPos =  llGetPos();
    float distance=llVecDist(<targetPos.x,targetPos.y,0>,<startPos.x,startPos.y,0>);                  
    rotation rot = llRotBetween(<1,0,0>,llVecNorm(<distance,0,targetPos.z - startPos.z>)) * llRotBetween(<1,0,0>,llVecNorm(<targetPos.x - startPos.x,targetPos.y - startPos.y,0>));
    llSetRot(rot);

Both methods work great if the PRIM is on the ground and not attached to an avatar.
Now the tricky part, I need the same behavior when the PRIM is attached on my avatar (eg. on pelvis or center point, ...).
I know the above methods are not suitable for this case. I've tried a lot to adapt method b) for my needs using llGetLocalPos(),
llGetLocalRot(), llSetLocalRot() in combination with llGetPos() and llGetRot() but without success. My PRIM looks always in the wrong direction.
Meanwhile Im lost in this rotation jungle. Would be great if someone can help.

llLookAt(llGetPos() + (TheirPosition + <0.0, 0.0, 1.0> - llGetPos()) / llGetRootRotation(), 3.0, 1.0);

Source : http://wiki.secondlife.com/wiki/LlLookAt

Second example down on the page

[fastblock]

5 hours ago, chibiusa Ling said:

lLookAt(llGetPos() + (TheirPosition + <0.0, 0.0, 1.0> - llGetPos()) / llGetRootRotation(), 3.0, 1.0);

Source : http://wiki.secondlife.com/wiki/LlLookAt

Second example down on the page

Thank you for your prompt reply. I know this example and have already tested it.
Unfortunately it doesn't work. What I've done: I've created a cube, pasted in the Wiki example, attached the box to my avatars skull and ran around another avatar. As soon the avatar is moving or rotating on which the PRIME is attached the PRIME does not look at the right direction anymore. (e.g. to the nearest avatar).
Did I forget something special? 🤔

Merry-Xmax!

[chibiusa Ling]

57 minutes ago, fastblock said:

Thank you for your prompt reply. I know this example and have already tested it.
Unfortunately it doesn't work. What I've done: I've created a cube, pasted in the Wiki example, attached the box to my avatars skull and ran around another avatar. As soon the avatar is moving or rotating on which the PRIME is attached the PRIME does not look at the right direction anymore. (e.g. to the nearest avatar).
Did I forget something special? 🤔

Merry-Xmax!

Hmm, weird. It works perfectly for me attached to pelvis. Does not matter where I move to the prim is always pointing at the avatar. Try it again but attach it to the Pelvis, double check the code you entered is the same etc etc 

[Qie Niangao]

So I don't want to be a spoil sport here, but see what happens with this script:

key tracked;
integer turned;
default
{
    state_entry()
    {
        llSensorRepeat("", "", AGENT, 95.0, PI, 2.0);
    }
    touch_start(integer num_detected)
    {
        llRequestPermissions(llDetectedKey(0), PERMISSION_TRIGGER_ANIMATION);
    }
    run_time_permissions(integer perms)
    {
        if (PERMISSION_TRIGGER_ANIMATION & perms)
            if (turned = !turned)   // toggle on touch
                llStartAnimation("turn_180");
            else
                llStopAnimation("turn_180");
    }
    sensor(integer total_number)
    {
        key newTracked = llDetectedKey(0);
        if (newTracked != tracked)
            llOwnerSay("tracking "+llKey2Name(tracked = newTracked));
        vector p = llGetPos();
        llLookAt(p + (llDetectedPos(0) + <0.0, 0.0, 1.0> - p) / llGetRootRotation(), 3.0, 1.0);
    }
}

In particular, watch how it behaves when touched (so with or without the "turn_180" animation), comparing that effect when attached to Avatar Center with the behavior when attached to Pelvis.

I imagine Skull is rather like Pelvis, only moreso. Animations aren't all as weird as "turn_180" but I think you'll see what's going on.

[Wulfie Reanimator]

To clarify what Qie is trying to point out, you cannot rotate an attachment towards an avatar if it is attached to anything besides Avatar Center. This is because animations are client-side only, which means that attachments (and LSL as a whole) don't know where they should be pointing if an animation (which aren't the same on every viewer) is changing them visually.

Essentially, this is all you need to logically do exactly what you want (with the same code expanded):
You can put this code anywhere you want the object to rotate, I tested this directly in a repeating timer event.

key id = "779e1d56-5500-4e22-940a-cd7b5adddbe0";
vector target = llList2Vector(llGetObjectDetails(id, [OBJECT_POS]), 0);
llLookAt( llGetPos() + (target - llGetPos()) / llGetRot(), 3, 0.2 );

key id = "779e1d56-5500-4e22-940a-cd7b5adddbe0";
vector target = llList2Vector(llGetObjectDetails(id, [OBJECT_POS]), 0);

vector origin               = llGetPos();
vector direction            = target - origin;
vector direction_in_region  = direction / llGetRot();

llLookAt( origin + direction_in_region, 3, 0.2 );

But note that getting the avatar's rotation will always be kind of inaccurate. llGetRot's wiki page states as much, and llGetRootRotation gives the avatar's rotation instead of the attachment's root. This same applies to llGetObjectDetails(llGetOwner(), [OBJECT_ROT]).

Edited December 25, 2018 by Wulfie Reanimator

[steph Arnott]

9 minutes ago, Wulfie Reanimator said:

To clarify what Qie is trying to point out, you cannot rotate an attachment towards an avatar if it is attached to anything besides Avatar Center. This is because animations are client-side only, which means that attachments (and LSL as a whole) don't know where they should be pointing if an animation (which aren't the same on every viewer) is changing them visually.

Essentially, this is all you need to logically do exactly what you want (with the same code expanded):

key id = "779e1d56-5500-4e22-940a-cd7b5adddbe0";
vector target = llList2Vector(llGetObjectDetails(id, [OBJECT_POS]), 0);
llLookAt( llGetPos() + (target - llGetPos()) / llGetRot(), 3, 0.2 );

key id = "779e1d56-5500-4e22-940a-cd7b5adddbe0";
vector target = llList2Vector(llGetObjectDetails(id, [OBJECT_POS]), 0);

vector origin               = llGetPos();
vector direction            = target - origin;
vector direction_in_region  = direction / llGetRot();

llLookAt( origin + direction_in_region, 3, 0.2 );

But note that getting the avatar's rotation will always be kind of inaccurate. llGetRot's wiki page states as much, and llGetRootRotation gives the avatar's rotation instead of the attachment's root. This same applies to llGetObjectDetails(llGetOwner(), [OBJECT_ROT]).

An attached object will be orientated where the wearer set it. This is not a script issue. What you are doing is a follower script.

[Wulfie Reanimator]

Just now, steph Arnott said:

An attached object will be orientated where the wearer set it.

Yes, thank you for pointing that out. The purpose for the script I posted is to make it not do that, as was asked by the OP.

[steph Arnott]

Just now, Wulfie Reanimator said:

Yes, thank you for pointing that out. The purpose for the script I posted is to make it not do that, as was asked by the OP.

It will not. You are just adding to a basic local set orientation which is pointlesss. An attachement is oriention is set under the object edit tool.

[Wulfie Reanimator]

31 minutes ago, steph Arnott said:

It will not. You are just adding to a basic local set orientation which is pointlesss. An attachement is oriention is set under the object edit tool.

With all due respect, I don't have the words to explain how uninformed you seem to be about almost everything you've posted about on this sub-forum since you started and I feel sorry for all the newcomers trying to learn things and being confused by your misleading statements and advice.

Before you dismiss people, and if you're going to tell people they're wrong, you need to start posting your own code and learn how to explain things in-depth. I don't think you're able to do that, but as long as you at least try to do it, people could correct you and... oh wait, you're never wrong. You've never been wrong. "Everybody else is wrong, end of."

I wish you were better, for the good of literally everybody, but you've proven impervious to criticism and feedback. I've nothing more to say.

Edited December 25, 2018 by Wulfie Reanimator

[steph Arnott]

1 minute ago, Wulfie Reanimator said:

With all due respect, I don't have the words to explain how uninformed you seem to be about almost everything you've posted about on this sub-forum since you started and I feel sorry for all the newcomers trying to learn things and being confused by your misleading statements and advice.

Before you dismiss people, and if you're going to tell people they're wrong, you need to start posting your own code and learn how to explain things in-depth. I don't think you're able to do that, but as long as you at least try to do it, people could correct you and... oh wait, you're never wrong. You've never been wrong. "Everybody else is wrong, end of."

I wish you were better, for the good of literally everybody, but you've proven impervious to criticism and feedback. I've nothing more to say.

With due respect you are posting arrant nonsense, Read what the OP stated. This is NOT a script issue. It is  object attached orientation which is done in object edit. This just proves that you are not in SL because this is basics. Now sir please stop wasting my time with nonsense.

[steph Arnott]

8 minutes ago, Wulfie Reanimator said:

With all due respect, I don't have the words to explain how uninformed you seem to be about almost everything you've posted about on this sub-forum since you started and I feel sorry for all the newcomers trying to learn things and being confused by your misleading statements and advice.

Before you dismiss people, and if you're going to tell people they're wrong, you need to start posting your own code and learn how to explain things in-depth. I don't think you're able to do that, but as long as you at least try to do it, people could correct you and... oh wait, you're never wrong. You've never been wrong. "Everybody else is wrong, end of."

I wish you were better, for the good of literally everybody, but you've proven impervious to criticism and feedback. I've nothing more to say.

So you can not admit you are totally WRONG then? I get that, you make a lot of false statements.

[fastblock]

Thanks  for all your hints. To illustrate it I've recorded two scenarios: unattached and attached PRIM (avi center). Not recorded but tested with fix avatar pose, makes no difference. As soon as the avatar is rotating the direction of the PRIM gets inaccurate.

 

Edited December 25, 2018 by fastblock

[Wulfie Reanimator]

1 hour ago, fastblock said:

To illustrate it I've recorded two scenarios: unattached and attached PRIM (avi center). Not recorded but tested with fix avatar pose, makes no difference. As soon as the avatar is rotating the direction of the PRIM gets inaccurate.

This is exactly what I was talking about earlier.

17 hours ago, Wulfie Reanimator said:

But note that getting the avatar's rotation will always be kind of inaccurate.

Unfortunately there is no fix for this that I'm aware of, LSL just can't get the exact facing of a free-standing (unseated and not in mouselook) avatar. (Ignore Steph, Qie and I have already explained the difference in behavior between different attachment points and you're doing the correct thing.)

Edited December 25, 2018 by Wulfie Reanimator

[steph Arnott]

15 minutes ago, Wulfie Reanimator said:

This is exactly what I was talking about earlier.

Unfortunately there is no fix for this that I'm aware of, LSL just can't get the exact facing of a free-standing (unseated and not in mouselook) avatar.

It is connected to the avitar and will just stay relative to where it was set. If the attatch point is say the head it will jerk around. The whole point is that the OP is not a script issue. If the object is multi prim it will get more sluggish as the count increases in keeping orientated. It is still not a script issue.

[fastblock]

2 hours ago, Wulfie Reanimator said:

This is exactly what I was talking about earlier.

Unfortunately there is no fix for this that I'm aware of, LSL just can't get the exact facing of a free-standing (unseated and not in mouselook) avatar. (Ignore Steph, Qie and I have already explained the difference in behavior between different attachment points and you're doing the correct thing.) 

Ok, I see,  there is no clean solution. Anyway thank you all for your support.

[Kyrah Abattoir]

Avatar direction isn't precisely synchronised client -> server, the client typically will not update its rotation until it turned a few degrees (unless you are in mouselook).

Edited December 31, 2018 by Kyrah Abattoir

[steph Arnott]

12 minutes ago, Kyrah Abattoir said:

Avatar direction isn't precisely synchronised client -> server, the client typically will not update its rotation until it turned a few degrees (unless you are in mouselook).

Not just the first. The rotation is dampened to stop erractic jerking. Nothing will update untill the limit is exceeded.