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”.

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.

Pathfinding prepares to blaze a trail on Aditi

Update: Linden Lab have made an initial annoucement regarding pathfinding.

In his December 2011 address, Rodvik touched on some of the work Linden Lab would be continuing through the early part of 2012  – such as performance and stability – and outlined some of the new features we can expect to start seeing in 2012. Of the latter, he particularly highlighted pathfinding, by saying, “For creators our first new feature for 2012 will be pathfinding. Because worlds feel most vibrant when they are full of life, one of our next focuses for Second Life is the ability to make high-quality “life” within it. So in 2012, we will be rolling out more advanced features that will allow the creation of artificial life and artificial people to be much smoother. For starters, in Q1, we’ll unveil a new, robust pathfinding system that will allow objects to intelligently navigate around the world while avoiding obstacles.”

NPCs: Alpha testing on Aditi soon?

Details of this new capability, aimed towards what are popularly referred to as Non-player Characters or NPCs, is now beginning to emerge.

Rand Linden has updated the pathfinding overview page on the SL wiki to provide initial information, together with an outline pathfinding API page. There is also a set of alpha release notes which suggest that people will be able to start testing the new capabilities on the Beta grid and include a bullet list of currently known issues.

The API and overview pages give insight into the LSL commands that are to be associated with pathfinding – most notably llCreateCharacter, described as, “Convert the current linkset to an AI character. By default, the character’s shape will be an upright capsule approximately the size of the linkset, adjustable via the options list. The linkset must use mesh accounting”, as well as associated commands intended to assist in various modes of movement (and evasion).

The overview page is interesting in that it gives more information on the fact that pathfinding will not itself animate an NPC:

Pathfinding is not an animation system. It does not provide a way to animate a biped or quadruped in conjunction with the new movement functionality. You must use existing methods to animate characters. Nevertheless, pathfinding enables more dynamic movement and provides a better system for controlling character movement than was previously possible. For more information on creating animations, see Animation.

The alpha release notes provide a list of the Aditi test regions however, at the time of writing none appear to be open to public use as yet – I was unable to access any of them earlier today, either via the World Map or via the use of the Address Bar within the Navigation Bar of the Viewer. The four regions in question are (SLurls):

• PathTest1 (secondlife://Aditi/secondlife/PathTest1/131/101/23)
• PathTest2 (secondlife://Aditi/secondlife/PathTest2/100/170/26)
• PathTest3 (secondlife://Aditi/secondlife/PathTest3/103/127/23)
• PathTest4 (secondlife://Aditi/secondlife/PathTest4/127/194/29)

Given they are on the Beta grid, the most obvious way of accessing them is to log-in to Aditi and use the World Map to locate them prior to teleporting.

According to the alpha release notes, the pathfinding commands will only be available on these regions, which appear to include various obstacles and courses NPCs using the functions can attempt to negotiate.

Pathfinding regions

A pathfinding tutorial is also in the offing, although the page for it is currently little more than a placeholder at present – again, expect more updates as they become available.There is also a wiki index page for a category of pathfinding, which should be of assistance in quickly locating the broader information on the subject as well as details of specific dedicated or associated LSL commands.

From this, it would appear that LL are pretty much keeping to the schedule outlined by Rodvik at the end of last year and that by the time you read this, the pathfinding test regions on Aditi may well already be open to public access. For those who are keen to get involved in the project, the updated wiki pages are worth keeping an eye on in lieu of more direct information coming through other channels, such as the blog or technology forum.

With thanks to Nalates Urriah.

Visual Auto-mute: a farewell to ARC/ADW upsets?

A new set of functions has been released by LL as a changeset, and is starting to find its way into SL Viewers.

Essentially, this functionality allows you to set thresholds above which avatars with a very heavy load (high-res textures, complex attachments (multiple prims, flexi prims, sculpts, and what have you), etc., – but not scripts, which are a completely different kettle of fish) will not be rendered by your Viewer. Instead, such avatars will appear as “grey ghosts”, similar to when they’ve been muted; however, IMs and chat can still be exchanged. This should theoretically reduce the load placed on the Viewer and a your system in terms of rendering, and lead to an improved SL experience.

It’s important to note that the functions only affect how such avatars are rendered in your world-view; they will still render normally in their own view, and for anyone who hasn’t set thresholds / has higher thresholds than you. Also, your avatar will remain visible in your view, no matter how you set the limits.

The thresholds are governed by two functions, initially released by LL as a set of debug settings:

• RenderAutoMuteByteLimit – Maximum bytes of attachments before an avatar is automatically visually muted (0 for no limit)

• RenderAutoMuteSurfaceAreaLimit – Maximum surface area of attachments before an avatar is automatically visually muted (0 for no limit)

These currently require numerical values to be entered. However, it is possible that they’ll find their way into at least some Viewers as Preferences options, possibly using sliders. Zena Juran has already opted for this approach with the latest release of the Zen Viewer (below).

Visual Auto-mute as presented in the Zen Viewer

The functions are supported by a new addition to the Develop menu: Render MetaData->Attachment Bytes. When active, This displays a set of figures over / near avatars, which can be used to help you to determine the byte and area thresholds you should set.

Rendering Metadata->Attachment Bytes display enabled

The approach has already come in for considerable discussion on the SLU forum, where opinion seems to be weighted towards the favourable.

Certainly, it can’t be denied that avatars can impact Viewer performance enormously, so any moves that enable the user to have a greater degree of control over what is hurting their SL experience is potentially a good thing. But lag is a very sensitive subject – as anyone who has encountered upsets in the past due to people using ARC as a Big Stick can testify.

This approach would appear to be a lot more beneficial than something like ARC and its successor, Avatar Draw Weight (or ADW) are concerned, as it should hopefully reduce the amount of finger-pointing and hostility that goes on when people have arbitrary figures in red floating over their heads like a glaring accusation of wrong-doing.

It’s also somewhat friendlier than the other alternative to “blocking” “overloaded” avatars: that of audio mute, which denies any communications capabilities where some might be preferred and which can, if done on a group basis, leave a poor soul ostracised in silence with no idea why.

There are, however, some drawbacks. On the minor side, it is possible that setting the options when entering a popular venue may well result in you finding one or more friends around you turn into grey ghosts  – or that you end-up greyed-out in their view. This might in turn result in strained relations, but shouldn’t really be anything reasonable people can get past – and even joke about privately.

This isn’t necessarily a “one size fits all” solution as well; it is possible that, depending on the type of venues a person visits (in terms of popularity popularity, nature of the activities carried out, etc.), the thresholds may need adjusting from time-to-time in order to gain the best benefits / compromise in terms of performance benefits and visual appeal. This may limit the scope to which the new functions are used, as people are not always willing to fiddle around with sliders as they teleport around SL.

It also needs to be remembered that avatars aren’t the only load placed on the Viewer, and using functions like these might not help tremendously when moving around an environment that has dozens upon dozens of high-resolution textures all over the place (such as a store or mall). In this regard, the effectiveness of the system needs to be balanced against alternative approaches (such as the use of avatar imposters, or by simply turning-down your draw distance and turning down / off various options within the Viewer Preferences) in order to improve one’s in-world experience.

The biggest question-mark over the new controls, however, is that of effectiveness. If the results of playing with the new options is an improvement of a couple of fps in overall performance and/or a very slight improvement in rendering time, then it is unlikely that they are going to gain a lot of traction. But if people see a demonstrable improvement in their overall experience, then it is liable that the functions are going to prove more popular.

That said, anything tha moves us further away from the finger-pointing extremism that has been the plague of ARC /ADW, has to be a step in the right direction, doesn’t it? One possible benefit from this approach is a greater awareness and consideration of just how one’s own avatar might be impacting other people’s experience within SL, simply by seeing that it exceeds the thresholds one is setting against other avatars.

Well, one can hope, can’t one?