Last week’s Monday was a holiday and there was no User Group meeting. This week Kelly Linden held his regular meeting. The recent policy changes for Third Party Viewers affect the LSL function llRequestAgentData(). So, this was a big topic of discussion.
The function currently returns your online status. It does not bother with permissions. So, you can check the online status of anyone. It is how stalkers find out if their prey is online. Obviously it gets used for griefing. The complication comes from legitimate uses of the function.
One legitimate use is for magazine and other subscriptions services. Rather than blindly send to everyone on the list the systems can check to see if a user is online and if so send the item. This process has recently taken a hit because the function llGiveInventory() was recently used to crash the backend servers. The result is a new throttle on the function. This has hit all the subscription and updater devices. To stay under the throttle limit llRequestAgentData() is used to reduce the numer of items that need to be sent at any given time.
Some think the loss of llRequestAgentData() will increase the load on the asset servers as these subscription devices blindly send to the entire list. Of course checking the online status hammers other servers. So, it is hard for we mere users to say which is creating the bigger load.
This function is going to change in the next 2 to 4 weeks. That’s an educated guess. It may take longer. It won’t be any sooner than 2 weeks.
The function will always return a false value to you if you write, compile, and use a script with that function to find out whether I am online or not. However, if I write the script and give it to you, it will work. The function will return the correct online status information for the script creator or owner.
So, all those signs that show if someone is online; customer service reps, escorts, and etc. will stop working. Whoever is managing the prims those scripts are in will have to get a script from each of those people to get them working again.
If you know people that are using online status signs and devices you may want to help them out by contacting them and showing them this article.
Since anyone with a script made by you may be able to use it to check your online status, you will want to be careful about giving people MOD OK scripts you have made. Especially full perm scripts.
It is going to be much safer to distribute scripts as text in a note card.
Until we see the changes in action we won’t know whether a recompile of a script will clear the ability of llRequestAgentData() to correctly return your status.
Reasons for Changes Now
Many are speculating on why the change is being made now. There is an apparent reason. As the JIRA has been triaged and server versions updated cleanup work was done, it’s still in progress. Many of these privacy issues were coming up. Rod at the last SLCC said a few words about having some plans in store for griefers. All of this has been coming together for months. About 3 months ago the TPV Dev’s (with Non-Disclosure Agreements –NDA) knew that viewer tags were going away as a privacy issue.
So, some of these issues have been in the works for a long time. They eventually they have to see the light of day. Now are the days.
The JIRA is full of legitimate user cases for use of the function. The result is a post by Oz Linden in the JIRA:
Oz Linden added a comment – 27/Feb/12 12:04 PM
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.
If you have a legitimate use for the function as it is now, check the JIRA to see if it has been included. If not add your use. As OZ said, this is going into consideration and its going NOW. So, add your input while it can do some good.
In the discussion in Kelly’s UG he said, “I have read *all* comments on the jira. I have also read all threads I could find on the forums, and all related mails to the mailing lists. I can tell you that I have meetings this week to further discuss the design and implications of this policy based on feedback we have received.” So, the Lindens are aware of what users are saying and the use-conditions affected by changing llRequestAgentData().
SCR-4 – Unbundle PRIM_* rules for llSetPrimitiveParams and similar functions to allow for individual parameter settings for all possible parameters. Kelly says, “Not currently being worked on.”
SCR-79 – llMatchGroup() – Checks if an object or agent is active in a specified group. Kelly says there has been more talk about SCR-79. I suspect it’s still in the discussion stage and will be for a time.
SCR-15 – Add flag parameter [vector slice] to llSetPrimitiveParams PRIM_TYPE flags PRIM_TYPE_BOX, PRIM_TYPE_CYLINDER, and PRIM_TYPE_PRISM. Kelly says no talk about SCR-15.
llGiveInventory() Throttle Changing
Going to Blue Steel, according to Kelly, is a change that affects the llGiveInventory throttle. The throttle rate is being eased to allow twice as many gives as the previous setting.
The current throttle rate is 2500 gives per 30min and that will be going up to 2500 per 15min in the next roll to the Blue Steel RC.
More tweaks are coming to this function. But, those will not show up until some other throttles are in place. I think this suggests a higher rate limit may be allowed. The Lindens are aware that there is a mailing list need. I have hints they are looking at how they can handle those needs.
The llSetRegionPos() function is said to be as accurate as llSetPos(). A difference is llSetRegionPos() will return a success/fail flag. Understanding the 0.1m final location proximity is important. Making small moves of less than 0.1m will likely return a fail value.
But, llSetRegionPos() is more precise than 0.1m. 0.1 is just the tolerance limit for success of failure.
This function is intended to replace WarpPos(), a sub-routine function one can include in their scripts. It was created to handle movement before llSetRegionPos() was added to LSL.
Linden Realm Tools
Charlar Linden has a few worlds on the coming beta testing of Linden Realm Tools. The initial testing will be on ADITI. At this point Charlar thinks is will be open testing, in the sense that no NDA will be required. Also, we may see a beta testers’ group form this week.