Sansar: Know Thy Neighbour release

Light switches and other scripted object interactions are now possible in Sansar. Credit: Linden Lab

Friday, June 1st saw the deployment of  the Sansar Know Thy Neighbour release, which brings user profiles to Sansar, adds object interactions through scripts and something the Lab call Access to Controls.

This article highlights some of the new features – and some deployed in May 2018. As always, full details of the updates in the new release are available in the release notes.

Initial Notes

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

User Profiles

Second Life users are more than familiar with the idea of user profiles and their usefulness. They are something that has been raised on numerous occasions as one of the missing elements within Sansar – and with this release, they’ve started to arrive.

A Sansar profile can be used to display basic information about a user: their avatar name / ID, a photograph, and a short  biography. In addition, viewing other people’s profiles allows users to request / remove friendship, see a summary of any store listings they have or experiences they have published, each of which are interactive.

Every Sansar user has a profile by default, which can be edited and updated as required, although they must be updated from within the Sansar client. Profiles can, however, be viewed both within the client and on the web.

Editing Your Profile

To edit your profile, launch the Sansar client and then click on More Options > Edit Profile. This will open the Profile Editor, which has two user-definable fields: the profile image and biography.

Profile images are automatically generated by Sansar, based on the looks you have saved in the LookBook (See Customising your avatar). To select / change your profile image click on the edit icon at the four o’clock position on the photo display (1 in the image below, right). A list of your available images will be displayed. Click on the one you wish to use with your profile.

To update your biography, click on the Bio section (2 in the image below right) and enter your text.

Editing your Profile

When you’ve completed your updates, click Save to apply them.

Viewing a Profile

Profiles can be viewed in a number of ways:

  • From within an experience, through the client’s People App.
  • Via the Atlas, either within the client or on the web.
  • Via a store listing on the web.

Via the People App

Displaying a Profile via the People app (in this case, using Search)

When in an experience, you can display someone’s profile by opening the Chat App then clicking on the People App button.

  • To view the profile of someone on your Friends list, click on their name to display the interaction options and click Profile.
  • To view the profile of some on your Friends list, use the Search option, then click on their name to display the interaction options and click Profile.

Both of these options will open the user’s profile. This comprises a number of sections:

  • The user’s profile picture with a microphone icon at the four o’clock position. This is the mute / unmute option. Green indicates the person is not voice muted, red indicates they have been voice muted.
  • Three central options to direct message them; to friend / unfriend them or abuse report them.
  • The bottom section of a profile may  – or may not – display one or other – or both – of two further options: Store Items and Experiences.
  • Store Items: if the user has a Sansar Store, the total number of items they have listed will be displayed, with a See All option. Clicking the latter will display their store in your web browser. This option will be absent if the user does not have any items in the store.
  • Experiences:
    • if the user has published one or more experiences, the total number of their published experiences is displayed, with thumbnails of each of them.
    • Clicking on a thumbnail should open the experience
    • A button (V or ^) is displayed in this section – if the user has more than one experience, this will switch the thumbnail view between a single experience thumbnail and a tiled display of thumbnails.
    • This option will be absent if the user has not published any experiences.
  • To close a displayed profile, click the Back button at the top left of the profile display.

Note that when viewing a profile, you can also accept Friend requests sent by that person, as well as send your own.

Continue reading “Sansar: Know Thy Neighbour release”

Advertisements

Sansar: VR Chat release

The new “/sit 2” animation- VR Chat release

Monday, May 7th saw the arrival of the May 2018 Sansar release, entitled the VR Chat release. As the name implies, this release includes the long-awaited option for those in VR mode to see text chat from those around them. Alongside of this is Twitch integration, a further avatar sit option, and other nips, tucks and updates.

As always, full details are available in the release notes, this overview just highlights some of the key features / items in the release. In addition, a small update was issued on Tuesday, May 8th, 2018.

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.

VR Mode Updates

Read Text Chat in VR Mode

A major limitation with Sansar up until now has been that those in VR mode have been unable to see text chat (either local chat or direct messages) in their headsets – which can lead to those using text as their preferred means of communications being ignored.

Chat in VR allows VR users to see local chat and direct messages whilst in VR Mode

Chat in VR rectifies this by providing the means for headset users to view the chat app in their field of view. I don’t actually have full-time access to a headset, so can’t vouch for how it works. However, from the Sansar documentation:

The Chat app in VR mode allows you to view messages from nearby people in your current experience in the Nearby tab and private messages in the Messages tab.

  • It is not currently possible to send messages while in VR mode.
  • You can move the Chat app by grabbing it with your Oculus Touch or Vive Wand and dragging it to a new location.
  • When you move or turn your head, the Chat app moves with you.

Pointer-based VR interaction

This update replaces the “move your head to select objects” approach with the more intuitive use of hand controllers. Simply point and hover over objects with the controller to select or pick up.
 Note that head movement is still required to use the Avatar tool when hovering over an avatar, however.

Twitch Integration

This release brings with it the ability to create a Sansar account via Twitch, and then log-in to Sansar using your Twitch credentials.

However, note that this is only for those creating a Sansar account via Twitch: it is not, at the time of writing, possible to link an existing Sansar account to a Twitch account and use the Twitch credentials to log-in to Sansar.

Those who create a new Sansar account via Twitch can now log-in to Sansar using their Twitch credentials

See the Twitch Integration article from the Lab for more.

Clothing Updates

The VR Chat update brings with it three updates related to clothing:

  • The Worn Clothing panel in LookBook > Customise option allows you to easily review, remove or adjust clothing on your avatar.
  • The Sansar astronaut and highlands outfits have been added to the default clothing inventory.
  • Adjustments for multiple Marvelous Designer clothing items can be made at the same time by clicking the “Adjust Clothing” button, or adjust each worn clothing individually by pressing on the “Play” button in the Worn clothing panel.
The Worm Items panel (LookBook > Customise) allows you to easily review / change the clothing you are wearing

New Sit Option

A basic ground sit came to Sansar in the April release (see here for more). However, as I remarked at the time, for a female avatar wearing a dress, the sit pose wasn’t the most elegant. This has now been addressed, to a point, with a new “/sit 2” pose, which set an avatar kneeling – see the animation at the top of this article. The hands-through-the-skirt aspect is still a little distracting, but “/sit 2” is a big improvement, as well as adding a bit of variety to a group sitting on the ground together.

Other Updates

The VR Chat offers a number of scripting updates:

  • API for object animation playback – play, pause, stop, rewind, slow down/speed up object animations via script.
  • API to override the media URL in a scene – update the streaming media at runtime via script.
  • Colours are now a supported type for script parameters.
  • Visibility added on container properties for local position and rotation in the property editor.
  • These are all explored in the Script API updates.

The release notes also reference Avatar broadcasting the ability for one avatar to the precedence when speaking over others – useful for presentations, music events, etc. It’s not currently available for end-user use, but the Lab indicate it will be used in some Sansar events.

Feedback

An interesting update, but one that I have to admit, hardly excites. Frankly, I’m still of the opinion that if LL really want to encourage new users into Second Life, they really need to tackle the Sansar website – notably getting rid of ZenDesk (and Discord, which just doesn’t strike me as either scalable when it comes to supporting the hoped-for user base with Sansar, and which doesn’t have any real integration with Sansar) and establishing a properly integrated and informative web platform, with decently provided blog updates, a proper forum, etc., and which can help engage new users and make information a lot easier to see and to surface.

 

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.

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”