SL projects update 25/2: Experience Keys (Tools) overview and beta information

Update Wednesday July 9th: Dolphin Linden also attended the Simulator User Group meeting on Tuesday July 8th, where he further discussed the Experience Keys (Tools) project. As that discussion covered some of the information given here, I have provided a further update on the additional information provided by Dolphin at that meeting, to serve as a companion piece to this report. Please do ensure you read that article as a follow-up to this one.

During the TPV Developer Meeting on Friday JUne 20th, Linden Lab gave advanced notice to third-party viewer developers that the long-awaited Experience Tools project will be entering a beta phase in the near future – possibly within the next month.

Dolphin Linden is one of the people working on the Experience Tools / Keys
Dolphin Linden is one of the people working on the Experience Tools / Keys

The notice came via Troy and Dolphin Linden, two of the key players from the Lab working on the project,  who between them gave an overview of what it is and how it should work, and answered questions from TPV developers.

There has been considerable interest in this project at Simulator User Group and Server Beta User Group meetings over the last several months, particularly as mention of the tools has been made in various RC deployment release notes, and the fact that they are currently on the Magnum RC. However, until the June 20th meeting, the Lab has remained tight-lipped on the matter.

The notes which follow were taken from an audio recording I made of the meeting, and the salient extracts from that audio are included at the end of this article (see also North’s video recording of the meeting). I’ll have a summary of the TPV Dev meeting itself available soon.

What Are Experience Keys?

Experience Tools is essentially a new means of providing a set of “blanket” permissions against a range of actions which might be taken on an avatar participating in a defined activity (e.g. allowing the avatar to be animated, teleported, have items attached, etc., in accordance with the requirements of the activity).  The idea is that rather than having to constantly give permission for objects, etc., to act on your avatar while participating in an immersive activity, you give a single OK at the start of your participation, and then no longer be distracted by additional dialogue requests. The permissions within the Experience Tools comprise:


Note that permissions such as DEBIT (i.e. take money from your L$ account) are explicitly excluded from the Experience Tools, and must still go the normal route of requesting permission from the user.

What is an “Experience”?

An “experience” in this context can be almost any immersive / interactive environment within SL where the user needs to provide permissions for objects, etc., to interact with their avatar. A list of examples of experiences might include:

  • A game or puzzle or hunt or quest which requires the use of a HUD and / or which requires certain items are attached to an avatar
  • An amusement park where every ride requires the user gives explicit permissions to every ride they take
  • A tour of an art or historical installation which utilises multiple teleports and / or the use of HUDs.

As noted above, within an experience, the user only needs to give permission to scripts and objects to interact with their avatar once, when they agree to participate in the experience.

Linden Realms, launched back in late 2011, was something of a precursor to Experience Tools, inasmuch as by entering a Linden Realm game area, players gave implicit permission for certain actions to be carried out on their avatars – HUD attachment, teleporting – without the need to explicitly allow each activity within the game. The difference between it and Experience Tools, is that with the latter, users must still  explicitly give that initial permission for objects, etc., within the experience to interact with their avatar.

Linden Realms, launched in 2011, was an initial release of what were to become known as the Advanced Creator Tools, the forerunner of the upcoming experience keys / permissions
Linden Realms, launched in 2011, was something of a precursor of what has evolved into Experience Tools / Keys

During the initial deployment, experiences using the Experience Tools will be restricted to running at the region / estate level for private islands / estates and parcel level for mainland. They will require white listing by the land owner in order to run. However, it is possible that the capabilities will be extended in the future to allow grid-wide experiences to be created (e.g. a grid-wide hunt involving multiple regions / mainland parcels). When / if implemented, this will mean:

  • Private estates / regions with access restrictions will have an additional level of access which will allow anyone participating in a grid-wide experience running on that estate / region to access it. However, should they revoke the experience permissions while on such an estate / region, they will be teleported away in accordance with the estate’s / region’s access controls
  • If a user opts not to take part in a grid-wide experience at one location, their refusal to do so applies to all locations running the same experience (so they do not have to keep refusing to participate when travelling around the grid).

See How it Will Work, below, for further information on allowing / refusing experiences and revoking permissions.

The Experience Key

The blanket granting of permissions which affect your avatar is obviously risky – such a blanket system could be exploited as a means of griefing / harassment. This was demonstrated in May 2012, during the initial deployment of the Advanced Creator Tools,. These included a “blanket” approach to granting permissions (in a slightly different manner), which was quickly exploited for griefing purposes. This forced the Lab to roll-back the tools, and then redeploy them in August 2012 without the associated permissions system.

To prevent this, every experience using the Experience Tools capabilities must be governed by an Experience Key supplied by the Lab – think of it as a licence applied to the experience and to all control scripts used within that experience, and which directly links the experience / experience scripts directly back to the experience owner, providing an audit trail of accountability.

The Experience Key allows the Lab, if necessary to instantly revoke all permissions used by a given experience, effectively stopping all scripts associated with it from interacting with avatars. The Experience Key will also be visible to users of an experience through the viewer (see Viewer Updates, below), so that abusive objects can be directly reported to the Lab.

Who Can Create Experiences Using These Capabilities?

Again, to reduce the risk of the Experience Tools being used for mischief, the ability to create experiences using the tools will be controlled. The Lab is still determining how exactly how this will be handled. However, it may be that content creators wishing to build experiences using them will have to pay for an Experience Key  / licence, or they may have to be a Premium member.

An Experience Key can only be owned by a single avatar account. However, to ease the process of experience creation, and to allow the collaborative development / management of an experience using the system, an experience can be associated with a group, and there will be two new group roles appearing when Experience Tools are deployed:

  • An “Admin” role which can be used to allow others to edit the experience profile (e.g name, description)
  • A “Contributor” role, which allows people to contribute content to an experience.

Viewer Updates

Experience Tools are primarily server-side, but require an updated viewer to access them, and to display important information about them. A project viewer will be released when the Experience Tools beta is officially launched (see below), and TPVs are being encouraged to integrate the code from that viewer (when available) so that as many users as possible can participate in the experiences available in the beta.

  • The project viewer will introduce new UI elements, such as:
    • An “Experience Profile floater”, which will allow you to see  details on the experience currently running (including the Experience Key). It will also include a button allowing you to report any experience object which is griefing in nature
    • A log in which all actions taken by permissions associated with an experience are reported, making it possible to see exactly what is going on with your avatar
  • The viewer will include updates to the estate management panel and the parcel management panel and changes to the script editor, and provide the ability for users to search for experiences
  • It will provide some additional capabilities specifically for experience creators (such as being able to associate a specific script with a specific experience via the Experience Key).

The viewer updates are primarily about providing the means by which users can understand what an experience is and does, and controlling how and experience affects their avatar.

So How Does it Work?

While the following is dependent upon the appearance of the beta, it should provide an initial feel for how the system will work from a user’s perspective.

  •  When arriving at an experience, you will be able to review information on it (e.g. by clicking on an information giver) – what it is and does, who owns it, etc. – and determine whether you wish to participate in it or not. You can then opt to:
    • Accept the experience so that any of the allowed permissions it employs will be able to operate on your avatar without the need for further permission dialogues being displayed and responded to
    • Refuse the experience so none of the experience permissions will act upon you at all. Should you re-visit the experience at a later date, the initial request asking for permission to control your avatar will again be displayed
    • Block the experience so it will not affect you during your current visit and it will never bother you again in the future, so you don’t ever have to refuse it again (unless you unblock it)
  • Once granted, permissions are persistent across log-ins; once you have accepted an experience, there is no need to re-accept on re-entering it, unless the permissions are explicitly revoked. Similarly, blocked experiences remain blocked until such time as you unblock them
  • You can revoke the permissions associated with an experience at any time, anywhere. Similarly, you can remove any block you’ve placed on an experience, should you later decide you’d like to participate; the next time the experience is visited, the initial prompt will be displayed

Beta Test

  • Beta testing looks as if it will commence within the next month (ish)
  • The beta is liable to be open to all users wishing to try-out experiences using the capabilities
  • The Lab will be providing two experiences of their own to try
  • It is likely the Lab will invite around a dozen content creators to develop experiences as a part of the beta. Invitations may be given on the basis of proposals received – although exactly how it will work has yet to be fully determined
  • The beta is likely to last “at least several weeks”
  • There will be an introductory video from Torley Linden when the video is launched, together with a blog post, and (hopefully) the opening of the Experience Tools SL wiki page which will have detailed information on the tools.


Speakers: Oz Linden, Troy Linden, Oz Linden, Jessica Lyon, Latif Khalifa

2 thoughts on “SL projects update 25/2: Experience Keys (Tools) overview and beta information

Comments are closed.