SL projects update 29/2: server, viewer, TPV meeting

My apologies for this appearing a little on the late side; things have been a bit manic in the physical world of late (not helped by the Tour de France and the German GP this weekend!), and I’ve been slipping behind on blog posts (I’ve also got to talk to my minions about vacation scheduling….).

Note that the following notes are taken from both the Server Beta User Group meeting of Thursday July 17th and the TPV developer meeting on Friday July 18th, the video of which is supplied below (my thanks to North, as always). Items taken from the later are time stamped within the text, so you can locate and listen to the discussion in full via the video.

Server Deployments Week 29 – Recap

  • On Tuesday July 15th, the Main channel was updated with the Experience Keys project, which had previously been running on Magnum. This roll-out coincides with the release of the Experience Keys project viewer (see below) and the release of the Lab’s first Experience Keys demonstrator game, The Cornfield.  Please refer to the release notes for further information
  • On Wednesday July 16th, the Magnum RC was updated a new infrastructure project that adds support for the upcoming changes to the Skill Gaming policy. Release notes
  • On Thursday July 17th, BlueSteel and LeTigre were both be updated with the Experience Keys project, but otherwise remained on the same  server maintenance project as week 28, which addresses a JSON-related bug, an interest list related race condition, and to improve L$ transaction logging for payments made by scripted objects. See the release notes (BlueSteel) for details.

SL Viewer

Group Ban Viewer

The Group Ban viewer reached release candidate status on Wednesday July 16th, with the release of version 3.7.12.292031. This viewer allows certain group members to ban avatar from a group or from joining a group  When an existing group member is banned, they are also automatically ejected from the group. Please refer to my Group Bans overview for further information, if required.

Maintenance Release RC

[04:20] This viewer, version 3.7.12.291824, has been tracking with the same crash rate as the current release viewer (3.7.11.291465), and as such is expected to be promoted to the de facto release during week 30 (week commencing Monday July 21st). However, it has been reported that the Mac Alt-Cam bug (BUG-6760) fix doesn’t work and has been referred back to the Lab for further investigation.

Oculus Rift Project Viewer

[04:56] It is anticipated that an updated version of the Oculus Rift project viewer will be appearing soon, potentially in week 30. The update will bring the viewer up to par with the current 3.7.12 release code base.

Log-in Test Viewer

[04:44] There is a special log-in test viewer currently on closed use (there is no publicly available version), which is being used for some kind of A/B testing related to logging-in to Second Life. Precisely what this testing is geared towards is unclear.

Viewer Autobuild Process

[05:50] Oz Linden has been working on improving the viewer autobuild process, and there is a new version of autobuild, together with a wiki page on the changes and improvements. The new version brings with it a number of improvements, such as stricter library version checking, full transitive dependency checks, additional error checks, etc. This is considered to be one of the steps required in order for the viewer to be compiled using Visual Studio 2013. Full details in the video for those into self-compiling viewers.

 Third-party Viewer Directory Updates

[00:20] The Third-party Viewer Directory, which lists all Second Life viewers and clients which have gone through the self-certification process, has been revised.

Until recently, the directory was listed by viewer crash rate – with the most stable at the top. However, this was something of a hit-and-miss approach due to a number of factors, including significant changes made to the code within the viewer which is used to detect and report crashes. So instead, viewer and clients are now split into three categories:

  • Those which are actively maintained “full” viewers which are updated regularly to track new developments in the Linden Lab viewer, and implement a full graphical environment
  • “Lightweight”, text and mobile clients, such as Lumiya, Group Tools, Radegast and so on
  • Those viewers which have not been updated recently enough to be considered fully compatible with current Second Life services (e.g. they lack things like server-side appearance, etc.).

Group Chat

[11:56] Work is continuing on group chat. At the TPV Developer meeting, Oz Linden summarised this work as:

We are working on group chat; I don’t really have much to report on that this week. We’re doing a set of experiments and collecting a lot of data, and then we’re going to come up with the next round of changes to make. One of the things we’ll try to do, once we think we’re done with this project – and I have no predictions for when that will be – is tell people how it went and what we’ve done.

It may well be that before we’re done, we’ll come back to this group and say we’re making changes to interfaces to viewers for group chat in order to improve the situation. I don’t know of any of those yet, but I’m not ruling them out. We’re going to try to make group chat a lot better, and if that means not being 100% backwards compatible, then that’s what it means. At this point we’re not looking at changing the protocol with anything else. Not ruling it out, but that’s not the correct direction.

Experience Keys

The Cornfield, the Experience Keys demonstrator game
The Cornfield, the Experience Keys demonstrator game

The current creator beta programme for Experience Keys has now been filled. Commenting on it at the Server Beta meeting, Coyot Linden referred to it as proving “wildly popular” and that the Lab have “heard some really cool ideas for new experiences”. He also referred to this being “round on” of the beta programme – so there may be more opportunities for creators to be involved in the future.

During the Server Beta meeting, a request was made for the Linden to consider allowing the popularity of an Experience (e.g. the number of people engaged on it) to be made available, with the suggestion it could be done in a number of ways:

  • As information made available only to the Experience owner (so they can see how popular a given experience they’ve created is proving to be
  • As information which can be (perhaps optionally) published by the Experience owner (e.g. via the Experience Profile)
  • As information which can be displayed in the Search tab of the Experience floater, allowing users to search for the most popular experiences at any given time.

Commenting on this, Simon Linden said, “The numbers will definitely be interesting, but we’ll have to think carefully about what and how to expose it.   As an owner, it makes sense for you to have an idea what’s going on with your experience.  I’m not so sure about others.”

Part of the concern here is about the popularity figure potentially being used by griefers as a means of targeting popular regions / activities and causing disruption. Following Simon’s observation, Dolphin Linden added, “yeah, technically the number can be made available. But how and to whom needs to be thought about, but numbers about your own xp can be tracked if you want with a little bit of work. We might also be able to just get an ordered list of the top 10 experiences or something, without disclosing actual numbers.”

Continue reading “SL projects update 29/2: server, viewer, TPV meeting”

The Experience Keys project viewer

The cornfield (game play area iuses a much darker and more atmospheric windlight)
The Cornfield: the Lab’s Experience Keys demonstrator (game play area uses a much darker and more atmospheric windlight)

On Monday July 14th, Linden Lab issued the Experience Keys project viewer alongside the launch of their Experience Keys demonstration game, The Cornfield, which I’ve reviewed separately.

As a quick overview for those not in the know, an Experience in Second Life can be almost any immersive / interactive environment within SL where the user needs to provide permissions for objects, etc., to interact with their avatar. Experience Keys mean that anyone wishing to participate in any activities suited to the use of Experience Keys need only give their assent once, thereafter, actions within the Experience which affect their avatar happen automatically – teleports, attaching a HUD or item of equipment, etc. – without any need for user approval (although notification of so actions may still be displayed in the viewer window).

The Experience Keys project viewer – version 3.7.12.291846 at the time of writing – is available from the Alternate Viewers wiki page, includes a number of key UI updates which are used alongside experiences in Second Life, and which apply to those creating experiences, those using experiences, and those who allow experiences to run on their land.

Please note that until server-side support for Experience Keys is fully deployed across the main grid (Scheduled to complete on Thursday July 17th, some elements of the viewer will not function on BlueSteel or LeTigre RC regions  – for example, searching for experiences will not return any result if you are on a region running on either of these two RCs).

The Experiences Floater

Within the Experience Keys project viewer, this is accessed via Me > Experiences (no toolbar button or keyboard shortcut with the project viewer), and provides the means for users to locate experiences in Second Life, manage the experiences they have encountered during their travels through Second Life or which they have created or contributed to, and also check any actions any given Experience has performed on their avatar. It comprises five individual tabs.

Search

Allows you to locate experiences in SL by all or part of their name and filtered by maturity rating. The tab also includes an option to view the profile for an Experience (see below).

The Experience floater is accessed via Me > Experiences, and comprises 5 tabs. Search allows you to search for SL experiences
The Experience floater is accessed via Me > Experiences, and comprises 5 tabs. Search allows you to search for SL experiences

Allowed / Blocked

These two tabs allow you see those experiences you have either allowed – that is, you’ve granted permission to – and those you’ve blocked. A blocked experience is one in which you have refused to participate and have blocked it so that you will no longer be prompted to join it whenever you visit a region / parcel where it is active (until such time as you choose to revoke the block).

Each tab displays a list of experiences by name. Clicking on a name will display the relevant Experience Profile (see below).

The Experiences Allowed tab displays a list of experiences in which you have participated. Click on an experience name to display the associated Experience Profile. The Blocked tab is similar in nature, but displays all experiences you have blocked from bothering you
The Experiences Allowed tab displays a list of experiences in which you have participated. Click on an experience name to display the associated Experience Profile. The Blocked tab is similar in nature, but displays all experiences you have blocked from bothering you

Admin, Contributor and Owned

These three tabs respectively display:

  • Those experiences for which you have been made an administrator of (via a special group role called Admin). Administrators are those people assigned by the creator of an experience who can edit the Experience Profile
  • Those experiences for which you have been made a contributor (via a special group role called Contributor). Contributors are those people assigned by the creator of an experience who can contribute scripts and objects to an experience
  • Those experiences you have created and own. While an experience can be a collaborative piece – hence the Admin and contributor roles – one avatar must be the designated owner of an experience and hold overall responsibility for it.

Events

This tab allows you to see the actions (events) taken on your avatar by any experiences in which you’ve recently participated. It includes a number of additional options:

  • Notify: turn-on on-screen notifications for a given event – so if you wish to be notified each time your avatar is animated by any experience, for example, you can use this button
  • Profile: display the Experience Profile for the experience associated with the event
  • Report: will open the Abuse Report floater, which has been pre-populated with the relevant information, allowing you to instantly file an Abuse Report against an event / object which is causing grief  / harassment
  • Notify All Events: checking this will cause all on-screen notifications for events within any experience to be displayed by the viewer
  • Days: the total number of days history of events you wish the tab to display
  • Clear: clear the event list
  • < and >: page through the list.

Experience Profile

The Experience Profile floater
The Experience Profile floater

The Experience Profile provides the following  information on any given Experience:

  • The experience name
  • A short description
  • An image (if provided)
  • The maturity rating for the experience
  • The experience owner
  • The group associated with the experience
  • A link to any associated Marketplace store

In addition, the Profile contains four buttons:

  • Allow: will add the Experience to your list of allowed experiences without you having to actually visit it and agree to participate. When visiting experiences allowed in this way, you will not see any invitational dialogue boxes displayed, because the system will already consider you a participant. Note that if you have already participated in the experience, this button will be grayed-out
  • Block: will add the Experience to the list of those you have blocked, so that you will not be bothered with any invitational dialogues when visiting regions / parcels where it is running – although you also won’t be able to participate in it until such time as you unblock it. Note that if you have already blocked the experience, this button will be grayed-out
  • Forget: If you have previously added an Experience to either your Allowed or Blocked list, this button will remove it from whichever list it appears on. This means that for a previously allowed Experience, you will have to once again agree to participate in it when you next visit, and for a previously Blocked Experience, you will receive invitational dialogues on visiting it once more, allowing you to participate in it, if you’ve changed your mind.
  • Report: opens the Abuse Report floater, which has been pre-populated with the relevant information, allowing you to instantly file an Abuse Report against an event / object which is causing grief  / harassment.

Continue reading “The Experience Keys project viewer”

SL projects update week 29/1: server, viewer, Experience Keys

Server Deployments – Week 29

As always, please refer to the server deployment thread for the latest status / updates / issues.

Main (SLS) Channel

On Tuesday July 15th, the Main channel was updated with the Experience Keys project, which had previously been running on Magnum. This roll-out coincides with the release of the Experience Keys project viewer (see below) and the release of the Lab’s first Experience Keys demonstrator game, The Cornfield.  Please refer to the release notes for further information.

Release Candidate Channels

On Wednesday July 16th, the Magnum RC should be updated a new infrastructure project that adds support for the upcoming changes to the Skill Gaming policy. This would appear to be the changes required to support the new Skill Gaming region type. Release notes.

On Thursday July 17th, BlueSteel and LeTigre will both be updated with the Experience Keys project, but will otherwise remain on the same  server maintenance project as week 28, which addresses a JSON-related bug, an interest list related race condition, and to improve L$ transaction logging for payments made by scripted objects. See the release notes (BlueSteel) for details, and part 2 of my projects update for week 28.

SL Viewer

As noted above, the Experience Keys project viewer, version 3.7.12.291846, was released on Monday July 14th. This provides viewer-side support for accessing and managing SL experiences using the new Experience Keys permissions capabilities.

The Search tab on the new Experience floater - part of the Experience Keys project viewer
The Search tab on the new Experience floater, accessed from the Experiences option in the Me menu in the Experience Keys project viewer

This viewer can be used in conjunction with the Lab’s Experience Keys demonstrator game, The Cornfield, and with other experiences as they are opened to public use. Please keep in mind that the viewer may not behave correctly until after the server-side deployment of Experience Keys support has completed on Thursday July 17th.

For further details on Experience Keys, please refer to the following:

There are also some further notes from Dolphin Linden on the subject, below.

Yet More on Experience Keys

Dolphin Linden at the Simulator UG meeting
Dolphin Linden at the Simulator UG meeting

Dolphin Linden again attended the Simulator User Group meeting on Tuesday July 15th, where he answered more question on the Experience Keys project.

Lucia Nightfire offered up a couple of points of feedback which appear especially relevant to the new capabilities:

  • An estate / parcel setting to disable all non-experience scripts. This would be useful in game experiences, as it could prevent participants cheating by using non-game scripted objects
  • An estate / parcel setting to block all grid-wide experiences from running on an estate / parcel. Currently, any grid-wide experiences which come on-line have to be explicitly blocked by name, which means if an estate / parcel owner didn’t want any grid-wide experiences running on their land, they’d have to keep adding them to their block list as and when they become aware of them. A single check-box option would eliminate this.

Feature requests are to be filed on both of these points, which the Lab have agreed to look into.

Other Bits

Sim Crossing Hiccups

There have been renewed reports of region crossing issues which seem to be occurring regularly, but only between certain regions when tested. The issues mainly appear to affect vehicles and take the form of the avatar taking an exceptionally long period of time to cross between regions – with the vehicle the avatar is say upon taking up to 30 seconds longer. When this happens, the avatar appears to be visually unlinked from the vehicle, but the vehicle itself fails to get auto-returned, as the simulators appear to consider the avatar and vehicle as still being linked.

Motor Loon provided some specific details on the issue, and has indicated he will raise a bug report using the information he has, as the Lab are unaware of any specific problems which may cause this. However, while it has yet to be confirmed, it was also reported at the meeting at a similar issue on a region crossing between two regions was resolved by restarting them in a specific sequence.

Viewer release summaries 2014: week 28

Updates for the week ending: Sunday July 13th, 2014

This summary is published every Monday and is a list of SL viewer / client releases (official and TPV) made during the previous week. When reading it, please note:

  • It is based on my Current Viewer Releases Page, a list of all Second Life viewers and clients that are in popular use (and of which I am aware), and which are recognised as adhering to the TPV Policy. This page includes comprehensive links to download pages, blog notes, release notes, etc., as well as links to any / all reviews of specific viewers / clients made within this blog
  • By its nature, this summary presented here will always be in arrears, please refer to the Current Viewer Release Page for more up-to-date information

Official LL Viewers

  • Current Release updated to version: 3.7.10.291265 July 8th – formerly the Snowstorm viewer – Windows XP users, please note that you must have Service Pack 3 (Win XP 32-bit) or SP 2 (Win XP 64-bit) in order for this viewer to install (download page, release notes)
  • Release channel cohorts (See my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
    • SL Maintenance RC version 3.7.12.291824 released on July 10th – almost 40 MAINT fixes from the Lab “to make your Second Life smoother”  (download and release notes)
  • Project viewers:
    • Project refresh viewer version 3.7.12.291799 released on July 10th – contains an update to a large set of libraries used by the viewer to provide security, stability and consistency improvements to this and future viewers (download and release notes)

LL Viewer Resources

Third-party Viewers

V3-style

  • No updates

V1-style

  • Cool VL viewer updated on July 12th – Stable release to version 1.26.12.7 and Legacy version 1.26.8.65 – core updates: please refer to the release notes

Mobile / Other Clients

  • No updates

Additional TPV Resources

Related Links

SL projects update 28/3: more server and viewer news

Banana Island - The Pilgrim's Dawn; Inara Pey, March 2014, on FlickrBanana Island, The Pilgrim’s Dawn, March 2014 (Flickr)

Server Deployments Week 28 – Recap

  • On Tuesday July 8th, the Main (SLS) channel was updated with the server maintenance project that was previously on BlueSteel and LeTigre.  This project adds the ability for LSL functions to view and modify the render materials (normal mapspecular map, and diffuse texture alpha mode) properties on prims, via new prim parameters – release notes
  • On Wednesday July 9th, the RC channels were updated as follows:
    • BlueSteel and LeTigre received the same new server maintenance update to address a JSON-related bug, an interest list related race condition, and to improve L$ transaction logging for payments made by scripted objects
    • Magnum remained on the Experience Tools project, and receives the same updates as the Main channel, so LSL support for materials is now grid-wide.

 BlueSteel / LeTigre Updates

Commenting on the server maintenance update deployed to BlueSteel and LeTigre at the Server Beta UG meeting on Thursday July 10th, Maestro Linden explained one of the bug fixes (BUG-6466) and the L$ transaction update thus:

The LSL JSON bug fix, BUG-6466, just makes it so that numbers in the format “1.0e+2” get parsed as JSON numbers.  Previously, they’d be treated as strings (though “1.0e2”  would be treated as a number). The spec says that “+” is optional, so we added that support.  I’d be surprised if more than 2 people end up noticing that change 🙂 .

The one non-bug fix change in BS and LT is more verbose logging of certain L$ transaction types … Historically, a L$ transaction from scripted payment (llTransferLindenDollars or llGiveMoney ) would not include the name of the object that did the payment, when you viewed it in the “L$ Transactions” section of the website. However you would see that information if somebody had paid L$ into an object.

Previously, the entry would just look like this: Destination: Maestro Linden; Object Pays; Region: Morris.

But now, with the update to BS and LT, transactions in those regions will additionally include this line: Description: <Name of object which paid>. The page where you see the difference is https://accounts.secondlife.com/transaction_history/. Anyway, it could be useful for understanding which of your objects are paying out L$. Assuming they’re not all named “Object” :).

The remaining fix, “Temp Attachments are sometimes not removed on the viewer when detached from a region change event”, was related to a race condition, and explained by Simon Linden:

Updates were out-of-order there. Basically if your script took things off on the region change, anyone might get the updates out-of-order. It was worst on slow connections. For those who are curious, it went like this:  if the first update from the new region was slow, the “kill” message removing the object would happen first, and get ignored.

So in other words, items which should have been removed appear to remain in place, with Simon adding:

In this case you can’t detach it … because for the sim, it’s already gone. The viewers are the ones out-of-sync with the server. So you right-click and detach again and nothing happens.

The fix on BlueSteel and LeTigre should hopefully prevent this from occurring during a region change to regions on these channels.

SL Viewer

Maintenance RC Viewer

A new Maintenance RC viewer appeared late on Thursday July 10th. Version 3.7.12.291824 contains almost 40 MAINT fixes intended “to make your Second Life smoother”. The list of fixes include:

  • MAINT-3135 Cocoa Viewer: Mac: Maximizing the viewer leaves garbage on the screen
  • MAINT-3154 Alt zoom zooms way out when attempt to zoom in on Mac build running with external monitor
  • MAINT-3171 Alt-clicking while moving mouse can move the camera significantly
  • MAINT-2980 Reevaluate the 512 meg texture cap
  • MAINT-4216 Double clicking on anything in COF removes it from your avatar – including skin, shape, hairbase and eyes – results in bakefailed avatar
  • MAINT-4001 Received Folder is movable within Recent Tab – see my notes here on this issue
  • MAINT-3610 SL viewer partly ‘eats’ chat-message.

 

Please refer to the release notes link above, for the full list of MAINT fixes.

Library Refresh Project Viewer

The Lab issued a new project viewer on Wednesday July 9th, version 3.7.12.291799, which contains a number of updates related to the third-libraries used by viewer. This viewer has grown out of Monty Linden’s ongoing HTTP work, which required the update of several essential libraries used by the viewer, and Monty took the opportunity to undertake a more extensive update of the libraries.

These library updates should provide better security, stability and consistency improvements to the viewer. However, an advisory to Mac users warns that the updated libraries in the viewer have been built with a minimum OS level of 10.6. Therefore, this viewer, and future viewers based upon it, will not run on OS X 10.5.

While the viewer is primarily intended for testing purposes, and doesn’t contain updates which are liable to be noticed by most LS users, it is thought that it might help those encountering very specific SSA-related issues, the release notes stating:

A few users have experienced problems with avatar appearance due to their very specific network configuration. Gray avatars are accompanied by ‘Transferred a partial file’ errors in the SecondLife.log file. Linden has not been able to reproduce this internally but a possible workaround is found in this release.

A list of related JIRA reports is also given, but none of these appear to have been switched back to public access at the time of writing. They are: BUG-3323, BUG-3770, BUG-3877, BUG-3879, BUG-3882 and SH-4375.

Other Items

SL AIS Viewer login / Attachments Issue

Users on the SL viewer using the AIS v3 viewer code are reporting issues with attachments when logging-in to Second Life.

Some of the issues are described as a user logging-in to find their hair or (mesh) foot / hand or other attachment incorrectly positioned, and the only way to rectify the situation is to re-log. Some have suggested that swapping between a non-AIS v3 viewer and the AIS v3-enabled viewer may trigger the situation.

Some bug reports (BUG-890 and BUG-2772, both unfortunately non-public at the time of writing) have been pointed-to as examples of the problem, and further reports have been requested should it be encountered, with Coyot Linden noting for those wishing to file a JIRA on the matter:

One way to get a grapple on that sort of thing is to start a test run and keep track of the login times and regions.  When you hit a fail, logout and do one more and see if it succeeds.  If you provide that and the viewer logs, it would be easier for someone to do some log diving to figure out what the problem is.

Coyot Linden Takes the Driving Seat

Maestro Linden is  taking a three-week vacation from the Lab and Second Life. In his absence, Coyot Linden will be occupying the driving seat for the Thursday Server Beta meeting.

SL projects update 28/2: more on Experience Keys (Tools)

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.

Dolphin Linden at the Simulator UG meeting
Dolphin Linden at the Simulator UG meeting

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
    • A sample Experience profile
      A sample Experience profile

      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.