The recent TPV Policy changes brought with them the news that the functionality of llRequestAgentStatus, popularly used to obtain someone’s actual on-line status would be changed at some point in the near future as a matter related to users’ privacy.

The ability to determine someone’s on-line status has been the subject of debate for some time now, as evidenced by JIRA SVC-4823.  The JIRA itself has received a lot of attention since the news on the TPV Policy changes broke, which both highlights the level of concern where potentially legitimate uses of llRequestAgentStatus is concerned, but conversely doesn’t help the Lab clearly understand all cases where this is so.

Yesterday, Oz put on a request on the JIRA, thus:

Everyone…. I don’t know if this will help or not, but I’m going to give it a try and see….

We hear what you’ve all said, we understand the issues, and we’re going to discuss what we can and should do about them.

Nothing is final.

We appreciate that Phoenix is moving appropriately to remove the privacy violation from their next release, and hope that they’ll do that soon, but we understand that these things take time.

In order to help us to have a better understanding, I appeal to the many of you who are posting messages that essentially say “I agree – this will be bad for me too” as opposed to describing a specific use case not already described here (and thank you to the many posts that have done a good job describing use cases): please stop with these “me too” posts – they just make it harder to read the full stream (and yes, I at least am reading all of every comment). We know that for every use case there are many users… we don’t need each of them to post something

This is a fair and reasonable request, and while it is understandable the many want to add their name to one or more instances where the function does have a positive use, it’s also essential the LL get a fair chance to establish the how and where and what in terms of what needs to be done in order to avoid causing undue upset or pain in altering the functionality – if indeed this happens.

If you do have a potential user case that hasn’t been listed in the JIRA (or perhaps hasn’t been fully explained), then now is the time to help Linden Lab help you by providing a clear and concise explanation of how the function is used and how altering it could be detrimental to the SL experience. If you just want to add a “me too” comment, without specifics, I would encourage you to consider Oz’s plea and resist the temptation, so that LL stand more of a chance of sifting through the feedback and properly taking all they need to understand into account.

Again, you can reach the JIRA to add your examples by clicking here.

Update April 2012: The flight limit has been raised to 5,000m. 

Nalates Urriah keeps her finger on the pulse where all things server and scripting are concerned, as well as keeping an eye on other technical aspects of SL. Today she reports on server scripting, and carries an interesting little nugget on flight limits.

Apparently the Lab is considering whether or not to raise the current flight “ceiling” for unassisted avatars. As we’re all aware, if you fly without any kind of scripted  / client-side assistance, you’ll start slowing down from around 165m onwards, and come to a complete halt at about 180-190m. To go any further, scripted / Viewer assistance is required.

I’ve no idea why this limit was set – there has to be some solid reasoning for it in the depths of time. However, for as long as I’ve been involved in SL, build height has (I think, my memory is getting fuzzy in some areas) always been at least 768m (prior to being raised to the current 4096m), so the brake-point at 180-190 to “natural” flight does seem rather arbitrary.

Simon Linden apparently puts forward an argument that raising the limit will shoot people using flight assistance systems into orbit. I’m not entirely sure I follow his logic. There is a plethora of flight assistance alternatives available across SL, from the ubiquitous Flight Feather or Flight Ring of old, through to fancy backpack attachments to options built-in to a range of tools such as Em Dash and Mystitool. Many of these include accelerators which allow the rate of vertical ascent to be adjusted by the user – some of them quite ridiculously so. Yet none, so far as I’m aware, have resulted in people ending up in orbit on the click of a button / key, even when employed at altitude. So would the removal of the current limit suddenly cause these tools to behave any differently?

It’s not even as if flight assistance tools are required, either. Firestorm bypasses the current limit by adding flight assistance to the LSL bridge. Milkshake (prior to being withdrawn from public use) demonstrated that it is possible to override the flight limit directly from within the Viewer without even resorting to any form of bridge attachment. Both of these capabilities tend to make the current limit somewhat pointless.

As it stands, and with maximum build height sitting at 4096m, it would make sense for LL to lift the limit to that altitude (as I’m sure they are only too aware). This would not only make mobility at altitude easier for all (especially around the more expansive higher-altitude builds where flying is allowed), it might even lessen people’s dependency on attachments, be they wearable or HUDs (not that this is a critical issue, given the threatened script limits project is now apparently shelved).

It’s not what I’d call a priority in any way shape or form, but it would potentially make people lives a little bit easier in-world; so if LL are considering the move – I for one say, “go for it – and push it to 4096!”

With thanks to Nalates Urriah