Voted

It would also be useful to be able to get a rotation heading directly from an AV. Currently I can do so by getting a rot from an attached HUD, but it would be nice to not need that.

I think this should be implemented in 2 ways. As in, both of them.

1. llLookAt etc. Should work with PERMISSION_TRIGGER_ANIMATION. Since it is, to uneducated eyes, a form of animation.

2. llApplyRotationalImpulse . Should require no permission, but not work in no push zones. Or on an avatar who's seated/non phys

Why?

Because all the calls needed already exist, they are all simply rotational variants of calls that can move avatars around linearly, or unimplemented parameters to calls that can move avatars linearly. For someone to use these for griefing they'd have to convince you to attach a prim to yourself, and once they do that the script's already able to orbit you, accelerate you laterally fast enough that you lose connection to the sim, and so on. Being able to rotate you as well adds no new danger, and the requirement that the prim be attached to you means you can't be shot or bombed into a spin.

...but of course, I hardly don't see how this can be griefer's way to abuse people. Maybe in a prank joke for wearing something.

I'm all against permission trigger.... they are too much of a hasle to script.

simply have the permission auto granted for attachments like animation permission. And unattached objects have to ask.

No permission needed.

For a hugger you can use llMoveToTarget to position your agent in front of the other agent. llGetObjectDetails will give you the other agents rotation so you can work out where to move to.
The only thing missing is being able to correctly rotate yourself to face them.

The same goes for any other situation where you need to place your avatar at a location and facing the correct direction.

The only way to do it now it so rez an object around them and have it bump into one side of them to turn them. Hardly accurate, and not very friendly to anyone else who gets in the way.

I Vote yes.

Darling.

Though it should be noted that agents only turn on one axis normally (the z axis). The other two axis are kept locked. Should the other axis be unlocked for these functions? Or maybe we should have a special avatar turning function where the x & y axis can be locked or unlocked by a boolean.

If you're standing and unprotected, there are plenty worse things someone can do to you already. Spinning doesn't add any problems.

I voted too.
Just my vision :

• tchat allow everyone to tell shit to others, why not break it too ?
• gestures, llPlaySound(),... allow everyone to make horrible sounds, why not break llPlaySound() and gestures ?
• some people kills other people... Oh just break humanity, it's a simpler way to fix it XD
  -....

I don't understand why llPointAt() is more a problem that other way to piss of people ?
If your wear an object that make you crash with spinning too fast, relog, quick depos it and make a report

(sorry for my poor english... hehe, break me too )

Glad you asked.

You request permissions: PERMISSION_MOVE_AVATAR.

When permissions are granted, you treat the avatar like any other physical prim. llRotLookAt() would give the desired rotation control. llMoveToTarget() would be essentially the same as 'Go To...' in the pie menu. llSetPos() and llSetRot() would be useful for less realistic simulations. Ignore X- and Y-axis rotation information; use Z only. Ideally, physics commands would replace current flight enhancement techniques.

One downside for the accessibility application is that the user of the script would have to give permissions each time a HUD is worn, eg. Policies could be implemented much like with permissions for other HUD apps, or with chairs that always get permission to animate. Glad I don't have to iron all that out just now.

http://www.seeingwithsound.com/

anyway, back to the topic, how do you propose llSetRot and such would work when the object isn't an attachment? I think it would be better to have new commands specificly for rotating the avatar, physicly and not (of course only when permission is granted, and for attachments permission could be auto-granted like how it happens with some of the other permissions)

@Cinco: I don't think we need any further permission requests. The ones we have are burdensome enough and llMoveToTarget() works quite well now without crippling it. Your suggestion would in fact break all existing flight assists, among other things.

Several individuals and groups in Second Life are working on scripts that make it easier for people with disabilities to use this immersive environment. However, Linden Scripting Language has some inherent limitations that the scripters, and those who use the scripts, must somehow overcome.

One of these is that LSL cannot easily change the direction that your avatar is facing--your "rotation". This was possible at one time, but it is no longer available.

Why is this important?

Someone who is Blind or Visually Impaired can check to see which way they are facing, but if they wish to face a particular direction, they must guess at how long to hold down the arrow keys. It is possible to set a "target" rotation that will notify you when you reach a particular facing, but it is still very easy to overshoot. So, the "simple" act of turning to face a doorway or to face someone with whom you are speaking may not be so simple for them.

Someone with motor impairment that affects fine motor control may likewise have difficulty turning. Imagine directing your avatar's facing by saying "Turn left" or "Turn right" instead of using your keyboard. This is just one example of how someone with motor impairment might use Second Life, of course.

Facing a specific direction in a smooth and realistic manner could be difficult in either case. If you know that Joe Avatar is at 47 degrees from your position, you could issue a command to "face 47 degrees", and your avatar would be "looking" at him. This makes social interaction smoother and more realistic, as well as making travel and interaction with objects in-world easier.

The desire to have Avatar Rotation returned to LSL is not limited to the Disability Community. Others have already begun this effort.

http://jira.secondlife.com/browse/SVC-56

If you log in to this site with your SL Username and Password, you can vote for this issue. Voting does not compel Linden Lab to address our concerns in the way that we desire! However, they did create this site because they want user input. They do pay attention to these votes, and they tend to focus on those issues that receive the highest number of votes.

Please, consider adding your vote.

Thank you,
Talvin Muircastle

Still, they could be used together. For example, my wife, Dianna Muircastle, has been practicing with vOICe to open the door to her office. From the center of her office (which is her home position) it is almost due SouthEast.

She has tools already that tell her which way she is currently facing, and that tell her which way she needs to face to have the door directly in front of her. The problem that this feature would address is making those two numbers match.

The first try to open the door took her close to 30 minutes. Now she can manage it in about 2 minutes on average.

Think about that: taking an average of 2 minutes just to get yourself lined up properly to open a door that is in the place where you wake up every time you log in to SL.

If she could change her avatar facing with precision, I think that could be shaved down to seconds. Door is at 5 meters at X degrees, so type /3 face X, /3 go 5, double-check to make sure she is lined up properly on the door, and click.

EDIT: I double-checked this with Dianna. She corrected me: 2 minutes is a GOOD day, not an average. 5 minutes is more average now.

If there's a missing API to set the Z rotation of the avatar, add a new call.

Think of your viewpoint with your camera behind you... and how even if things push you around, even if they make the avatar appear to rotate momentarily, you never experience the camera turning around. If it happened I bet it would grab your attention!

I'd like to hear from Linden Lab as to the feasibility as well as impact. It is not like avatar animations as those are done client-side. Controlling the head, I'd imagine, yes. Controlling the body's rotation? Not so sure.

Those issues aside, if someone knows where the JIRA for llMapDestinations()'s failure to use the third rotation parameter is, could you link it to this one? Ditto for anything regarding sit/stand's unstable behavior vis-a-vis avatar rotation. They're all related. I'm guessing that fixing one fixes many if not all of them.

As for "Fixing Sound and Voice Chat", I have heard no complaints about either. Nor do all Blind people use Voice Chat.

If you are interested in learning more about these issues, please contact me in-world for a demonstration of some of the LSL-based technology that Blind people use to navigate Second Life and an explanation of how this will fix a Major problem for them.

Changing the priority on this issue because a handful of users might need it to navigate seems like overkill. The same madness that led my former boss at the Registry of Motor Vehicles to force me to make the website accessible to the blind "in case they needed to renew a driver's license." I don't know what drugs they feed government decision makers, but they're bad ones.

and I imagine that with the right settings (perhaps a custom Windlight sky/lights, or perhaps some tweaking of the rendering system itsel)f, Second Life could become even easier for the vOICe beginners than RL

I don't think the fact people with disabilities have just a bit more dificulty than the rest of the people with aiming their avatar after the same amount of training justifies bumping up the priority here, in RL it isn't uncommon for blind people not stare or face the same direction a sighted people would in a given situation, and people with motion related disabilities depending on the severity can only turn and aim themselves with the help of others. But many others use joysticks or other types of input devices to move and I don't see why that approach wouldn't work with SL as well

it should also be possible to use AutoHotkey combined with a purposely made hud to assist with doing certain movements in SL

I don't think this ability is any more important to people with disbilities than it is for the rest, what is needed to overcome the lack of this feature is just about the same for both types of people, being blind is no excuse to suck at videogames, haven't you heard about that guy that had his eyes removed when he was a kid? I don't mean to offend anyone, what I'm trying to say here is that I believe the difficulty some people report with aiming themselves is just lack of practice, if they had been practicing using these type of controls for a similar amount of time as the rest of the people they would probably turn just about as easilly, gotta play more, and "watch" more other people doing it as well with whatever means they got avaiable

As for the classification as "Major": It was set to Major when I first got here. This topic has been up since 2007, reopened at least once, and set to Major by someone who presumably had no knowledge of the disability issues. Over 150 people have voted for it since without feeling it needed a downgrade.

The person who did downgrade it cited that they wanted other things first as a reason. JIRA does not include a "vote against" option: if you want something else first, go vote for that instead! Nor is arguing against the interests of People with Disabilities going to get very far, either: one survey shows that as much as 20% of the SL population self-identifies as having a Disability of some sort, and we are working to bring more in. We have as much right to have our voice heard here as anyone else.

As soon as the downgrade occurred, I reset it to Major. If you feel I abused the system by doing so, I suggest using the existing grievance channels already in place.

I think that's it's pretty shameful of you to use the disabled as part of your PR for Second Life, yet you don't even have the courtesy to assign someone to look at this feature. Despite the major benefits to a large minority of your community (I have no idea just how many of those 20% of physically disabled customers would directly benefit) and a general benefit to the rest.

But then, the company is not about being honourable is it?

C

if you've not come across the word honourable before, here's the definition:

Adjective

honourable (comparative more honourable, superlative most honourable)
Positive
honourable

Comparative
more honourable

Superlative
most honourable

1. worthy of respect

All of the assistive tech that I am aware relevant to this is attached to the Av.

*(But if you know of a reason, please share!)

perhaps simply allowing avatar rotation along the Z axis to be physical would work perfectly, for objects not attached the angular impulse part of llPushObject woudl do it, unless the land has push completly blocked (instead of just weakened), and attached objects would use the the physics commands that affect rotation on the prim that run the command, push doesn't need permission, and nor those the translational phys commands that also work on an avatar if run from an attachment

edit2:gonna try to make it less mangled without having to have horizontal scrolling

edit3: I should've RTFM to start with, now it should look good on the page (also the preview button was underused,sorry). I've managed to make everything looks right except there is no indenting, and it will look mangled by email (without the pjira rendering engine), I've just tested and copying the stuff between the /////////s (after rendered by pjira) and pasting back into SL works just like the original, if indentations are really important for you, or you don't wanna come to pjira and copy the text from here, you can use the original one, the only changes are presentation and a couple of typos

/////////////////////////////////////////////////////////////
//HOMING AVATAR proof of concept
//Originaly by TigroSpottystripes Katsu

//do whatever you want with this code

//2d topology only, no jumps nor flight requirements nor obstacles taken in consideration

//tested only with Emerald Greenlife viewer with Restrained life functionality enabled

//too simple, doesn't do any checks nor anything, just the basic algorithm to do the job and any extra code necessary to make a working proof of concept

//How to use: place the script on a prim you own, set the key of the target bellow, save the script, and start holding the forward key till you hit the target

//key of target avatar or object to home on
key target = "25e31276-cd5f-ae40-58bc-b9174ce540a5";

default

{

state_entry()

{

llSetTimerEvent(0.2);

}

timer()

{

vector tpos = llList2Vector(llGetObjectDetails(target, [OBJECT_POS]),0); //target position, if going to specific coordinates instead of going after an object or avatar, replace everything after the = sign and before the ; with the vector of the destination

vector opos = llList2Vector(llGetObjectDetails(llGetOwner(), [OBJECT_POS]),0); //owner position, used to calculate the angle to face the target position

float ang = -llAtan2(tpos.x-opos.x, tpos.y-opos.y)+ PI_BY_TWO; //angle calculated based on relative position of the target to the owner, for some reason it's 90 degrees off, PI_BY_TWO==90 degrees

llOwnerSay("@setrot:" +(string)ang+"=1");//sends the command to set the rotation for the client to process, needs Restrained Life functionality

}

}

//////////////////////////////////////////////////

According to the guidelines, "Critical" is for "Generally, most crashes (particularly if they're easy to reproduce and affect many), content loss, significant memory leaks, greatly reduced performance, etc."

"Major" is for "Major loss or impairment of function, including rarer crashes."

While I obviously consider this to be important, it is not at the level of "Critical" in my opinion.

As this question of Priority has come into question (and contention) more than once in recent memory, I ask that a Linden settle the matter.

I think for new features the best thing to do is try and rate it by how complex the feature is, as the number of votes should express the desirability/demand for the feature.

In this case the issue probably shouldn't be above normal, as it isn't likely that hard to implement. The main concern with it (and its derivatives) is that if we change rotational functions to affect avatars, then it could have unforeseen effects, for example in scripts that currently have these functions. Currently their rotational element will do nothing, but if it's suddenly activated what impact could that have? Some things could break as a result.