llSetAgentRot() doesn't rotate hovering avatars
tracked
Lou Netizen
llSetAgentRot() seems to be functional with standing and seated avatars (given a viewer with support, etc.), but doesn't rotate hovering avatars.
Log In
Rohacan Hirons
Hi, I tested the function on Firestorm Viewer 7.2.2.79714 and the rotation is a bit odd when I’m hovering too. Sometimes it doesn’t do anything, and sometimes it rotates in two or more visible steps.
Even when standing it doesn’t seem very accurate yet. I was really happy to see this function become available, but at the moment its behavior seems quite close to the RLVa feature.
Rohacan Hirons
If that may help I wrote a quick test. I have no idea where you've implemented this feature in the viewer code then I wrote my own command using CHAT_TYPE_OWNER in llviewermessage.cpp xD. The viewer receive "SETAGENTROT:<x,y,z,w>" and call SetAgentRot() :
void LLVOAvatar::SetAgentRot(const LLQuaternion& rot)
{
if (!mDrawable || !mRoot || isSitting())
return;
stopMotion(ANIM_AGENT_BODY_NOISE);
LLQuaternion r = rot;
r.normalize();
// Forward direction of the avatar
LLVector3 fwd = LLVector3::x_axis * r;
// Project onto the horizontal plane
fwd.mV[VZ] = 0.f;
if (fwd.lengthSquared() > 0.0001f)
{
fwd.normalize();
// Yaw angle around the Z axis
F32 yaw = atan2(fwd.mV[VY], fwd.mV[VX]);
r = LLQuaternion(yaw, LLVector3::z_axis);
}
// Apply the rotation to the drawable / root
mDrawable->mXform.setRotation(r);
gPipeline.markMoved(mDrawable, true);
mRoot->setRotation(r);
mRoot->getXform()->update();
if (mEnableDefaultMotions)
{
startMotion(ANIM_AGENT_BODY_NOISE);
}
// Update agent / camera only for the local avatar
if (isSelf())
{
LLVector3 at_axis = LLVector3::x_axis;
at_axis = at_axis * r;
at_axis.mV[VZ] = 0.f;
at_axis.normalize();
gAgent.resetAxes(at_axis);
gAgentCamera.setThirdPersonHeadOffset(LLVector3(0.f, 0.f, 1.f));
gAgentCamera.setSitCamera(LLUUID::null);
}
}
It is a fast copy/past of existing code only for testing purpose, it works like a charm but maybe some parts are not really necessary.
Maestro Linden
marked this post as
tracked
Maestro Linden
marked this post as
under review
Maestro Linden
marked this post as
needs info
Maestro Linden
I'm not able to reproduce this bug with Second Life Release 7.2.2.18475198968 (64bit) on Second Life Server 2025-09-16.17777995432. Here's an example with the original example script:
I also made a version of the script which rotates the agent 90 degrees on each touch event. That script is also working consistently while the agent is hovering:
// Turn the touching avatar to face the same direction as the prim.
doRot(key agent)
{
rotation oldrot = llList2Rot(llGetObjectDetails(llDetectedKey(0), [OBJECT_ROT]), 0);
rotation newrot = oldrot * llEuler2Rot(<0,0,PI_BY_TWO>);
llSay(0, "Agent's old rotation is " + (string)(RAD_TO_DEG * llRot2Euler(oldrot))
+ ". Rotating them 90 degrees counter-cloudwise..");
llSetAgentRot(newrot, 0);
}
default
{
state_entry()
{
llSetText("Avatar Rotator", llGetColor(ALL_SIDES), 1.0);
}
touch_start(integer total_number)
{
if(llGetPermissionsKey() != llDetectedKey(0) || !llGetPermissions())
{
llRequestPermissions(llDetectedKey(0), PERMISSION_TRIGGER_ANIMATION);
}
else
{
doRot(llDetectedKey(0));
}
}
run_time_permissions(integer perm)
{
if (perm & PERMISSION_TRIGGER_ANIMATION)
{
doRot(llGetPermissionsKey());
}
}
}
Lou Netizen
Maestro Linden Behaviour of this script is identical to what I observed in the initial bug report: works while the agent is standing, has no effect when hovering. My first instinct was that I had some sort of movelock enabled, but I've double- and triple-checked that.
Sample output from three successive clicks:
[12:35 PM] Maestro test 20261117 1: Agent's old rotation is <0.00000, 0.00000, 130.07100>. Rotating them 90 degrees counter-cloudwise..
[12:35 PM] Maestro test 20261117 1: Agent's old rotation is <0.00000, 0.00000, 130.07100>. Rotating them 90 degrees counter-cloudwise..
[12:35 PM] Maestro test 20261117 1: Agent's old rotation is <0.00000, 0.00000, 130.07100>. Rotating them 90 degrees counter-cloudwise..
So, even the server seems to agree I'm not turning.
In one instance I had gotten a camera reset about 30 seconds AFTER touching the prim with the test script; however, my avatar didn't rotate.
We encountered this trying to turn avatars in an underwater environment (so, basically, everyone is hovering all the time).
Maestro Linden
Lou Netizen: Are you doing anything differently than the example video I uploaded to youtube? My minimal steps with the 90-degree-rotating are basically to:
- Stand on the ground
- Touch the script, accept permissions request
- Touch the script, observe llSetAgentRot rotated the avatar properly while on the ground
- Press 'F' to enter the hovering state
- Touch the script, observe llSetAgentRot rotated the avatar again
Lou Netizen
Maestro Linden OK, yes, it appears I am doing something different, and the results are now somewhat different too. This is looking more complex than I thought. The main difference in what we're doing MIGHT be that I have been zooming out so I can see my avatar and the test prim at the same time. But this time I got a "stuttering" hovering turn at first (where I got partial turns separated by some secords, each with a camera reset), and after that no turns at all. When llSetAgentRot() fires it seems to shake the camera back to default position (which is also true of turning an avatar manually). However, when it fails during hover, the camera stays locked on whatever I had been using as a "pivot" to manage the zoom.
I don't have a YouTube account; I have a video of the fail, but the max upload here is 8MB. I haven't used this service before: it says the video link is good for two days. If you can read the chat window, watch the object output and comments.
Maestro Linden
Lou Netizen: Thanks for the video. It's good to see exactly when it reproduces for you or not.
I tried it out a few more times with my test script, mimicking your video. I managed to get myself into the failure case exactly once. I'm not sure exactly _what_ triggers it - perhaps it has to do with the camera state or the locomotion state?
One thing I do see every time (but only while hovering) is the stutter behavior you describe. Looking at the message stream going down to the viewer, it seems that some of the ImprovedTerseObjectUpdate messages about the agent's movement alternate AngularVelocity between <0,0,0> and something like <0,0,8> or <0,0,6>. I think this stutter behavior is likely related to the intermittent cases in which the agent fails to rotate at all.
Lou Netizen
Maestro Linden That sounds like a reasonable hypothesis! Thanks for taking the time to look again. Intermittent bugs are the worst. :)
Lou Netizen
I included repro details and all other required information in this report, but Canny doesn't seem to want to display any of that. If I attempt to edit the bug to include it, Canny says "Uh oh, something went wrong." So, I think I've done all I can.