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).
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).
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 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.
The Experience Profile can be viewed in a number of ways, e.g:
- From any tab in the Experiences floater where the Experience name is displayed as link
- From the name of the Experience as displayed in any invitational dialogue which is displayed in your (Experience Keys enabled) viewer
- Via the View Profile button in the Search tab of the Experiences floater.
Region / Estate and About Land
As well as the above, the Region / Estate and About Land floaters in the viewer has also been updated with a new Experiences tab. These allow the landowner to control which Experiences can run on the land by adding them to the correct list:
- Allowed: the Experiences listed are allowed to run on all regions in the estate (Region / Estate floater) or on the parcel (About Land floater), if not blocked at the estate level
- Blocked: the grid-wide experiences listed are blocked from running on all regions in the estate (Region / Estate floater) or the listed Experiences are blocked from the parcel (About Land floater)
- Trusted (Region / Estate floater): the listed Experiences are allowed to run on all regions in the estate, and participants in the Experience are allowed to access the estate regardless of any access controls, but only so long as they are participating in the Experience (see below).
- Experiences with a higher maturity rating that a region / estate will be automatically blocked from running on any part of that region / estate
- Because non grid-wide Experiences must be white listed via the Allowed list in order to run on an estate, there is no need to block such Experiences via the block list; if they’re not on the Allowed list, they won’t run on the estate
- Similarly, because grid-wide experiences are designed to be just that – grid-wide – there is no need to explicitly allow such experiences on an estate. Instead, they only need to be blocked if you do not wish to have them running on your estate.
A Note on Trusted Experiences
As noted above, Trusted Experiences are those experiences an estate owner is allowing on the estate regardless of any access controls enforced on the estate. This means that anyone participating in such an Experience can access the estate’s regions, regardless of whether or not they are on the access list. However, should they revoke the experience while on the estate (e.g. click the Forget button on the Experience Profile), they will immediately be teleported out of the estate, as per the estate’s access controls.
Scripting Related Updates
The viewer also contains the following scripting related updates for experiences:
- The script editor has controls to associate a script with an Experience and to view the profile of the Experience a script is associated with. The controls are only enabled if the resident is an Experience Contributor.
- The properties floater for a script has a link to the Experience it is associated with, if any.
Joining an Experience
Aside from viewing the floaters described above, the viewer operates in exactly the same way as any other viewer, the only other noticeable difference you are likely to see is when encountering an active Experience or gateway to an experience. When this happens, a dialogue box is displayed which gives information on the experience (this may occur automatically, such as when arriving at a landing point or on collision with and invisible phantom prim, or it might be the result of having to click an information giver or similar, depending upon how the Experience is configured).
If you are using a viewer that is Experience Keys enabled (such as a the project viewer), this dialogue box will include a link to the Experience Profile (by clicking the Experience name link), and buttons to accept / refuse the Experience or to block the Experience (so you’ll never see a prompts anywhere for it again) or to block just the current inviter.
If you are using a viewer that has not been updated with Experience Keys support, the dialogue box will only allow you to accept / refuse participation in the Experience.
Note that when participating in an experience, nothing as actually stored by the viewer itself, all of the relevant information is stored server-side in a special database associated with each Experience. Also, anything attached to your avatar as part of an Experience is not added to your inventory – it forms a Temp Attachment and is removed and deleted when you leave any parcel / region running that specific Experience / should you opt to stop participating in the Experience.
Final Points
Do remember that the Experience Keys project viewer is just that – a project viewer. The final capabilities and options may be different to how they are presented in the current version. For example, there is already a request that the Region / Estate floater includes an option to block all grid-wide experiences, rather than having to block them individually by name, to help those estate owners who do not want any grid-wide experiences running on their regions.
Similarly, a request has also been made to allow land owners to set there land so that only the scripts associated with allowed experiences will run, thus helping to prevent cheating in games through the use of scripted objects.
Obviously, it remains to be seen if such ideas will be implemented as the tools in the viewer are developed. In the meantime, this overview will hopefully act as a useful introduction to the viewer’s Experience options.
Inara Pey: Living in a Modemworld 
Im really getting tired of seeing all the new features that LL is putting out that clearly took a lot of developer time and effort while the major bugs that are affecting SL are continuing to be left unfixed.
Every since 3.7.7 was released and up to the current 3.7.11, users have been plagued with large amounts of vanishing prims, entire chunks of sims missing when changing group tags, avatars distorted until a relog when changing outfits, intermixed add/wear inventory problems, attach and detach problems, and persistent blurred textures all over the place…just to name a few. All these bugs have been accepted by LL on their JIRA as real problems but not a single fix has come so far and there is no evidence of any fixes even being in the works.
But what to we get instead. Ooooo experience tools! Excuse me while i barf.
LikeLike
In fairness, the Lab is continuing to work on both viewer and server issues.
The viewer in particular has had a fair number of maintenance releases specifically aimed at bug fixes (there’s one in the release channel right now). These viewers comprise fixes for issues with the viewer the Lab has been able to repro & has accepted for a wide range of problems – rendering issues, inventory issues, long-standing Mac issues, etc.
We’ve also seen recent viewer releases such as the MemPlug RC, which was specifically geared towards fixing memory leak issues which cause the viewer to crash / freeze (later combined with the Sunshine / AIS v3 RC). There’s been further work from Monty Linden in improving mesh and texture loading via his HTTP updates & HTTP pipelining work, and so on.
As it is, don’t forget that Experience Keys aren’t something the Lab has cooked-up in the last few months. This work is something they have been slowly plugging away at since at least 2012 (2011, if you count the SLCC 2011 previews of what was to become Linden Realms, which was in turn the first cut at providing the capabilities we see in the Advanced Creator tools, of which Experience Keys form a part). So if anything, it could be argued that the reason Experience Keys have taken so long to surface is because the resources perhaps have been diverted to deal with very specific issues as and when it has proven beneficial in solving said issues for the Lab to do so.
Yes, it is frustrating when long-standing issues appear to go unresolved, or seem to keep cropping-up; but it would be a mistake to think that just because the Lab deliver feature X, issues A, B and C aren’t being dealt with. And it’s not necessarily true that the more manpower you throw at a problem, the quicker it is resolved.
LikeLiked by 1 person
I am not denying that the Lab does fix bugs at times. But there is no doubt that the priority is on the back burner or their timeliness has a lot to be desired.
That maintenance RC that you pointed out does not contain a fix for any of the severe bugs that i pointed out in my original post. It is comprised of literally months old minor level bug fixes that were sleeping around in their viewer-tiger repository for months that they never bothered to try to fast track out to users. Although it does address some older minor bugs, its super late to the party and leaves the big and very experience hurting ones of the past few months unaddressed. When i made reference to “evidence” in my earlier post, i was including not just release candidates and project viewers, but also source code commits to almost all of LL’s publicly viewable source repositories and also the individual active work repositories of many Lindens. Not a sign in the slightest of any of those major bugs being worked on. And even if one did come up with a fix today, as i am writing this, it could take literally months for the fix to make it into release due to the way they run their current release candidate cycle.
And the project viewers that you mentioned bring up another issue. There are too many times where there is a major bug is actually fixed by the lab but instead of being fast tracked out to users in a hot fix or maintenance RC, it is shlepped into a project viewer like its trivial issue that will often take months to hit release. The group bans project viewer is an example of that. For the past several months, there have been major bugs with group owner capabilities. Problems like being unable to assign others to owner role, unable to remove from owner role, unable to invite to owner role, and some other misc problems with roles in general. But instead of working to get it out to users as fast as possible when the fix was made a couple months ago by putting it into the maintenance RC of the time, its simmering in the group bans project viewer that might not be released for months. The bug fix isn’t even reliant or related to the new group ban code. But there it sits with users still trying to have to deal with the bugs for likely months to come before it finally makes it into release one day.
Most of the long standing Mac issues that were recently fixed in release were born a year ago with the Cocoa changes. You go to almost every third party viewer developer meeting and you know for how long developers where hounding and begging LL to fix the bugs. And guess what, most of the fixes didn’t even come from Lindens. The majority of fixes came contributed from third party viewer developers months after they saw that they Lab was not going to fix them themselves. Those contributed fixes were sitting in Oz’s snowstorm repository since last winter time and only just recently, here in July, actually finally made it into release. A year after they were discovered and fixed by mostly TPV developers and sitting collecting dust in Oz’s repository. Nothing to applaud.
And we all remember the mountain of bugs that came with CHUI. There are still many bugs that linger from its launch back in Spring of 2013. For literally a year, loading access lists and ban lists for parcels along with group member list loading was very unreliable and would almost never load right the first time. That bug went unaddressed for months and months until Ansariel Hiller, again, not a Linden, actually fixed the bug and contributed it back in the Winter of 2013. And just like the Mac fixes it sat in Oz’s snowstorm repository for months until hitting release a full year later in July of 2014. Again, nothing to applaud.
And onto the MemPlugs release as of late. The problem of virtual memory address exhaustion has existed in the SL viewer for years. Only in middle 2014 after years of it being a major crasher did the lab actually put out something to try to address. Attempted fixes coming years later is nothing to applaud.
Monty’s HTTP pipelining work is basically a prototype at this point. He doesn’t even have the work available right now on his viewable repositories. Only ‘insiders’ of sorts can get access to precompiled binaries of it or to the source code to compile or see how the work is coming. It will most likely be 6 months minimum before the work starts hitting the light of day in a release candidate or release. If any of this work on that project actually does fix the persistent blurred textures problem it is very far in the future. The problems with enormous amounts of vanishing prims and entire chunks of sims failing to load when changing group tags isn’t even related to it. Those bugs came about with project interesting a few months ago. Project interesting opened a major can of bugs and ever since its release not a single one has been addressed even in release candidates or sitting in publicly viewable repository waiting to be merged in for a project or release candidate to get out to users.
So again, the Lab does fix bugs at times. But they continue to fail miserably at getting out fixes for major bugs in even the slightest timely fashion to users. And in many cases they don’t even bother to fix the bugs themselves. They just wait months and months until TPV devs are sick of the bugs and then fix them to contribute them months later. Yet the gears at LL always keep chugging away at the next big feature and with each one always come a new mountain of bugs that they will leave unfixed for months on end or years.
LikeLiked by 1 person
I know that on the more and more pro Linden lab position of this blog my post will never see the light of day but let’s be honest and ask, how many will even bother to try these new tools until they are on firestorm or other tpv’s?
LikeLike
There is nothing “pro” LL about this blog just as there is nothing “anti” LL. I try to present a balanced, fair view based on fact rather than supposition and assumption.
As to how many will “bother” with Experience Keys depends on a number of factors, and not simply when the viewer-side code appears in TPVs. Right now the capabilities are still very much in beta among content creators, and they have been the focus of a fair amount of interest and questions at various user group meetings, hence Dolphin Linden’s frequent (of late) attendance at such meetings.
Currently, The Cornfield (and any other Experience which may pop-up) can be enjoyed by anyone, regardless of viewer; the Experience Keys project viewer simply gives an additional layer of information / trust.
LikeLike
Figured maybe you would like a response related to your very informative post rather than hijacking it to rant about “my personal issues with the lab/how I know better than them”.
Personally I’m very excited about getting my hands on the keys! We do a fairly involved survival horror game every Halloween and it involves a fair amount of teleporting as part of the experience and to do some load balancing across our sims. Normal scripted teleporters tend to fail during heavy server loads so we are forced to use scripted map teleports (open up the map to the new location and have the user press the teleport button). This gives us reliable teleports but causes some confusion with new players and obviously breaks the game flow. Can not wait to have simple system teleports based on a simple click or scripted event.
Great post as always 😉
LikeLike