New experience tools: details starting to emerge

LL have started releasing more information on the Advanced Experience Tools developed during the creation of Linden Realms and its predecessor game demonstrated at SLCC-2011.

The blog post (yay! BLOG post!) provides an overview of the new tools and permissions, with the video providing further information. Bear in mind when reading and watching that this is only an initial announcement and that as such, further information will be forthcoming…

The video delves a little deeper into the creation of the tools themselves and which includes some interesting factoids and tidbits of information.

One of the tidbits demonstrates the popularity of the Linden Realms game, which has 5,000 unique visits per day, for a total of 249,000 unique visits since the game opened in (I presume) Beta. Had the game relied upon a “traditional” means of HUD attachment via people’s inventories, the game would be generating 4 million new inventory items per month!

The tools discussed by both blog post and video are:

Teleport agent: this is a new LSL function that enables an agent (avatar) to be teleported automatically to a given location / destination. Within Linden Realms, this is used when people are “killed” by the various threats to their safety; within the video, the LL spokesperson suggests a further interesting use for the capability: the teleport “gun”…

The function supports both local and remote teleports and also respects teleport and access permissions.

Temporary Attachment: this functions is a similar manner to llAtach, but avoids the creation of an item within a user’s inventory. This has two benefits, the most obvious being that people’s inventories don’t get cluttered with items each time they visit a region where the function is in active use and the second, as an extension of this, the asset database itself isn’t overloaded with millions of requests (again, Linden Realms would be generating an estimated 4 million items a month if using llAttach). Attachments for both avatar and screen (HUD) are supported.

The blog and video indicate that temporary attachment is not  forced attachment, but a part of the overall Experience Permissions system.

LR Portal: a means of enabling the enhanced permissions system

Experience Permissions: this is a simplified version of the existing permissions system currently in use across the grid. Under the current system, permissions to control your avatar would need to be handled on a case-by-case basis. In something like the Linden Realms game, this means that rather than “dying” and being teleported on contact with a rock monster, the player would get a pop-up asking them if they wish to “die”.

Allowing these permissions to be granted requires action on the user’s part – such as walking through the Portals in the Linden Realms game, but they only need to be granted once, and can be applied across multiple regions (again, as with Linden Realms), allowing for large, continuous experiences to be built.

Permissions that can be granted (according to experience requirements) include:

  • Teleporting
  • Attaching objects to an avatar / screen
  • Control / track camera
  • Trigger animations

The permissions system is specifically geared to prevent more dangerous permissions such as inventory access, debit a user’s account and change links.

Potential Uses

The potential uses for these tools in terms of games and adventures are clear. However, there are wider applications for the tools, including:

  • Providing a means for guided tours within sims – providing avatars with HUDs that suggest directions around the sim, allow items of interest to be identified, information relating to those items to be displayed, and so on
  • Providing a means for store owners to enhance the in-world shopping experience  – including how demo items can be provisioned to users using the temporary attach option
  • The enhancement of more interactive experiences ranging across multiple regions.

Professional Creators Programme

In line with the new tools, LL will be launching a Professional Creators Program. Details on this are currently scant – the blog post simply states, “This program will provide members with helpful resources, such as tutorials and exclusive closed betas. More information will become available in the next few months”. However, Rodvik gave some pre-hints on this via Twitter a couple of months ago, and it seems likely the programme will, like mesh, require filing of some personal information with LL and perhaps taking some form or tutorial like the mesh status upload tutorial. From Rodvik’s comments, the requirements shouldn’t be that intrusive, but given the potential uses of the tools, are seen as precautionary against misuse.

For those wishing to be updated on news and information on the new tools, there is also an in-world Group  – the Advanced Creator Tools Notification Group  – which can be joined free-of-charge.

Appetites are bound to be whetted at this news (and there are already a fair few in the Advanced Creator Tools Notification Group already!) – and at the little teaser included in the blog post that LL have, “Produced a number of other tools and prototypes to support more rich content creation that we look forward to releasing”.

March Mesh Madness

March Mesh Madness kicked off on March 1st, and has caused some upset / confusion. The event “brings together unique mesh designs from 20 established Second Life”, and is open until March 15th, and has been organised by Damien Fate, himself a mesh designer, and is hosted on Fate Island.

Part of the confusion seems to be that people mistakenly took this to be an LL-sponsored event as it is currently appearing on the splash screens for those Viewers using the official splash / MotD notifications. As has been pointed out in the thread linked-to above, such MotD links aren’t that uncommon – they are pulled from the Destination Guide (wherein Mesh Madness is listed), and so seeing it linked their isn’t necessarily a sign of any LL collusion.

Anyway, I decided to jump over and take a look. The sim itself is nicely designed in a modern, minimalistic look, comprising a central arrival plaza with a display kiosk in each corner, surrounded by 16 more kiosks, four to a side to form a square, all linked by walkways over water. The majority of the build appears to be mesh (or at least partial mesh) and as such, one would expect it to be relatively low-lag.

March Mesh Madness at Fate Island

Sadly, this is far from the case. With just 12 avatars in the region, Fate Island exhibited more-or-less the same amount of lag experienced elsewhere with a similar number of avatars combined with the likes of multiple textures, vendors, etc. Rubber-banding was the order of the day.

In terms of the content on display, I’d have to say that things are – disappointing in some respects. Around twelve of the kiosks are devoted to clothing / footwear / accessories, with another three devoted to mesh hair and the remaining five offering up such items as furnishings, trees, and so on. There is little imagination shown with the various kiosks; most of which resemble mall-like slots, rather than attempts to showcase mesh. The one real exception to this is the Rustica kiosk, where Max Graf has (as ever) demonstrated his talent by producing a first-rate display of his mesh creations.

The Rustica display at Mesh Madness

Of course, one might argue that it’s easier perhaps for Max to produce such a display than others – his items are very much touch / feel, whereas clothing is more look / try. Even so, his kiosk and that of Organica, situated almost exactly opposite in the region, are the eye-catching units that tend to draw one to them.

As mentioned, the majority of the creations being displayed here are of the looks / try variety – clothing, accessories, hair, etc., and most of the vendor boards offer demo versions of items so you can try before you buy – and this is strongly recommended.

It would have been nice to see a more varied selection of mesh on offer here – whether the final selection was down to a matter of whosoever applied for a slot, or whether the event was specifically more geared towards the fashion / accessory side of things, I’ve no idea. Until Pamela Galli made mention of the event, I wasn’t even aware it existed, and only saw the MotD as I happened to fire-up Dolphin this morning while running my weekly Viewer version checks (I use Firestorm as a rule, so don’t get the MotD otherwise).

Obviously, a single-region exhibition doesn’t allow for large-scale displays such as buildings, but it would have been nice to see more in the way of furniture and perhaps vehicles, etc.

That said, if you’ve not tried mesh clothing / footwear / hair, this is a place to visit if you want to grab a handful of demos and give things a try before you plunge deeper into the world of mesh.

March Mesh Madness

Esbee and Charlar – gone

Tateru posts news that Chalar and Esbee Linden have both been laid-off from the Lab.

Sarah Kuehnle

Esbee – aka Sarah Kuehnle (nee Hutchinson) in real life, had previously had responsibility for the SL Viewer, prior to departing from the Lab in January 2011 of her own free will, but returned in June. While active on Twitter, her public-facing profile at LL was quite low following her return.

At SLCC-2011, she was part of the team that demonstrated some of the gaming mechanisms the Lab were then experimenting with (some of which eventually found their way into Linden Realms). During the presentation, it was announced that she would be taking-on the role of “Subject Matter Expert” for “role-play” – but so far as I’m aware, did not have a major user-facing roles as such, and didn’t host and user group meetings related to this.

I didn’t really “know” Esbee (as much as anyone can get to know Lab personnel), but we did swap a few tweets and other bits, and she always came across directly as someone who was warm and fun-loving, and I remember that at SLCC-2010, after coming in for a lot of criticism for the level of spin around Viewer 2, she Oz and Q had and open forum on the (then) new Project Snowstorm, and that by-and-large they were more aware of worries and concerns from both users and devs than perhaps they’d been given credit.

Charlar’s famous tree avatar

Charlar has had a fairly high-profile role at LL, firstly with regards to mesh, which rolled out last year, and then within the Content Creators group. He’s enjoyed something of a mixed reputation in the eyes of users, but I will say that I had the opportunity on several times to chat with him one-to-one, and we swapped ideas and points-of-view via profile direct messages, and I always found him to be polite, thoughtful and with a keen sense of humour.

News of the departures is bound to bring mixed reactions across the community. However, being laid-off is never a pleasant experience, so I certainly hope that both Esbee and Charlar find safe havens work-wise soon.

Rodvik blogs: No Last Names

So, Rodvik has blogged on the subject of last names.  In sort: they’re not coming back. The overall direction of the post is pretty obvious from the outset – that last names won’t be making a return just yet  – simply because the first couple of paragraphs ramble somewhat – as if Rodvik knows what he is about to say is going to draw howls of disappointment.

As the Lab can’t strike a balance between freedom of choice and pre-set last names, they’re not doing either. However, special characters are being introduced to the sign-up process to allow some degree of freedom. This means, as Rodvik says, the someone signing-up can be “Horatio-Nelson”; it’s a step forward, given that the Lab are also looking to expunge all last traces of “Resident” (and Rodvik has asked to be informed if people come across any) – but it’s a very small step.

I have to admit, I found the claim that pre-set last names appeared to cause more new-user sign-up angst than the current system surprising. Admittedly, it’s been  a long while since I signed-up, and almost as long since I was forced to create what is now my “crash test alt”, but I can’t ever remember feeling frustrated by being limited to a list of pre-sets (which was pretty extensive). Rather the reverse, in fact – I found I was dallying over the name selection as the available presets were intriguing – a make of name-up names, names from history and fiction, ethnic names, and so on which (I do remember) got me thinking on the whole question of identity and how I wanted to project myself in Second Life – what aspects of my personality, which interests, and then playing with various name options to see how they worked before I made my final choice.

But then, I’m weird like that.

So as the Lab can’t strike a balance between pre-set and free-form last names, neither will be making a return to the sign-up page for new users. In the meantime Rodvik will be kicking-off a new Profile Feed “round-table” to discuss recapturing the “frontier feel” of SL, probably next Monday. Interestingly, one of the ideas he put up for discussion what that of allowing new users pick from a list of pre-set last names after having been involved in SL for six months or so. Also offered-up for discussion is the potential to re-think Linden Homes (which I thought they were doing anyway…or did I simply dream I’d received a survey on linden Homes last month…?), and the idea for a new “Mainland-like region” – something that is bound to intrigue / cause concerns ahead of the actual discussions.

Rodvik’s post can be read in full here.

TPVP changes – Oz provides further explanation, Tateru gets answers

As concern over the latest TPVP changes continues, Oz has offered-up additional information on what section 2.k in particular means, and how it affects TPVs is terms of official Viewer releases, etc.

In a comment on the thread Questions about new TPV policy initiated by Cummere Mayo, Oz states:

Thanks for taking the time to pull your questions together, Cummere. I know a number of others have had similar questions, and I wanted to take a minute to address them here. I hope this will help clarify things.

1) What is meant by shared experience?

Making a simple statement that covers all possible cases is not easy … there is an unavoidable element of judgement in interpreting this rule; I’ll try to answer below, but that should not be taken as modifying the policy itself.  We will certainly help developers with proposals to understand whether or not a feature might fall under it.  It’s worth noting that the vast majority of all changes made by third-party viewers have certainly not been a problem.  The fact that there have been some problems in the past motivated our adding this rule so that in the future developers would work closely with us to prevent any more like them.

A shared experience change is one that modifies the definition of the elements that make up the virtual world, or how they behave, in such a way that users on other viewers don’t experience the same virtual reality.  

This rule does not affect changes to rendering, user interface, or the controls a viewer offers for interacting with the world.

2) What counts as the latest released Linden Lab viewer?  Do the Snowstorm and Beta viewers count as released?

The Release viewer is the benchmark, but the difference in time is normally quite small (a few weeks).  If the relative release schedules of our viewer and that of some TPV are causing a problem, then we will discuss making allowances for that if the stability of the feature makes that a reasonable thing to do.  The whole point of the Development and Beta viewer builds is to test things – which implies that those tests may reveal the need to modify the feature, potentially including changes that would not be compatible with the earlier version, so the likelihood of this kind of problem would have to be taken into consideration.

3) Does this mean systems like RLV and integrated AO’s are no longer allowed?

No.

4) Does this mean that third-party viewers may no longer experiment with and help test new features?

No – if the feature would fall under the 2.k rule, then it is faster and easier for everyone if the primary development and testing of it be done based on the common upstream code we make available to everyone, but parallel work by developers in test versions (not the default downloads) of TPVs will usually be ok as long as everyone (including the users of those test viewers) understands that the feature may change in incompatible ways, or even in an extreme case be withdrawn (such as if it is found to be harmful in some unresolvable way).

5) Does this mean that text only viewers or “voice only” viewers would no longer be allowed?

No – failing to provide a common feature is not the same as adding a new feature.   Users who choose to use such viewers are making a choice that is up to them. 

In terms of impact on TPV, the core paragraphs are:

A shared experience change is one that modifies the definition of the elements that make up the virtual world, or how they behave, in such a way that users on other viewers don’t experience the same virtual reality.  

This rule does not affect changes to rendering, user interface, or the controls a viewer offers for interacting with the world.

These give unequivocal clarification to a misunderstanding I’ve seen posted on a number of blog commentaries: that UI changes developed by TPV are unaffected by the policy update. To be fair to Oz, he made this very clear in the meeting last week when the changes were announced – but some commentators still seem to have the wrong end of the stick when it comes to UI changes.

To put it simply: the policy changed doesn’t impact on things like revised Build floaters, additions to the Snapshot floater (to upload to Flickr, for example) and improved Camera control floaters, etc. Similarly, things like object derenders are well outside the scope of the policy, as is the ability to audio or visually mute others (which is a concern I’ve seen raised elsewhere, despite the fact it is LL themselves who are introducing Visual Auto-mute), so people have no reason to worry on these scores.

I still find “shared experience” as defined in the policy itself to be far too vague – Oz’s clarifications notwithstanding; and it is the policy that will be used as a yardstick, not additional comments in a forum which may well be lost in archives over time. As such, it would be useful if wording such as Oz gives in the two paragraphs above were cited within the policy as examples as to where the line is drawn.

Better yet, I’d like to see the Lab take-up Tateru Nino’s suggestion. Over on her blog, she publishes the answers she has had to date on the policy changes (and if you’ve not read them, I urge you to do so). In particular Tateru suggests:

A well-documented baseline feature-set, that content-creators could refer to with confidence, would make a lot of sense, and probably be of broad utility and benefit…

Which is an excellent suggestion. Such a baseline document doesn’t have to be within the TPVP itself. LL have a wiki, and it could be placed there as a part of resources for TPV developers or those wishing to get into TPV development – as long as the policy provides a link to the baseline,then the needs of the policy are served and people get a clearer understanding as to what is “allowed”, etc.

Tateru’s piece raises the spectre of enforcement – and Section 8 of the policy is somewhat vague to the point of unpredictability, as Tateru states. It was an issue back when the policy was first introduced, and these latest changes bring those concerns back into focus. Again, providing an outline set of exceptions (say, alongside the baseline feature-set mentioned above) would go some way to further focusing developer’s thoughts and people’s understanding.

That said, and in fairness to LL, where problems have occurred with TPVs over the past few years, they’ve made every effort to sit down and discuss issues with the developers concerned, and provided opportunity and time for ways to be mended rather than simply dropping the hammer. As such, I doubt that they are going to stop any such dialogue as a result of these policy changes which may be required in the future. Again, as I’ve said elsewhere, LL isn’t the malicious ogre as can sometimes be portrayed.

I still have concerns that section 2.k will have an adverse affect on broader Viewer innovation than perhaps the Lab anticipates – which is not so say I don’t understand the reasons for the Lab taking this step (which Oz also moved to clarify in part in a comment he made in reply to my original piece on the policy changes). Hence why I feel that were the Lab to take one or two additional steps in the matter and provide a baseline functionality document, together with some examples of  potential exceptions that might cause problems (with any required caveats about such a list not necessarily being  complete, etc.), would actually help the wider audience of concerned SL users understand what is happening and why, as well as providing TPV developers old and new with a more solid foundation for their work going forward.

Related Links

Help the Lab help you

The recent TPV Policy changes brought with them the news that the functionality of llRequestAgentStatus, popularly used to obtain someone’s actual on-line status would be changed at some point in the near future as a matter related to users’ privacy.

The ability to determine someone’s on-line status has been the subject of debate for some time now, as evidenced by JIRA SVC-4823.  The JIRA itself has received a lot of attention since the news on the TPV Policy changes broke, which both highlights the level of concern where potentially legitimate uses of llRequestAgentStatus is concerned, but conversely doesn’t help the Lab clearly understand all cases where this is so.

Yesterday, Oz put on a request on the JIRA, thus:

Everyone…. I don’t know if this will help or not, but I’m going to give it a try and see….

We hear what you’ve all said, we understand the issues, and we’re going to discuss what we can and should do about them.

Nothing is final.

We appreciate that Phoenix is moving appropriately to remove the privacy violation from their next release, and hope that they’ll do that soon, but we understand that these things take time.

In order to help us to have a better understanding, I appeal to the many of you who are posting messages that essentially say “I agree – this will be bad for me too” as opposed to describing a specific use case not already described here (and thank you to the many posts that have done a good job describing use cases): please stop with these “me too” posts – they just make it harder to read the full stream (and yes, I at least am reading all of every comment). We know that for every use case there are many users… we don’t need each of them to post something

This is a fair and reasonable request, and while it is understandable the many want to add their name to one or more instances where the function does have a positive use, it’s also essential the LL get a fair chance to establish the how and where and what in terms of what needs to be done in order to avoid causing undue upset or pain in altering the functionality – if indeed this happens.

If you do have a potential user case that hasn’t been listed in the JIRA (or perhaps hasn’t been fully explained), then now is the time to help Linden Lab help you by providing a clear and concise explanation of how the function is used and how altering it could be detrimental to the SL experience. If you just want to add a “me too” comment, without specifics, I would encourage you to consider Oz’s plea and resist the temptation, so that LL stand more of a chance of sifting through the feedback and properly taking all they need to understand into account.

Again, you can reach the JIRA to add your examples by clicking here.