Today Dolphin Linden was at the Scripting-Server User Group meeting answering questions about the Experience Tools (XP Tools) and how they will work. The made for an interesting meeting. I posted about this meeting’s coming Q&A last week.

The current request for Beta Testers is for experience creators, Madpea or Loki Eliot type people. Latter they will be asking for experience participants (users) to join the beta testing.

There is a knowledge base article up: Experiences in Second Life. This is mostly for users not scriptwriters. We are told by Oz and Dolphin Linden that wiki documentation is in the works. The current draft is being reviewed by those Lindens that do the reviews. Scriptwriters check the last line of this post.

Dolphin and Oz Linden told us the following things:

Dolphin : We are working on a beta program. Once that is done we will announce how people will be getting access to make their own experiences.

Oz: The documentation will be posted shortly.

Dolphin: 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.

Dolphin: We are still working on the rules about who can have them [XP Keys].

Dolphin: An experience can be associated with a group. [Groups will have two roles; admin and contributor.] There is a new group power ‘contribute to experiences’ which will allow associating scripts with the experience.

Dolphin: Experiences may be allowed by a parcel owner, if not blocked by the estate owner.

Oz: Each script may only be associated with a single experience.

Dolphin: However, different scripts on the same object may have different experiences, though that might be hard to manage properly.

In order to get into the ‘creator’s’ beta Dolphin said: I would say that you don’t have to have something you want to convert necessarily, but you should be able to demonstrate that you have the experience with building/scripting to make use of the tools.

In answer to my question of how easy it would be to adapt existing scripts to XP Tools, Dolphin said the permissions request used now would have to change as a first step. Then the event handlers would need to change to handle two new events: experience_permissions and experience_permissions_denied. Those will need to be handled instead of the normal permission event.

Dolphin: I would describe XP Tools as providing 2 [new] things; a persistent permission model that has been talked about a bit and a simple key:value database for storing game state. [Otherwise] for permissions, there is not a lot different from WHAT you can do today. The main difference is removing popups.

Dolphin: The permission is persistent and grid-wide. However, experiences must be able to run in the location where the av is. An experience may not be allowed in a particular estate or parcel and an adult experience may not run on a general region, for example.

Dolphin: Permission can be revoked at any time [by the user, XP owner, and/or the Lab]. In that case, the experience_permission_denied event will be sent to scripts in the region. If the owner wants to turn it off temporarily (maybe to fix a bug or something) they can and LL can disable an experience temporarily or permanently in response to abusive behavior.

Dolphin: There is the idea of a “Trusted Experience” which can be set at the estate level. A trusted experience will allow people in the experience access to a non public estate. If they [estate manager/owner] block the experience while [an XP users is] on the estate, then they will be teleported home. This allows estate owners some extra tools to force people to be in an experience if they want to be in the estate. [But,] normal allow lists still apply, so you can add individuals or groups access as normal.

Dolphin: The permissions granted are:

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

Other permissions, notably debit, will still have to be handled the old way.

Dolphin: The list of experiences allowed on an estate is public information. The list of experiences a resident has allowed or blocked is private information.

Dolphin: Assigning an xp [key] to a script must be done by the xp owner or by a member of the xp’s group with the appropriate group power.

Oz: That’s probably the biggest difference between the first iteration and this one.

Dolphin: There is no concern about your script getting leaked then people taking over your experience, [but] you still have to be careful who you give access to.

Dolphin: An xp [key] is set on a script via the script editor, there is a combobox at the bottom which allows you to select any xp you have permissions for. You cannot change the xp [association] on a script without modify permission.

Dolphin: You can set a content rating on an experience. That will prevent anyone from letting it run in a lower rated region. Also, there is a public profile for each experience which contains: Name, Description, Content rating, SLURL, marketplace url, image, and owner/group. Those fields should all be rated G.

Dolphin: The experience is set at compile time, similar to the compile type and you need to re-save if you want to change the experience. An xp is part of a compiled script.

This is paraphrasing Dolphin to reduce the Q&A to a statement: if a Mod-OK script is given to someone, can they change it and keep it attached to the experience key? If the script is editable [Mod-OK], but the person editing it does not have permissions for the experience they will not be able to save the script, unless they remove the experience or change it to one they have permission for.

This tells us the ‘key’ is not held  in the script, bit only a reference to the key. Those the control is server side.

The question came up as to whether XP Tools could be used to create clothing attachments. Yes.

Dolphin: If the person later blocks the xp, or goes to a place where the xp is blocked, then all temp attachments will fall off, well, die.

Oz: Not only can you attach demos, I suspect that you could use the database to create an in-store shopping cart… keep track of what a customer has been trying…

Database

Dolphin: Let me talk about the db real quick. It is fairly simple, but should make storing state [think: game state]much more simple and fast. Basically, it is just a string to string mapping. So you could use, e.g. the residents id as a key and information about them as the value. It supports create, read, update, delete, count, and iterate. And the update can be made to be atomic so that it is safe to modify from multiple scripts.

Oz: One db per experience.

Dolphin: Each experience has their own db, which can be accessed anywhere the experience can run. The databases are completely separate, if you want to reference data in another one, you will have to do that with two different scripts and message passing. The db will be limited in size, we are still determining an appropriate limit. We will likely provide options for people to raise that limit for L$ in case your experience needs more. [The] size policy is in the works, but [it size] is configurable.

Dolphin: We really hope it makes things much easier to keep track of any information you need about people taking part. I find it works really well with the json objects for the value 🙂

Next Tuesday (12noon – Denby), Dolphin plans to be at the Scripting-Server UG again to answer more questions.

UPDATE: Aaaaaah! I over looked the link into the WIKI: Experience Tools.