NEW LSL llSetAgentRot(float radians );
in progress
dantia Gothly
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
Signal Linden
in progress
dantia Gothly
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
dantia Gothly: 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.
dantia Gothly
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
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.
Otoa Kiyori
It would be nice if turn speed can also be adjusted with something like "tau" (also with reasonal minimal rotation speed) ... with sudden rotation change, the camera following might switch posittion too fast and... it can shake screeen (if the script with this new function is changing avatar rotation quickly between two different angles). This can be simulated with RLV @setrot function.
dantia Gothly
Otoa Kiyori The way the RLV function hijacks the camra both feels bad and its slow. if you run the function to fast it breaks down. it is also only avalible in those clients that support it only works for some and not other users. The Tau suggestion is a good one and I could see that being useful for easing into the rotation.
Load More
→