SL projects Update 22 (3) SSB/A issue update, upcoming viewer releases

Server-side Baking / Appearance

Yesterday, I reported on the SUN-74 issue (Apparent avatar skin and eye texture asset corruption with Server Side Appearance), which can impact users with avatars wearing modifiable skin and/or eyes and/or hairbase who enter (via teleport or crossing a region boundary) an SSB/A-enabled region while using a non-SSB/A enabled viewer (e.g. such as Phoenix or the v1.23.5 viewer) and leave them with a corrupted copy of the worn skin / hairbase or eyes. At the time I noted that the matter was under investigation by Linden Lab, and no decision had been made on how to handle it.

Whirly Fizzle demonstrates one aspect of the SUN-74 issue – on a non-SSB/A viewer, her MOD skin has turned black / invisible and her MOD eyes have turned white as a result of entering an SSB/A-enabled region and responding with YES to the given prompt.

Speaking at the TPV Developer meeting on Friday May 31st, Oz Linden provided an update on the issue and spoke more generally on the issue of the use of olfder (non-SSB/A capable viewers) going forward:

We don’t actually know what’s ultimately going to be done about that; that’s a subject of vigorous discussion that’s going on even as we speak, so we’ll see how that plays out. I think it’s fair to say that regardless of what happens with that particular issue … I will just make the observation that there are still people really, really old viewers [and] there is no way, no way at all, that we could even begin to test for compatibility back with all of those viewers.

As it is, as recently as this last week there were 1,665 different viewer version strings reported as connecting to the main grid (these include 151 versions of Singularity, 50 versions of Phoenix, 262 labelled as Firestorm, and so on). Some of these may be “one offs” self-compiled builds (which may or may not have the most recent updates to support something like SSB/A), but even so, given the overall number of viewer strings, it is understandable why the Lab view attempt to ensure so many different viewer versions were fully compatible with anything on the grid is a next to impossible task.

This does not mean that the Lab is going to ignore SUN-74, right now they are still investigating the problem and trying to reproduce it in a consistent manner (which is apparently proving difficult for a number of reasons, not the least of which is that some older viewers simply crash when attempting to repro the corruption). However, what it does underline is the need for people to upgrade to an SSB/A-enabled version of their preferred viewer sooner rather than later.

The reason for this is that very soon the Lab will start undertaking more widespread testing of the new service by enabling it across a number of regions across the grid. These regions may not necessarily be constrained to any of the usual RC channels, but could well be a mix of regions from all of the various simulator channels, making them harder to identify and avoid. This testing will be to gain greater insight into how the service stands up under “real avatar loads” – something which is impossible to carry out to any great depth on Aditi, as there simply isn’t the volume of users active there.

Once this more widespread testing starts, then it is entirely possible that users who remain on non-SSB/A capable viewers are going to encounter issues and problems beyond seeing grey avatars which the Lab are not going to address, simply because the issues can be resolved by a viewer update.

So the word really is, update, update, update.

LL announce “first set” of advanced creator tools now live

Yesterday, as I reported, Linden Lab rolled-out the first pass of the advanced creator tools across the main release channel for the grid. These are the functions that lead to an outbreak of griefing when they were first rolled-out on the Magnum Release Channel back in June.

Since then, the code has been revised – and now includes a “master switch” that allows Linden Lab to disable the functionality should anyone try to get up to mischief using the tools. The code was in fact enabled on both LeTigre and BlueSteel last week without major incident, and so the code was rolled-out to the main channel in an enabled mode on July 31st.

Today, LL has formally announced this initial release of the tools via a new blog post. This initial release comprises three new functions:

• llAttachToAvatarTemp (integer attach_point) — allows objects to be attached to your avatar / screen without any corresponding inventory record being created for the item, which will disappear on being detached or on disconnecting (teleporting) from the region in which it is active
• llTeleportAgent (key agent_uuid, string lm_name, vector landing_point, vector look_at_point) — this allows a script to teleport an agent to either a local coordinate in the current region or to a remote location specified by a landmark (the landmark must be contained within the inventory of the object using the teleport script)
• llTeleportAgentGlobalCoords (key avatar, vector global_coordinates, vector region_coordinates, vector look_at) – this will teleport an agent to to a specific point within a region, with the agent facing a defined direction (vector look_at) on arrival.

These functions should allow a range of new experiences to be created, some of which are demonstrated in the Linden Realms game, wherein the attachment option is used to attach the game HUD to avatars and the teleport options are used in conjunction with things like the rock monsters.

Linden Realms HUD (top left): attached using the full experience tools

The functions are also designed to be used with a new permissions system, which has yet to be rolled-out across the grid. This means that until the new permissions are rolled-out, some of the functions will not operate as transparently as they eventually will. For example, rather than something like a HUD being automatically attached to your avatar (as is the case with the Linden Realms game, which does use the new permissions system), you will be prompted to accept the object first (thus making you the owner) in order for it to attach.

It’s not currently clear as to when the new permissions system will be rolled-out, but with the “master switch” at their disposal, Linden Lab are confident that the kind of issues that marred the June RC roll-out can be avoided.

The official blog post includes a video from Torley.

Advanced user experience tools griefing update

Oskar Linden has provided an update / post-mortem on the recent bout of griefing that took place across the grid as a result of person or persons unknown abusing the advanced user experience code that was released onto the Magnum Release Channel two weeks ago.

The problem hit on Monday 4th June when the advanced teleport functions released to Magnum were used to teleport individuals or groups around the grid, with some people reporting they were teleported to the likes of The Cornfield, while others found themselves unexpectedly picked up and dropped into stores or meetings.

Linden Lab reacted rapidly to the issue, determining a fix for the exploit on the afternoon of the 4th (SLT) and deployed across the entire grid in a rolling restart that affected the main channel and all release channels.

The key points relating to the issue remain:

• The exploit came about due to a permissions restriction within the advanced tools not working as anticipated
• To prevent further misuse of the code, the advanced tools were also removed from the Magnum RC channel
• Both the code and the associated test plans have been revised and are being run through LL’s QA process to better ensure the situation of the 4th June is unlikely to be repeated when the code is rolled-out once more
• Coyot Linden estimates that the advanced experience tools project has been delayed by around 2-3 weeks as a result of these events
• LL are at this point in time unclear as to when the tools are likely to be rolled back out onto a Release Channel; the slot assigned to the tools on the Magnum RC has now been taken by other security issues in preparation for their roll-out to the grid.

One immediate outcome of the griefing situation is that the teleport capability has been revised so that when someone is teleported, the function will tell them the name of the owner of the object that teleported them (thus allowing any potential abuser of the system to be reported to LL via an Abuse Report).

With thanks to Nalates Urriah.

Genie out of the bottle: advanced tools capability used for griefing

Update 11th June: Oskar Linden has provided further feedback on this situation. 

Update June 6th: Oskar Linden has confirmed that the Advanced Creation Tools capabilities that were rolled-out to the Magnum RC channel will remain disabled until at least nest week, although no firm decision has been on re-enabling them.

Update June 5th 11:30 UTC: The rolling restarts completed at 03:39 UTC. At present, no further updates have been given on the forum post relating to the restarts, but this may change later during the course of today. Oskar Linden has reiterated that due to this rolling restart, there will be no main channel deploy today and that details on Wednesday’s RC deploys are still TBA. My apologies for late timing of this update; a small matter of real life prevented me putting my nose in front of the keyboard any sooner!

Last week saw elements of the new Second Life Advanced Creator Tools rolled-out to the Magnum channel. As I reported at the time, the tools were issued without the new permissions system, but with safeguards that (it was hoped) would prevent misuse.

Today, however, a party or parties unknown started to use teleport functions of the new tools outside of the Magnum Release Channel as a means of griefing. People first became aware of the issue as individuals and groups started finding themselves randomly teleported around the grid, which sparked speculation on Twitter. Later, messages started circulating in-world among groups, outlining issues, such as this one, sent out to the NCI Citizens Helper Group (with thanks to Raylene Gothly)

Ok to everyone, there is something seems grid wide, we do not know if its a bad code in certain sims or if someone has found a way to teleport grief. But its happening all over, so I’m not sure. however I’d like to let everyone know we are aware of this. Suddenly you are just teleported away, best to log off and relog to get out of it, as it seems to continue to teleport you, I was teleported 3 times when i relogged… Dont be frightened it just seems to be a mess up.

The only sims unaffected by the griefing tool appear to have been those on the Magnum RC (where the new teleport functionality has safeguards) and those sims that had script capabilities disabled. Messages were thus circulated to land holders to disable scripting in their regions to avoid the issue, at least until Linden Lab responded to the situation.

Linden Lab themselves commenced efforts to stop the problem with emergency rolling restarts across the grid, announced via a Grid status update and a forum post:

To solve a security issue with the Experience Tools that were deployed to Magnum last week we are doing an emergency simulator rolling restart deploy. This has already begun.

Regions on the following channels will be restarted with the fixed code:

• Main Channel
• BlueSteel
• LeTigre

Magnum will not be restarted because the issue is not possible in Magnum regions. We will have no rolling restart Tuesday morning. The Wednesday morning RC channels will roll at the usual time.

We apologize for any inconvenience and appreciate your understanding.

I’ll update here when further information is available.