NEW LSL llSetAgentRot(float radians );
in progress
Neon Zombie
Currently, we have no way to rotate the avatar. This function would rotate the owner of the script on the Z-axis and would work as an attachment. With this, we can rotate the avatar to the surface normal of a wall, table, or other avatars without the need to use RLV functions that manipulate the camera or having to sit and unsit the avatar. This would allow for things like wall climbing and a host of other useful applications.
rotation RotNormal(vector _normal){
vector vLeft = llVecNorm( _normal % llRot2Fwd(llGetRot()));
vector vFwd = vLeft % _normal;
rotation rRot = llAxes2Rot(vFwd, vLeft, _normal);
return rRot;
}
wall_climb()
{
vector scale = llGetAgentSize(owner);
vector vStart = llGetPos() + <scale.x/2,0,scale.z/2> * llGetRot();
vector vEnd = vStart + <0.25,0,-1.0> * llGetRot();
list CN = llCastRay(vStart, vEnd, [RC_DATA_FLAGS,RC_GET_NORMAL, RC_MAX_HITS, 1]);
float FW_Dist = llVecDist(vStart,llList2Vector(CN, 1) + <scale.x/2,0,0> * RotNormal(llList2Vector(CN, 2)));
/*
Set the position and agent rotation to the surface normal of the detected object.
*/
}
Log In
Tapple Gao
I finally tried this in my own script. and my opinion is, wow, this sucks way worse than rlv @setrot. Every time it fires:
- it closes any open right click menu
- It resets alt cam
- It deselects any selected prims
rlv @setrot doesn't do any of that
llSetAgentRot has a slightly smoother camera jump than @setrot, but, wow. I am not using it in my passive follower script in this state. being able to cam around without worrying too much about your avatar is the primary use of a follower
Tested in two viewers on Linux:
- Second Life Project Lua Editor 26.1.0.21525310258 (64bit)
- Firestorm 7.2.2 (79439)
maybe it would be ok for active steering in my AO, so that I can actually llTakeControl(CONTROL_ROT_RIGHT | CONTROL_ROT_LEFT) instead of watching llGetOmega. Will try that later. Because in that instance, camera will already be behind the avatar, and edit windows deactivated. Well, unless the third party viewer option to "reset camera on movement is off". llSetAgentRot does not play well with that setting in firestorm, unlike rlv @setrot
Signal Linden
marked this post as
in progress
Neon Zombie
As of Second Life Release 7.1.12.12999043440 (64-bit), which is labeled as ForeverFPS, you still cannot see the visual effect on the avatar.
I can see it rotating the hitbox but not the agent.
The Lindens were asked about this at the most recent content creator meeting, but no answer was given. As far as we know, this is still on the development branch.
Signal Linden
Neon Zombie: Yeah, it looks like this got auto-closed when the associated github issue (not visible) was closed. I'll update accordingly and we'll probably need to disable this automatic status updating feature for now.
This post was marked as
complete
Nexii Malthus
Does this mean the viewer side has been implemented? I know there is a feature freeze in place currently for viewer development while work is focused on performance. So does this mean that viewer side is pending for integration or already released?
Nexii Malthus
The scripting side of this has been implemented now in the 12th Nov simulator release as
llSetAgentRot
: https://releasenotes.secondlife.com/simulator/2024-11-12.11802108395.htmlHowever note that this still needs a viewer update to display the updated rotation correctly.
---
Nonetheless some notable behaviours can be noted for what it will be like when applied to older viewers once the update is available:
When applied to oneself you can notice your avatar shifting as your server-side representation or physical hitbox is rotated sim-side. However your avatar still faces forward / as normal visually without any change to its rotation.
When applied to another agent instead it
can actually
visually affect them to rotate. However not always, I suspect that accounts or bots on radegast viewer require the avatar to have had some physics movement recently, if the avatar had been physically rested the rotation updates seem to be ignored.The latter could possibly be a bug, since it feels like it seems to be almost working? The former behaviour is probably what mostly needs a viewer update to work correctly.
So as of so far:
* You can't see rotation updates applied to own avatar, however you may notice side effects such as your avatar shifting due to sim-side physics. A future viewer update should remedy this
* Others can see your avatar rotating
* Rotation updates do not seem to be instantenous? There may be some kind of easing or transition time built-in, but can't fully confirm at this stage without the viewer update in place. This may be undesirable in applications where precision or certain speed is needed for finetuning or manoeuvres
* You need a timer that is at least around ≤0.3s to provide continuous smooth rotation control. Anything slower than that makes the in-built easing/transition curve quite obvious (the starting / stopping or the slowing down / ease-out of the avatar rotation updates vs. continuous/directed rotations; Kinda like a traffic jam vs smooth traffic with little to no braking)
* Rotation updates may affect avatars logged on unconventional viewers differently. This is something important to caveat for the future especially of avatar NPCs/bots that are Scripted Agents rather than animesh
Thornotter Resident
I'm in full support of something like this.
The function could require a new permission - e.g. PERMISSION_CONTROL_MOVEMENT. That would allow it to be used within the existing permission system (upon request) or within an experience.
I also suggest that the implemented function start with the main verb - e.g. llRotateAgent - which would imply a smooth rotation with use of the turning animations rather than an immediate edit-like 'snap' to the new rotation.
Neon Zombie
Thornotter Resident Do not under any circumstances lock this function behind experience, a permission request to act on another agent would be fine but do not lock it behind experience or this function might as well not exist that would make it useless.
Rohacan Hirons
I did the same request many years ago for the exact same reason. I made a demo of my climb system and remember Andrew Linden's comment "wow this is what people want!".. two weeks later "Sorry this is too much work, we should update server and viewer side." xD
I totally agree we need this, not only for climbing of course.
Kore Jardberg
Long overdue.
Signal Linden
marked this post as
tracked
Kadah Coba
For accessibility reasons, the function should not instantly snap the avatar to the new rotation. Sudden view port changes are problematic for many of us.
Otherwise, this functionality is overdue.
Nexii Malthus
Kadah Coba avatar rotation and view port are not the same thing. If you strafe left or right the avatar rotates into the direction of the strafing movement but it doesn't turn your camera 90 degrees, so I think of this function in the same way. I don't think llSetAgentRot should affect the camera whatsoever unless it has camera permissions. On the other hand there may be cases where lack of instant snap can cause various problems, such as the avatar lagging behind coordinated movements, making it feel and look sluggish or inaccurate, which might not be great for accessibility either in terms of establishing the cognitive context.
However it would be useful to be able to have the viewer be able to move the camera in the direction of intentional scripted movements such as for an auto pilot system, but that would have to be a separate feature to implement it in an accessible way, or the existing camera permissions and camera controls may be able to do that already.
Load More
→