Sansar: Slip, Slide and Sit release (April 2018)

Ground sits come to Sansar

Tuesday, April 10th, 2018 saw the arrival of the Sansar Slip, Slide and Sit release. As the name implies, this update includes the first iteration of the ability to sit avatars in experiences. Yes, it’s a simple ground sit, but it’s a start. The release also sees further avatar gestures (aka “emotes”), script API updates and a reminder aimed at creators on the removal of the Terrain Editor.

As always, full details are available in the release notes, this overview just highlights some of the key features / items in the release.

Initial Notes

  • As with the majority of Sansar deployments, this update requires the automatic download and installation of a client update.
  • Changes to the avatar inventory support means that on logging-in for the first time following the update, users will be placed in the LookBook (Avatar App).

Terrain Editor Reminder

Starting with the mid-March release, the Lab has been discontinuing the use of the Terrain Editor. This is as a result of recent investigation in Sansar’s performance revealing the height maps created using the tool could adversely affect performance in both the Run-time and Edit modes.For creators who have used the Terrain Editor, this means:

  • All existing terrain created using the Terrain Editor or through uploaded heightmaps should be replaced by the end of April. After this date, all terrain items that are still in scenes will be replaced by a place-holder asset.
  • All terrain items in the Store that have been created using a terrain heightmap should also be removed from the Store as soon as possible.

There is at this time no indication as to if / when the Terrain Editor will be re-introduced.

Ground Sit and Avatar Gestures (/”Emotes”)

Sitting in Sansar

The ability to sit is Sansar has long been a request along those engaged in the platform. It’s been seen by the Lab as one of the more problematic issues to solve for, particularly for a number of factors.

Firstly, there is the question of where should avatars be able to sit? In the physical world, we can sit almost anywhere that’s sensible (and a few that are not!): on chairs, on stairs, on counter tops, on logs and rocks, up in the branches of trees, on the edge of a cliff, the railings of a bridge, in (and on) vehicles, and so on; and the Lab would like to have the ability in Sansar, and preferably without the need for custom scripting within the more “static” objects – railings, tree branches, rocks, etc., to make it possible.

Then there is the “realism” factor. It’s been expressed that rather than having people point-and-click to have a script and animation effectively “grab” an avatar and seat it, a-la Second Life, it would be preferable to have an avatar be able to “walk up and sit down” as we do in the physical world. But – how should that be handled? By a more subtle form of scripting that “goes through the motions” for the avatar? But how would that work for people in VR? Would it be disorienting to find their avatar under “external” control, however briefly, as an animation takes over movement? What about the physical confusion for VR users… standing and controlling their avatar, then seeing it sit, and perhaps instinctively trying to sit as well – regardless of whether a chair is behind them or not?

While having the ability to sit is nice, the use of a cross-legged pose for female avatars in skirts or dresses isn’t perhaps the best given the amount of potential knickers exposure and perhaps other problems

The one place we all can reasonably safely sit is on the ground – hence the first iteration of sitting in Sansar allows just that, with a simple “/sit” command. This activates a basic animation to sit your avatar cross-legged on the ground with arms resting on legs. To stand, simply hit a movement key, and your avatar will stand (and perhaps turn, depending on the key pressed).

In Desktop mode, the animation works well  – if you are wearing jeans, shorts, leggings, trousers, etc; if you’re in a skirt or dress, then it might not be so good and result in a case of knickers exposure and possibly other odd results if cloth physics aren’t employed in the skirt / dress.  I’ve also no idea how it works in VR mode (I assume a controller command) as the release notes make no mention, and I am sans a headsets to test it myself.

Cross-legged like this isn’t necessarily the most feminine of sits, so hopefully we’ll see some differentiation introduced – how about the more attractive leg tuck position for female avatars, LL?

New Gestures

Thee new gestures are added with this release. They are all self-explanatory:

  • /wave – a reasonable wave, although a little more emotion on the avatar’s face would not go amiss, given it is intended to be a Friendly GreetingTM.
  • /cheer – a two-armed cheer, which again given the lack of facial emotion seems (to me) to leave it devoid of any real feeling.
  • /lol – something of a belly laugh of the kind we’re used to in Second Life, just without the over-the-top doubling over. And it actually has (a bit of) a facial emote to go with it!
/wave, /cheer and /lol gestures / emotes

I confess these gestures / emotes provoke a mixed reaction in me. On the one hand, they add a degree of life to an avatar, on the other, the sheer lack of reflective facial emotion – a smile when giving a thumbs up or a wave, for example – tends to emphasise the mannequin-like artificiality of Sansar avatars, particularly for those coming to the platform from expressive environments like Second Life. Hopefully, this will improve in time, particularly if some means of providing a more comprehensive animation / animation override capability is made available.

It would also be handy if the commands themselves could be “hidden” from display in the local chat window. Seeing lots of “/thumbsup”, “/clap”, “/cheer” gesture commands littering the chat window is a) distracting, b) can result in a lot of frustrating scrolling back up the window when trying to read something someone wrote.

Other Updates

  • VR mode arm IK improvements: a set of updates to improve arm ikenema in VR mode. Again, lacking a VR headset, I’m unable to test these, nor have I seen anyone with a headset since the release in order to see if the improvements are visible.
  • Marvelous Designer clothing updates: it is now possible to pin sleeves and scarves up in cloth simulation mode, and to pull zippers up or down.
  • Lighting updates: all properties on lights can now be changed by scripts.
  • Physics updates: a number of physics updates including new APIs to adjust nearly every physical property of objects at runtime; the ability to define motion types of models on import, and friction and bounce settings on static objects. The Sansar Script API documentation provides more information.

Feedback

Another compact release focusing on building out capabilities rather than adding a lot of new features. Like the March release, it’s unlikely to get those outside of Sansar feeling a “wow!” factor – but that’s not the intention. My own thoughts on things are given above, so I won’t repeat them here.

Advertisements

Sansar Product Meeting #12/1: publishing and access control

Radio Grind presents…The Experience: Part V The Dirty Grind IAC Live Music Venue & Listening Lounge – scene of the March 20th Product Meeting

The following notes are taken from the Sansar Product Meeting held on Tuesday, March 20th. These weekly Product Meetings are open to anyone to attend, are a mix of voice (primarily) and text chat. Dates and times are currently floating, so check the Meet-up Announcements and the Sansar Atlas events sections each week. Official notes, when published can be found here.

A portion of the meeting looked at the mid-March update, which is covered separately here. The latter half of the meeting was also  an extended  – and at times confused – general discussion on access control. Part of this did highlight the benefit of more scripted capabilities for access control and persistence of scripts, etc., (e.g. limited ban times, rather than a one-time “forever” ban until revoked; or the ability to apply the same access control list across multiple experiences). The discussion did not draw specific conclusions, but highlighted the potential for more focused discussions with specific product experts in the future.

Given the above, these notes focus on the core feedback provided by Boden and Jenn in terms of how the Lab views things.

Publishing on Sansar

There is some concern in the Lab that the current route to surfacing an experience is potentially confusing for some creators, in terms of knowing whether or not their experience is actually listed.

The current flow is to go to the publishing options, which opens on the Who Can Visit tab (below left), where the general access options can be set (Public, Only Me, by lists – Friends, Guest, banned).

The user then moves to the Atlas Listing tab (below right) – the first option of which is set to Hide This Experience From The Atlas by default, which unless unchecked, means the experience will not be surfaced in the Atlas, regardless of anything set in Who Can Visit – hence the confusion.

By being checked by default, is the Hide This Experience From The Atlas causing confusion when publishing an experience?

This led to an extended conversation about access, terminology (e.g. given a scene has a URL, isn’t that technically “published” anyway, regardless of the status of the experience?), options, etc.

Purely in terms of dealing with the confusion over whether or not an experience can be seen in the Atlas, the simplest approach would seem to be to leave the Hide This Experience option unchecked – this would also then more accurately reflect the explanatory text given with the Why? link.

Tool Tips

The suggestion was put forward that why going forward, and allowing for complexities of language localisation, etc., the Lab should look to ways to offer tool (or hover) tips within elements of the UI to help users better understand options and buttons.

Access Control Roadmap

In terms of access control to experiences / events, the current order of things at the Lab seems to be:

  • Implementing the underlying infrastructure to allow event ticketing.
  • Then build-out the tools to allow pay-to-access events (this will initially be internally / possibly with partners, prior to the tools being publicly surfaced).
  • Then, depending on how demand for events grows, go on to provide:
    • Experience / event owners to appoint moderators for their events, who can help manage the actual event (e.g. remove people causing problems).
    • Event organisers to rent experiences so they can host events without necessarily having to build a dedicated experience / contract someone to build it.

Does Access Control Mean Adult Content May Be Allowed in Sansar?

  • Currently no. Linden Lab’s Terms of Service, Sansar Terms and Conditions, etc., remain unchanged.
  • While access control may offer a step towards allowing adult content, there are other factors still to be put into place (e.g. age verification – something which could affect the experience owner as much as LL).
  • As the product is still in a “beta” status, the Lab is sensitive towards how it is perceived in the media (understandably, given the history of SL and certain elements in the media).
  • Adult content may come in the future, as Sansar grows, particularly as the environment means there is not necessarily the kind of “link” between moderate and adult content as might be seen with Second Life, simply because spaces in Sansar can be clearly separated one from another.

Other areas of consideration include the Sansar Store, and how Adult material would be handled there: would there need to be a separate Store for such content?

While no final decision on adult content has been made vis Sansar, Boden pointed out that the steps being taken now in enhancing access control, providing the means to support groups with different interests and requirements, etc., could eventually lead to adult content support as Sansar matures.

Access Control & Dress Code

In early discussions on Sansar, Ebbe Altberg raised the idea that experience creators would be able to define what outfits could be worn in their experiences, if they wished.  So for example, a steampunk themed role-play experience might require visitors to be dressed in appropriate costumes, thus avoiding the immersive nature of the experience being broken by someone waddling around as a pigeon toed under grown flying purple people eater (so to speak). This is apparently still on the roadmap for some point in the future.

Sansar Product Meetings #11/1: mid-March release news

Pierre (centre, in sunglasses) and Cara (to his left, with wings) discussing the upcoming mid-March Sansar release on Tuesday, March 13th at Skye Naturae Virtualis

The following notes are taken from the Sansar Product Meeting held on Tuesday, March 13th. These weekly Product Meetings are open to anyone to attend, are a mix of voice (primarily) and text chat. Dates and times are currently floating, so check the Meet-up Announcements and the Sansar Atlas events sections each week. Official notes, when published can be found here.

Originally, the subject for the meeting had been listed as being the Sansar avatar. However, this was updated to a discussion about the upcoming “mid month” Sansar release.

Overview

March 2018 will see a “mid-month” release for Sansar – the exact date is still TBA, and it is being made because  a number of features are available earlier than the Lab had anticipated, and which Linden Lab is keen to get in front of users.

The following is a high-level overview of what to expect. Obviously, I’ll have more information on this when the release is deployed, and the release notes are available.

Performance Improvements

The Lab convened a “strike team” to address a number of performance issues, and the upcoming release should be marked by a umber of performance improvements.

Terrain Editor and Performance

One of the findings from the performance investigations is that the terrain editor used to sculpt height maps from within Sansar, and the terrains edited using it, can have a significant performance impact in both Edit and Run-time modes. There is no quick fix for this at present, as the terrain editor requires a significant amount of work, and the resources aren’t available at the moment. Because of this:

  • The terrain editor will be disabled with the next release.
  • There’s no date as to when a replace terrain editing system will be implemented.
  • Between now and the end of April, creators who have extensively used the terrain editor and height maps to produce terrain in their scenes / experiences, will be asked to remove / delete their existing terrain sculpts with tiles made via alternative means (e.g. custom made externally and uploaded for “as-is” use).

Pierre outlines the terrain editor issue

This means that with the mid-March update:

  • It will no longer be possible to upload new height maps.
  • It will no longer be possible to list new height maps on the Store, either uploaded or those already in inventory.
  • Creators who have placed height maps on the Store will be asked if they could unlist them to prevent people for purchasing them and using them in their scenes.
  • It will no longer be possible to paint, sculpt, reposition, rotate, etc., terrain in  scene.
  • It will no longer be possible to pull terrain sculpts from inventory for use in a scene.
  • Terrain elements will still work as expected in published experiences, but again, they will not be editable within the experience’s scene.

Then, between the mid-March update and the end of April:

  • Creators will be encouraged to remove / delete custom terrain sculpts as noted above, and replace them.
  • Terrain maps not removed by the end of April will be replaced by a place-holder item.
  • To help people get to grips with creating and uploading terrain elements, the Lab will be providing a new Sansar knowledge base article.

Feedback from those at the meeting:

  • A request has been made that the Lab allow higher resolution textures to be used with uploaded terrain tiles, particularly where larger experiences are concerned.
  • Another request was made for the Lab to make at least some of the scene template elements (e.g. the rocks and cliffs) available through the Store so that experience creators would have some “pre-built” terrain elements they could use.

Both ideas are being taken back to the Lab for consideration.

Events Creation

As reported in my week #10 update, with this upcoming release it will be possible for Sansar experience owners to create their own event listings.

  • The option to create an event – a meet-up, game, tour, and so on will only be in the client (it will not be possible to create events from the web).
  • Using the client, it will be possible to set the location, date, time and duration of an event (presumably with some form of description, although this wasn’t specified in the meeting).
  • Once created, all events will be displayed in both the client Atlas events section and on the Sansar Events page.

Scripting Improvements

Script Update Capability

With the upcoming release, scripters will be able to offer updates to their scripts listed on the  Sansar Store. The basic process will be:

  • Update the script and upload it to inventory.
  • In the client, locate the revised script, right-click on it and select the “Replace Item on Store” option.
  • This will take the script creator through a workflow to replace an existing script associated with a Store listing with the updated script.
    • If required, the listing can also be updated to include release notes or details of changes made to the script.
  • Those who then wish to update their versions of the script can then go to the store and download the update (which will be added to their inventory without deleting / replacing the original version) or, if they prefer, just keep using the original.

This functionality has been implemented and is being deployed to help with situations where changes to Sansar’s evolving script APIs can result in scripts being broken following updates. other options for updating goods on the Store will come in the future.

C# File Size Increase

With the upcoming release the file size for C# script files is increased to 1 MB.

LookBook Update

When using the LookBook to view your own  avatar accessories for listing purposes, etc, the green corner button will be replaced by a right-click option, which should also display the item name.

Continue reading “Sansar Product Meetings #11/1: mid-March release news”

Sansar Product Meetings #10: events in Sansar

Sansar: The Whyst Garden – blog post

The following notes are taken from the Sansar Product Meetings held on Tuesday, March 6th and Thursday, March 8th. These weekly Product Meetings are open to anyone to attend, are a mix of voice (primarily) and text chat. Dates and times are currently floating, so check the Meet-up Announcements and the Sansar Atlas events sections each week. Official notes, when published can be found here.

The subject for both of the week #10 meetings was Events in Sansar. These notes are an attempt to bring together the key points of discussion from the meeting note that they represent discussion points, not necessarily ideas the Lab will be implementing in Sansar.

Changes to Event Submissions

Currently, the process of adding events to the Sansar events calendar (visible on the Web Atlas events page, and within the Client Atlas) is via e-mail submission to Linden Lab.

  • This will be changing soon to allow users to post their events directly to the events listings.
  • However, the option will initially be limited to hosting events in a user’s own experience – it will not be possible to post events taking place in an experience run by someone else.
    • This is primarily to prevent issues of people trying to unfairly monetise other people’s experiences.
    • Once there is a means for splitting revenue between event organiser and event “host” (experience creator), this restriction would likely be lifted.
    • As an alternative, LL might consider ruling that events can be held in any public experience, but where the experience creator is not the event organiser, than the event must be free of charge to access.
  • Some time after the events submissions process is revised, the system will be expanded to allow people to invite other users directly to their events.

How Should Events / Event Access Be Governed?

Controlling who can access events is still under discussion, with the Lab courting feedback on ideas for how this might be managed.

  • The Lab’s thinking is that there should be two broad categories of events:
    • Public – as in anyone can attend (subject to the payment of any associated access costs)
    • Private – the event is restricted to a defined access list / via invitation for the event host / experience owner only.
  • The above could be expanded  to a more defined set of event types that experience creators might use to define their events (e.g. live music, DJ / Dance, etc.,).
    • This is seen by some as potentially limiting and requiring additional management overhead (maintenance of the central list to suit all needs; experience owners having to resign “allowed” events depending on what they want in an experience at any given time, etc.).
  • There has been a feature request for the Lab to provide event-focused access control lists (ACLs).
    • A single ACL could be used to control access to multiple activities of a similar nature across multiple experiences.
    • Combined with the idea of scene “privacy volumes”, ACLs could be used to control access to content with an experience (e.g. there is a puppet show in the experience, but casual visitors don’t get to see / enter it, as it is within a privacy volume, until they “pay” an entry booth, which then adds their information to the controlling ACL – and they can access all other puppet shows controlled by the same ACL).
  • A counterpoint to this is that if better persistence of data is provided by LL – such as an API to allow experience creators to store data in an external database -, then such “hard-coded” ACLs would not be required, and experience creators could script them.
    • There are questions as to how user-friendly would individually coded access lists be; how would they scale, etc.

Accessing Events and Event Instances

Instances of experiences are capped for the number of users able to access them. No hard limit has been officially defined, although the number is currently around 30, and the Lab has indicated they are aiming to perhaps have 100 avatars active within an individual instance of an experience.

However, when attending events, this does raise questions, including:

  • How can large numbers of people witness a single event?
  • How can people wishing to attend an event together be sure they will be able to access the same instance of that event, and thus share it?

To address the first question, the Lab has already raised the idea of having a “broadcast” or “parent” event.

  • This would be the primary instance of an event (e.g. a live band performing on stage, a presenter on stage addressing and audience, etc.), which broadcasts out to multiple instances of the event as they are spun-up to meet the needs of the audience numbers.
  • Those in the “audience” instances might not be able to communicate into the “parent” instance or directly interact with avatars in other “audience” instances (e.g. dance with them) – but they would see / hear everything going on in the “parent”.
  • There is currently no time frame on when this capability might be introduced.

To address the second question – people being able to access the same instance of an event together – the Lab is looking at various ideas, including:

  • Access based on group size / queuing: people define themselves as a group, and effectively access an event together, allowing them to be sent to the same instance.
  • An “event lobby” system where users can see where they could go in order to be together.
  • The ability for people to directly invite one another into an instance of an experience.
  • Some combination of all of the above.

Monetising Events

The ability to monetise events – particularly events hosted in experiences created by someone other than the event host – is unlikely to occur until the supply chain / licensing system has been deployed. However, some ideas for monetisation that have been put forward include:

  • The ability for people to “rent” experiences built by others for a specific event / specific period of time.
  • The ability to make the “parent” instance of an event a “premium” experience, where people pay extra to be in it and able to interact with the performers / presenter(s) – so they could, for example, ask questions during a presentation.
  • The ability for people to charge subscriptions to events / activities.
  • The ability for event hosts / experience creators to define a specific “event” scene of a public experience.
    • This “event” version could be “reserved” for those paying / allowed to access the event (e.g. a dance, a hunt, a game, etc.), and instanced accordingly.
    • Anyone not paying the admission fee go to a “normal” instance of the experience which does not have the event running within it.
    • However, creation of such an “event scene” of an experience would still count against the creator’s allowed total of published experiences, even if it is effectively a “copy” of an existing published experience (although the scene could obviously be unpublished after the event).
    • A suggestion put forward to offset hitting the cap on the number of published experiences a creator can have, is to allow a creator to pay a nominal fee to have an “extra” experience published for a specified period of time, before it then goes away.

Monetising events touches on the wider aspect of monetising experiences in general, and during the meetings the Lab re-iterated that coming on the roadmap is:

  • The ability for creators to build and sell entire scenes / experiences.
  • The ability to offer direct tips in Sansar Dollars (which encompasses both events and experiences).
    • This is seen as more relevant at this point in time than offering a means to pay wall experiences.
  • Possibly the ability for experience creators to charge people wishing to access their experiences.
    • This does raise the question – as the Lab acknowledges – of how do users gain an assurance that the experience / content is worth paying for in order to view it?

Continue reading “Sansar Product Meetings #10: events in Sansar”

Sansar Product Meetings #9: interactivity

The Wednesday February 28th, 2018 Product Meeting

The following notes are taken from the Sansar Product Meeting held on Wednesday, February 28th. The subject for the meeting was Interactivity in Sansar, although more than this was covered. These notes are an attempt to bring together the key points of discussion from the meeting.

These weekly Product Meetings are open to anyone to attend, are a mix of voice (primarily) and text chat. Dates and times are currently floating, so check the Meet-up Announcements and the Sansar Atlas events sections each week. Official notes, when published can be found here.

Bust a Move Release and Update

  • The Bust a Move (February) release was made subsequent to the meeting, which includes some of the updates indicated in the meeting – these have been noted below.
  • An update to the Bust a Move release was made on Friday, March 2nd, 2018, specifically aimed at fixing the issue of complex Marvelous Designer clothing items exploding briefly when entering cloth simulation mode.

Roadmap Notes – Interactivity

Aleks summarised the following as the key points for interactivity in Sansar the Lab has deployed , or is looking to, deploy and build on, over the coming months.

  • Keyframed motion type: introduced with the Bust a Move release on March 1st, which allows objects to be moved by object animations and certain script API functions.
    • This means that, while they are capable of movement, they are unaffected by gravity, cannot collide with static or keyframed objects, and can collide with dynamic objects and avatars, but are not moved by them.
    • Keyframed objects are useful for creating things like doors, that need to perform a specific motion reliably without adding unnecessary strain to the physics simulation.
    • It is acknowledged by the Lab that “keyframed” in this context is perhaps not the best descriptor for the functionality, and it may be changing to “scripted objects”.
  • A New Dynamic objects flag: used to determine if a dynamic object can be picked up or not.
  • Gravity / Centre of Mass:
    • Initial gravity scaling (0 through 5x “normal”) introduced with the Bust A Move release.This is straight up-and-down gravity.
    • Does not affect animations / locomotion, etc., at this time (a walk in 0 gee will be the same as in 1 gee, for example).
    • Ability to set centre of mass of objects and adjust the mass of objects via script will be coming.
    • Cylindrical and / or spherical gravity are not being worked on at this time.
    • Opens the case for avatar jumping / flying.
  • Friction and bounce controls to be made available for both terrain and objects surfaces. So ice will be slippery, a lead cannon ball many be set so it doesn’t bounce, but a rubber ball does, etc.
  • Scripted object interactions: this will allow creators to define what items  support interactivity, and how users can interact with them.
    • Will likely take the form of some kind of indicator which is visible when a mouse pointer (Desktop Mode) or hand (VR mode) is over the object, perhaps with a little tool-tip outlining the available interaction.
  • Manipulation abilities: the Lab is investigating how best to allow creators to define how items are held (e.g. a rifle and a hammer have different means of being held, one to the other) and for users to manipulate the objects they are holding (left hand? right hand? swapping between hands? etc).
  • Resource containers: objects that can be used to contain all of the sounds or animations or textures or rezzable which might be used in a scene, which can then be called via script as needed.
  • New interaction API: to provide abilities such as touching a button to change the colour or intensity or brightness of a light, or pull a lever, etc.
    • Again such capabilities will be introduced iteratively over time.
  • Scripted animation of textures: the ability to animation multiple textures on a surface, and potentially hook-in to a flipbook of textures.

Persistence Across Sessions

  • The Lab is looking at how to handle data persistence across sessions in Sansar (e.g. progress to date in a quest, or points scored in a game, etc.).
  • It’s not clear if this will be something handled internally with experiences, or by providing experience creators with some form of API, allowing them to create external mechanicals to store such data.
  • Seen as a capability which will be added once more in the way of game creation capabilities have been added to Sansar.

Particles

  • Not on the immediate  roadmap, and viewed as a “nice to have”, but not a priority at this point.
  • Are being considered with regards to emotes, e.g. type or say “smile” and a smiley pops up over your avatar or similar.
    • (Quite how this wouldn’t be as “immersion breaking” as having an unobtrusive voice indicator illuminate over an avatar’s head when voice is being used, as some at the lab claim, totally escapes me.)

Scripted Animation

  • Comprehensive scripted controls (start, stop, select a frame, change speed, etc.) for animations (and eventually leveraging the ability for .FBX files to contain multiple animations?) are being developed.
  • Initial work will be to provide scripted access to one animation on an object, rather than being able to control multiple animations.
  • The ability to swap between different sets of animations is acknowledged, but seen as “further out”.
  • This should allow for a range of NPC-style creations which can respond to avatar proximity.

Permissions System / Supply Chain

  • Still being worked on by the Lab.
  • Seen as a “sticking point” for many capabilities  / options within Sansar.
  • Currently prioritised is a script update system.
    • This won’t extend to objects, which will eventually have their own update mechanism.
    • It is not an automated update process (i.e. a new script is released and all previous versions are automatically updated).
  • Overall, the permissions system / supply chain is split into a number of areas, none of which is set for deployment in the near-term.

Performance Improvements

  • Voice is being revised so that when in an experience, only the voice data for those you can hear speaking is sent to the client, rather than voice data for all users in the experience, regardless of whether or not you can hear them.
  • Avatar LODs are also being looked at to help reduce the amount of avatar data being transferred to the client (do you really need to have every single tri in an avatar’s hair rendered when they are 300 metres away?).

Sansar Bust A Move (Feb 2018) release

Female dancing in Sansar Desktop mode – part of the Bust a Move release

The Sansar release for February 2018, called “Bust  A Move” was deployed on Thursday March 1st. This release builds on some capabilities added in recent Sansar releases, as well as adding some new capabilities. to the mix, notably for experience creators, but also to help improve with user-user engagement.

The release notes provide full information on the new features, updates, documentation changes and resolved / known issues within the release. The following is a general overview of the update’s key changes.

Initial Notes

  • As with Sansar deployments, this update requires the automatic download and installation of a client update.
  • One launching the client the first time, following update, the log-in splash screen’s Remember Me option will be unchecked, and needed to be re-checked for log-in information to be correctly retained by the client.
  • Changes to the avatar system (e.g. avatar emotes) means that on logging-in for the first time following the update, users will be placed in the LookBook (Avatar App).

Experience Access Controls

The new means of controlling who can access an experience have been introduced with the Bust a Move release:

  • Only Me: only the creator can access the experience.
  • Guest List: only those defined on an access list will be able to see the experience in their Atlas, and access it, regardless of whether or not they are on your Friends list.
  • Ban List: maintain a list of individuals specifically banned from accessing an experience (they will not see it listed in their Atlas).

These options work alongside the existing options of making an experience open to anyone, or limiting access to only those people on your Friends list, and are set when publishing an experience.

The default published status for an experience is to have to open to everyone, and with only the ban list active (if used). To change this:

  • Either edit the experience and select the Publish option or from the My Experiences list, click on the Publishing Options buttons for the experience you with to update.
  • Make sure the Publishing Options > Who Can Visit tab is open (if not already selected).
  • Use the top drop down (Everyone, Only the Following, Only Me) to set the initial level of access to the experience.
  • Selecting Only the Following allows you to limit access to an experience to friends and / or a guest list (both can be set together).
The updated experience access controls mean you can now define access to an experience by both your friends list and / or a guest list, according to your preference of using one / the other / both in combination.
  • Note that any experience you have set to access by friends only and / or a guest list will appear in your Atlas with a yellow icon in the top right corner of their Atlas image.

Creating either a Guest List or a Ban List comprises the same basic steps:

  • Click on the required Edit List button. This opens the list, which will display the names of anyone already added.
  • Click the Add button to add further avatar names / avatar IDs (no “@” required for the latter) and click Search.
  • Click the correct name in the list box (if more than one) to highlight it, and then click Add Selected to add them to your list.
  • Repeat for each new name; click Done when finished, to return to your updated list.
  • Click Save to save the list.
Adding people to a guest or ban list both follow the same basic steps

Names can be removed at any time by clicking on any name in a list to highlight it, then clicking the Remove button – note that no confirmation is required.

Bookmark Favourite Experiences

Users can now bookmark experiences for display in a Favourites tab within both the Client and web Atlas. To add an experience to your list of favourites:

  • Display the information page for the experience in either the Client or web Atlas.
  • Click on the heart icon to add the experience to your list of favourites. The icon will turn a solid white, indicating you have added it to your favourites, and the Favourite count for the experience will increment by one.
  • To remove an experience from your Favourites, display the information page for the experience and click the heart icon again. It will no longer appear solid white, indicating the experience has been removed from your favourites, and the Favourite count for the experience will decrease by one by one.
You can add any visible experience in the Atlas to your list of favourites by clicking the heart icon in the experience description page (arrowed). This will also increment the number of favourites for the experience (circled, lower left corner)

Avatar Emotes

Using the “/clap” animation / gesture / emote. Courtesy of Linden Lab.

A rudimentary set of “avatar emotes” (that’s basic animations to you and me) have been added for Desktop mode with this release.

Triggered by nearby chat commands, three basic animations are provided:

  • /clap – Causes your avatar to clap its hands for a few seconds.
  • /dance – Causes your avatar to perform a short dance.
  • /thumbsup – Causes your avatar to give a “thumbs up” gesture.

The dance animation perhaps leaves the most to be desired, bringing to mind as it does visions of the hoary old “dad dancing at a wedding” visual gags. The clapping is (for me) the most effective, and the thumbs-up sitting between the two.

The Lab has indicated that more sophisticated means of animating avatars will be coming down the pipe, so regard these options as just a first step along the way towards more expressive avatars.

Chat Improvements

It is now possible to access the chat app from experience load screens and the Atlas, allowing conversations to continue more broadly across Sansar.

Continue reading “Sansar Bust A Move (Feb 2018) release”