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.


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.


  • 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 Product Meetings week #8: communication

Sansar: Treehouse Overlook

The following notes are taken from the Sansar Product Meetings for 2018 week #8,  held at 14:00 PST on Tuesday, February 20th. Unfortunately, illness kept me from attending the second meeting on socialisation, held on Thursday, February 22nd.

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.

Communications – Ideas from the Lab

The following is a list of some of the communications elements the Lab is actively investigating for Sansar. Note none of the following currently has a delivery time frame associated with it.

  • Group chat: somewhat similar in nature of SL conference calls: starting an IM with someone and then inviting others into it, to allow a select number of people to jointly converse together privately in Sansar as a whole (e.g. when in an experience or browsing the Atlas or working in LookBook).
  • Multiple instance communications: currently, users can only converse with one another in open chat if they are all in the same instance of an experience. The Lab would like to broaden this to allow some form of open chat between users in different instances of the same experience.
  • Broadcasting: the ability of nominated people in one instance of an experience to “broadcast” out to all other instances of that experience. This is being developed specifically for events such as presentations, concerts, etc.
  • Chat App improvements: including time stamps, and hopefully copy / paste – the problem being here that at the moment, the Chat App UI can break if trying to copy a large swathe of text. Hence why the option was disabled.

Ideas that are not currently being pursued, but may be considered in time include:

  • The ability to see where friends are in Sansar and teleport to them.
  • The ability to send a teleport invitation to friends to have them join you in an experience.
  • The ability for users to engage in private, one-to-one Voice conversations (Voice IMs, so to speak).

Voice Chat

A number of issues have been identified with Voice chat:

  • Audio occlusion: this does not always work as expected, allowing shows from part of an experience to bleed into a neighbouring part, even if the two are separated by a solid wall.
  • Voice roll-off: it’s been noticed that recent changes mean that where there was a clear break between different voice chat sessions scattered over an experience, there can now be times when multiple conversation overlap, potentially confusing the listener as they move around.
  • There needs to be a quick, effective means to focus in on someone talking in a group, which can be applied to both Desktop and VR modes.
  • there needs to be a more granular approach to being able to adjust the volume at which a users hears those around them talking.

Text Chat in VR

The Lab is looking at ways to surface text chat in VR mode, so that VR users can read what is going on in text and respond to it via Voice. This alone would be a huge improvement, given that in groups are VR dominant, anyone using Desktop text chat is essentially ostracised, as one of the VR users can see what they have typed.

User Profiles

Spanning both communication and socialisation is the user profile. Familiar to everyone in Second Life, it has been lacking any kind of implementation in Sansar. However, this is now changing.  Being prepared for a future release is the first iteration of a Sansar user profile. This will initially include:

  • The user name and an avatar head shot (obtained via the LookBook).
  • A field in which a short biography can be added.
  • And option to friend others through their profiles.

Additional options such as instant messaging, recording an avatar’s rez date and having a field in which notes on an avatar can be recorded.

2018 Sansar Product Meetings week #7: on-boarding and audience

Mario2 Helstein’s M2D City, location for the Thursday, February 15th, 2018

The following notes are taken from the Sansar Product Meeting held at 16:00 PST on Thursday, February 15th, 2018. are open to anyone to attend, are a mix of voice (primarily) and text chat, and there is currently no set agenda.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.

Unfortunately, I was unable to attend the Tuesday, February 13th Product Meeting for week #7.

New User / On-Boarding Process

As noted in recent Sansar project updates (see 2018 week #3 for example), this is a priority for the Lab: making the new user sign-up and on-boarding smoother, possibly with fewer steps and hopefully (in the future) providing the means for experience owners to engage directly with their own audience through the events listing, their own web page with a URL to their experience and bring that audience of new users directly into their own experiences.  The Lab has been looking at a number of possible options for direct on-boarding, including something akin to Second Life’s Social and Learning islands.

Introducing Sansar to an Audience

Related to on-boarding is the idea of how to introduce Sansar to a new audience. Like Second Life, Sansar isn’t a game; there are no goals to work towards, no achievements to gain, no quests to be completed per se (although individual experiences can obviously include these). Therefore, providing videos, live streams, etc., which might help newcomers understand Sansar is a difficult topic to encompass.

  • One suggestion is to focus on the common elements within Sansar – such as the form-form ability to create environments, or the ability to participate in the economy either as a creator or a consumer (or indeed, a consumer-creator), and make “let’s play” style videos.
    • This could would well for the consumer-creator especially: showing how someone not versed in Maya, Blender, ZPaint, etc., can enter Sansar, come up with an experience idea, purchase items through the store and then create an experience and using the Edit Mode to lay things out and then set-up an Atlas presence and bring people into that space.
  • A problem with a “creation” perspective videos is that they might only appeal to a small percentage of a potential audience – simply because a) creation is complex in Sansar (even for the consumer-creator) in using the Edit Mode; and b) many people are looking for more-or-less for instant gratification. So having a focus on what people might find and do could be more effective.
  • Another suggestion is to have videos of the community meet-ups and the Top Five videos better promoted.

Audience Identification and Outreach

Part of the problem with encouraging an audience into Sansar is actually identifying that audience. Again, this is not a “one stop shop” like a conventional game. Those running a social environment for discussions and conversation in Sansar aren’t necessarily seeking the same audience as those making a learning or historical experience, who in turn aren’t necessarily going to be looking to the same audience as a sci-fi role-play experience. Thus, consideration must be given to experience creators finding their own channels to reach their preferred audience – be it YouTube or some other video outlet, forums, etc.

Is Sansar Ready for a Bigger Audience?

This is a chicken-and-egg question: users are need to drive adoption and grow content. Content is needed to attract users and engagement – content here not only being experiences and mesh models etc., but the platform’s capabilities: users being able to interact with one another and with the environment, etc. Right now, and in many respects, Sansar isn’t ready for a broader audience, simply because it isn’t capable of supporting these broader / deeper levels of activity. Focused communities cannot easily be managed, for example, because there is no mechanism (platform content / capability) to be able to do so.

This is already potentially leading to people visiting Sansar and walking away with the impression it is just a pretty place with nothing to do – so how to engage with these people and encourage them back needs to be considered and made a part of thinking, rather than – for the time being at least – simply looking to try to attract people in from elsewhere in greater numbers, by it from the world at large or SL or other platforms.

Social aspect of Sansar are picking up – look at the events listings during the week (not so much at weekends as yet). However, these can be very close-knit (for example, the preference is for voice chat, not text – which can be off-putting for those who do not wish to use – and equally importantly, if often overlooked – people who do not wish to hear chatter. Voice, frankly can be off-putting socially, simply because so many people don’t have the wherewithal to toggle their microphones off when not speaking, often leaving disconcerting background noise, conversations with other in the physical world with them, and so on.

On-Boarding / New Users Focus Group Discussion

On-boarding is liable to be the subject of a focus group meeting in the near future.

In Brief

  • Experience access control: currently, access to an experience can be limited to those on the creator’s Friends list. The next element – possibly to be rolled-out in the March update (ish) will be the ability to govern access via a white list of names. Anyone not listed for access won’t see the experience on their Atlas.
  • Sansar roadmap: this will likely be a focus for the Product Meet-ups in week #8 (commencing Monday, February 19th, 2018).
  • Improved object interactions: the ability to touch-interact with objects (e,g, touch a book and it opens, click a switch and a lights come on, etc)., are being worked on – but the Lab is sensitive to developing these capabilities so that such capabilities can be scaled and grow to meet a broad a range of needs as possible, rather than pushing the capabilities out quickly “to give people something to do”, and then having to revise them, possibly breaking content.
  • Windows Mix Reality Headsets: some people have been trying Windows Mixed Reality headsets with Sansar. While Sansar doesn’t officially support these headsets, people are finding the work, but the avatar arms don’t respond to the user’s hand / arm movements, even those the available VR interaction (picking up objects, etc), does work.

2018 Sansar Product Meetings week #6: Find and Connect 2

Eternity by C3rb3rus

The following notes are taken from the Sansar Product Meeting held at 9:30am PST on Friday, February 9th, 2018 – unfortunately, I was unable to attend the afternoon meeting, so have not notes from that.

These Product Meetings are open to anyone to attend, are a mix of voice (primarily) and text chat, and there is currently no set agenda. The official meeting notes are published in the week following each pair of meetings, while venues change each week, and are listed in the Meet-up Announcements and the Sansar Atlas events sections.

Product Meeting Changes

The “new format” for the Product Meetings, featuring specific subject matter experts from the Lab making themselves available to answer questions from users will now likely start in the week commencing Monday, February 12th.

  • The meetings are liable to be held on different days of the week relative to one another, rather than both on a Friday.
  • Dates and topics will be announced via the usual channels (Sansar Discord channel, meeting announcements, Atlas Events).

Find And Connect Update

The Find and Connect release (see my previous Product Meeting report) was updated on Wednesday, February 7th, 2018, comprising fixes for some known issues.  A list of changes / remaining known issues is available in the release notes. The following provide a little more context on the update.

Character Editor

A couple of avatar issues have been fixed, forcing users logging-on for the first time after the update to go to the LookBook (avatar app). These are:

  • The avatar’s head only having limited movement (particularly noticeable in VR).
  • Switching between avatar genders could merge female and male avatars together.

Experience Loading  and Progress Indicators

This was noted in my previous meeting notes, the progress bar seen on an experience splash screen is still in its first iteration, and can appear to “hang” while loading content for uncached scenes.

  • It’s been suggested a count of assets loaded (e.g. 23 out of 96 or something) could help prevent feelings that the load process has hung.
  • It’s been noticed that on occasion, an experience can hang on loading, then quiting and restarting the client / reloading the experience can cause it to load and start OK.
    • This was noted before the progress bar was added, and has been more noticed since the addition of the progress bar, which might be indicative of a load problem / connection issue upsetting the load process.

Experience Concurrency Indicator

The experience concurrency indicator (green icon in the top left of the experience Atlas thumbnail / description image) is reporting avatars as being present in experiences when no-one is in fact visiting.

  • This is a known issue, caused in part by a degree of latency which can occur between people entering and leaving an experience, and the Atlas being updated, and the Lab is looking to improve this.
  • If the Atlas has been left open for an extended period, refreshing it (e.g. reloading the page in the case of the web Atlas) might force an update of the concurrency indicators for experiences that have seen a change in the number of people visiting.
  • Note that this indicator only applies to visitors in a published experience, it doesn’t count people actively editing the scene associated with the experience.

General Feedback

Outside of the points raised above, general feedback for the Find and Connect update is:

  • Load times have (in general) improved.
  • Performance has improved within experiences, probably as a result of the update optimisations included in the release.
  • LookBook is a lot more responsive and gives a smoother experience.
  • Issues of names not showing in Desktop Mode when hovering the mouse over an avatar seem to have increased, and dropping into / out of LookBook and re-spawning in an experience no longer consistently fixes the issue. This is a known to the Lab and is being investigated.

Voice and Text

Voice Indicators

The debate on how to more easily identify who is speaking continues both at the Lab and among users. Ideas put forward include:

  • A over-the-head indicator of some kind (a-la Second Life) – perhaps a an illuminated dot only seen when speaking. There is some resistance at the Lab to this approach as it “breaks immersion”
  • A voice indicator in Sansar’s people floater. Potential problems here:
    • It requires people to always have the people floater open, which could be intrusive and “immersion breaking” for some (possibly more so than a dot that only illuminates when someone is speaking).
    • It currently wouldn’t work for people in VR, who cannot see the chat / people floaters.
  • An auto-rezzing “speaker’s stick” indicator that automatically rezzes in front of the avatar of someone speaking, and vanishes when they are silent.
  • An avatar animation (again a-la Second Life “speaking” animation gestures); but again, this might be a problem for users in VR using hand controllers.

Currently, this issue s not on the immediate road map to be addressed.

Text Chat  / People Floater in VR Mode

  • This is still being considered at the Lab and not currently on the implementation road map.
  • It is possible that the first iteration will allow VR to see text chat, but not necessarily have the means to type text.
    • Users may have the option to toggle this on or off.
    • Some form of indicator that messages have been left in text chat, even if the text panel isn’t visible is also seen as advantageous.
  • The ability for VR users to respond in text is seen as a longer-term issue to resolve.

Voice vs. Text Debate

There is an ongoing debate about preferred communications in Sansar.

  • The platform is a lot more geared towards voice use; so there is a concern that encouraging text chat (as with making text visible to VR users) could shift the bias away from voice to text.
  • There are situations where text chat is the better means of communication, e.g:
    • As a means of saving a transcript of a business discussion / arrangement.
    • To assist with character role-play (e.g. no issues of a voice failing to match a character  – orc, dragon, elephant, etc), or a male user having a female character or vice versa, etc.

Discord has been pointed to as a “solution” to group chat, etc., with Sansar. However, while there are advantages to this (e.g. Linden Lab do not have to develop a Discord-like environment within Sansar) there are also disadvantages (e.g. Discord is not particularly intuitive for a new user; it actually means time in Discord is time potentially away from Sansar; it means placing data and information in the hands of yet another third-party, etc.).

  • There is potentially a bias towards Discord at present, as it does only have a very small community of Sansar users involved within it. There are questions as to how well it scale should Sansar reach tens of thousands of active users trying to engage in group conversations, locate groups, etc.
  • Conversely, can Linden Lab realistically encompass everything users need directly within Sansar without overwhelming the ease-of-use aspects the platform is supposed to have, and are approaches used in Second Life (e.g. full group integration) the most optimal solution?

The Voice / chat debate and options for text chat and voice indicators may form a part of one of the new focused Product Meetings in the future.