Tag: Experience Keys

On Tuesday July 8th, Dolphin Linden, a member of the team responsible for the Experience Keys (Tools) project,  attended the Simulator User Group meeting, where he took time to provide further information on the project via what amounted to a Q&A session.

The following notes have been taken from Dolphin’s comments, and should be read alongside my original overview for Experience Keys, and the Lab’s invitation for experience creators to participate in the Experience Keys beta programme.

Note that because some aspects of Dolphins comments on Experience Keys have been covered in my original article (e.g. the concept of trusted Experiences running on regions with access control enabled, permissions covered by Experience Keys, etc.), they can not reproduced here.

• Documentation for the projects will be finalised “shortly” – it is currently undergoing final review and update
• Precisely how Experience Keys will be made available to people is still to be decided; as Dolphin reiterated at the meeting: “We are working out the details, but we want them to be reasonably available, but not so easy acquire that people will make throw away ones to try to grief people; we are still working on the rules about who can have them.”
• Those applying to be part of the Experience Keys beta do not necessarily need to convert an existing experience they may have, but
  • They should be able to demonstrate that they have the experience with building/scripting to make use of the tools, and
  • They should provide as much information on possible about the kind of experience they’d like to present through the beta
• Experiences and region maturity ratings:
  • Experiences must respect the maturity of the region(s) on which they run – so an adult rated experience cannot run on a general region, for example
  • Experience ratings are set by the experience owner, and this rating is used to determine the region maturity rating required in order for the experience to run

  • 

    The rating is part of the Experience’s public profile, all of which must be G rated

  • The list of experiences running on a region is public information
• Experiences and scripts:
  • A script can only be associated with a single experience
  • However, a single object can include multiple scripts belonging to different experiences, if required – although this might prove difficult to manage, depending on what the scripts are doing / how the object is used
  • Assigning an Experience to a script must be done by the Experience owner or by a member of the Experience’s group with the appropriate group power (“Contributor”)
  • Existing scripts can be converted to work within an experience, the permissions request to an Experience permissions request and then the event handler would need to be modified to handle tw new events – EXPERIENCE_PERMISSIONS and EXPERIENCE_PERMISSIONS_DENIED
  • An Experience is set on a script through a combo box in the script editor. This lists all Experiences the script creator either owns or has Contributor rights to
  • The selected Experience is set at compile time (similar to the compile type), and is part of the compiled script. The script must be re-saved if it the association is changed to another Experience
  • If a modifiable script associated with an Experience is passed to someone who does not have Contributor permissions for the Experience, they will not be able to save the script unless they remove the Experience or change it to one for which they do have permission
• The Experience database:
  • Every Experience has its own database, which can be accessed wherever the Experience is running
  • The database is fairly simple, but should make storing the current state-of play for avatars engaged in an Experience (e.g. what they have been doing, what they have attached, etc.)
  • It is basically string-to-string mapping
  • The database supports create, read, update, delete, count, and iterate, and the update can be made atomic, so it can be safely updated from multiple scripts
  • The overall size of the database will be limited, although the Lab is still determining an appropriate limit
  • The database size is also configurable (per Experience), so the Lab will likely offer Experience creators the opportunity to increase their database size for a L$ fee, if needed, although this policy has yet to be finalised
• As indicated in my original notes, an Experience can be refused or blocked by a user, and can be revoked by the Lab. Additionally, an Experience can be suspended by the Experience owner (so as to allow a bug to be fixed, for example). All of these will result in an EXPERIENCE_PERMISSIONS_DENIED event being sent to all scripts associated with the experience
• Also as indicated in my original notes, 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
• All temporary attachments made to an avatar will die should the person go to a place where the Experience is blocked or if they block the Experience.

Again, please do be sure to read the above notes alongisde my original overview of Experience Keys.

Dolphin Linden will be available at the next Simulator User Group meeting on Tuesday 15th July to answer further questions.

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.

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:

• PERMISSION_TAKE_CONTROLS
• PERMISSION_TRIGGER_ANIMATION
• PERMISSION_ATTACH
• PERMISSION_TRACK_CAMERA
• PERMISSION_CONTROL_CAMERA
• PERMISSION_TELEPORT

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.

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.

Continue reading “SL projects update 25/2: Experience Keys (Tools) overview and beta information” →