Day: July 9, 2014

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.