Lindens on the beach in Second Life

The gathering of the gathering for the meet-up ...
The gathering of the gathering for the meet-up …

Thursday, June 11th saw the latest get together between Linden Lab staff and residents. Perhaps learning from the lessons of the last event, this one was focused on a 2-region venue in order to help spread the load. Given that when I checked at one point, there were over 110 people in attendance with more arriving, then just as well.

Coming ahead of the 12 anniversary celebrations scheduled for June, the event was marked for Premium members only. On offer for those attending was a chance to pick-up the 12th anniversary avatar ahead of it being made more generally available (and  for those who missed the event itself, the kiosk offering the avatar will be available at the meet-up island until midnight SLT on Friday, June 12th).

Dino-ing out to celebrate SL12B? The hat and shades may not win the approval of palentologists (or Steven Spielberg) - but they help give velociprators less of a bad rep ...
Dino-ing out to celebrate SL12B? The hat and shades may not win the approval of palentologists (or Steven Spielberg) – but they help give velociprators less of a bad rep …

The idea of providing a celebratory avatar for SL’s anniversary is not new; in the past we’ve had the likes of bears and robots. This year the rumour mill was that a dinosaur would be on offer. And by “rumour mill”, I mean the original e-mail and blog post put out by the Lab which accidentally gave the game away. Oops 🙂 .

The choice of velociraptor is interesting. On the one hand, dino avatars have been popular in SL for a while now – I’ve visited a number of regions over the past few months only to find various dinos also taking in the view. On the other hand, the choice of velociraptor and the release of Jurassic World in cinemas around the world did have the words “oh, bandwagon!” echoing faintly.

The island for the get-together itself provided plenty of space, with a couple of bars, a dance floor and a crocodile wrestling ring, with a bridge crossing the water to a beach on one side, and a boat offering crossings to the jungle over the water on the other. As it was, most people gathered at the main bar and showed little willingness to risk moving around too far, although as things got ever more crowded, some opted to chillax on the beach.

Dee, Alexa, Oz (with the wonderful Chantal Harvey behind him) and Michael were all at the bar, as were Torley, Shaman and Xiola, while Patch and Vitae took to the beach, quite possibly with other Lindens I missed...
Dee, Alexa, Oz (with the wonderful Chantal Harvey behind him) and Michael were all at the bar, as were Torley, Shaman and Xiola and Guy, while Patch and Vitae took to the beach, quite possibly with other Lindens I missed…

Michael Linden was the first to arrive, in full mole guise, and served briefly as boat pilot and then as bartender. The Watermelon punch ensured Torley’s participation, and Xiola, Guy, Patch, Vitae, Alexa and Shaman were all noticeably on-hand, while Dee’s diminutive presence (she always has the most wonderful petite avatars) perhaps went unnoticed by many in the crowd.

Conversation was, as usual loud and hard to follow in open chat. An unintentional error at the bridge meant a few people needed rescuing after finding themselves stuck under rocks – I sent Xiola a teleport offer at one point after Kerena nudged me, but she managed to extricate herself without needing the help.

Some of my favourite people: Brock mcMillan and Tomais Ashdene, Ziki Q catching the sunshine, and Rocky constantine looking cool in the shade and shades :)
Some of my favourite people: Brock McMillan and Tomais Ashdene, Ziki Q catching the sunshine, and Rocky Constantine looking cool in the shade and shades 🙂

There was a good ebb and flow of visitors and a far few velociraptors within the crowd, with Vitae leading a small group to go sun themselves on the beach. Ziki and I opted for swimwear, but while there were a few bare-chested males on the islands, most people opted for lightweight summer wear. I managed to catch-up with a number of friends, mostly through IMs, although at one point I forgot to turn shout off. My apologies for anyone sitting / standing near me at the bar I may have deafened with my bellowing; which I think may have actually sent Michael scampering for cover, as he was absent the bar shortly afterwards.

Maxwell Graf and I chat at the bar ...
Maxwell Graf and I chat at the bar …

It was particularly good to catch-up with Karsten Rutledge, although I failed miserably in capturing him on camera.  Chantal Harvey and I made the most of the bar barrel seats… and he availability of the bar itself while chatting, but I think the crowd may have prevented Torley from actually getting to the watermelon punch as it sat between the Chantal and I.

Looking across to the beach, I had hoped to see the velociraptors there perhaps engaged in sunbathing on the hammocks or playing a game of beach volleyball. But sadly no; they seemed content to stand or lie on the sand chatting.

As I mentioned last time around, it’s easy to dismiss events like this on the basis of the numbers or question their value. However, to do so is to really miss the point.

Not everything that goes on in SL need serve a specific purpose beyond bringing people together and allowing them to share time in one another’s company. That they may be doing so in a crowd of 100+ doesn’t matter; the act of being there and just enjoying the moment brings its own satisfaction. It also lets Lab staff to mingle and relax among residents without worrying about being bonked with this or that question or one problem or another, allowing them to get to know people and make friends / acquaintances.

Raptors on the beach...
Raptors on the beach…

As noted earlier, the use of the two regions did help considerably in terms of people coping with issues such as rendering, “lag”, and so on. People were encouraged to spread between the two as some of the Lindens moved between them, encouraging the crowd to spread naturally and thin itself. Hopefully this approach will continue at future meet-ups.

The demands of the physical world (in particular those of the kitchen) meant I had to depart the party before things started winding down, but was very clear that folk were having a good time, and many were seeing the event as a early kick-off for the upcoming anniversary celebrations.

It’ll be interesting to see how many raptors are roaming the roads of SL12BCC in a little over a week’s time. Or, indeed, if we get any performing on stage during the SL12B music festival…

Watery stories in Second Life

Mizu: A rainy story
Mizu: A Rainy Story

Open now through until July 7th is an interactive story book called Mizu: A Rainy Story, which takes place in the region of Papillon. I was led there after reading Honour’s post on the subject.

The story is a curious mix, the title of which actually gives little away, although I suspect that for “rainy” you could read “watery”, which would be more in keeping with the theme and matches the use of Mizu, one of the five godai of Japanese Buddhism, and associated with water.

Mizu: A Rainy Story
Mizu: A Rainy Story

Things don’t get up off to a good start – as you quickly discover that in your clumsiness, you’ve broken a family heirloom: a multi-hued stone. This sets you on a journey through time, witnessing events which – I’m guessing – form a secret history for your family. Water certainly plays a significant role in matters through the unfolding tale, make no mistake; but to follow the narrative, umbrellas are certainly not required!

To play, you’ll need the free HUD which can be obtained from the wall bordering the landing point – Japanese and English language versions are available – and wear it. It will request that you allow it permission to act on your avatar (predominantly teleports and camera control). It’s important that you both wear the HUD and give permission prior to actually going any further and entering the story, otherwise things may not work.

Once you are wearing the HUD, make sure you find your way to the little movie theatre and take a seat. The story commences every 5 minutes, so the wait shouldn’t be too long. If you’re sharing the experience with a friend or two, make sure you all sit in the same coloured seats so you can travel through the story together.

Mizu: A Rainy Story
Mizu: A Rainy Story

When the film starts, you’ll find yourself transported to a small room, the aforementioned broken stone lying on the table. Here, as in the rest of the story, touching things is the key – and having a little patience; not everything is quite as it seems, and sometimes things have to be touched in a specific order.

Click on the right things and the HUD will open and proceed to tell you a part of the story and / or give you directions on what to do next, and will also transport you to the next location in the unfolding tale as and when appropriate.

Mizu: A rainy story
Mizu: A rainy story

I’m not going to give any more of the plot away, as it is one best discovered through participation.

What I will say is that it is rather unusual in content and thrust, and possibly not what you might be expecting as it unfolds. In this, perhaps the use of “Mizu” is a reflection of the flow of the story: its changing nature and our need to adapt to it as it unfolds, just as the river and plant adapt to their environment and the changing of the Sun within the philosophy of the godai.

However you look at it Mizu: A Rainy Story is an interesting presentation, offering something just that little bit different to visitors. And if you feel in need of a little retail therapy after travelling through it, there’s a little street market (see in the topmost images of this article) to be found either through the tunnel next the the story landing point, or once you have completed your journey.

SLurl Details

SL project updates week 24/1: server; VMM; group list changes

Goatswood; Inara Pey, June 2015, on Flickr Goatswood (Flickr) – blog post – visit soon, closes June 19th, 2015

Server Deployments Week 24

As always, please refer to the server deployment thread for the latest updates / news.

  • On Tuesday, June 9th, the Main (SLS) channel received the server maintenance package previously deployed to the three RC channels, comprising:
    • Change logic on accessing group member lists for large groups – please see more below
    • Internal server logging changes
  • On Wednesday, June 10th, the three RC channels should all receive a new server maintenance package comprising further Internal server logging changes.

Group Member List Changes

The “Change logic on accessing group member lists for large groups” refers to how the members list for groups with more than 5,000 members are now handled. A full explanation of the change and the reasons behind it can be found in my blog post on the matter. however, in short:

  • Groups with 5,000 or more members will no longer display the list of members unless:
    • You are assigned the Owner or Officer role within the group
    • You are assigned an ability within the group which requires the members list to be displayed (e.g. you are able to assign members to assigners roles, or are able to eject / ban people from the group, etc.)
  • Instead, and until corresponding changes are made to the viewer, all you will see on opening the members list as a message stating “Retrieving member list (0 / XXXXX)” – where XXXXX is the total number in the group,

The has already caused concern over how the change may be perceived as a functional breakage – see BUG-9393. In addition, two further issues resulting from the change have been reported:

  • BUG-9404: “Group members of large groups in a role which has “Invite people to this group” ability are not able to send group invites” (initially filed against the RC regions when the change was deployed in week #23, and now applicable to the grid as a whole)
  • BUG-9428: “Users using older viewers are unable to leave groups with >5k members on regions running 15.05.28.302161”

Scripting Memory Limits

A request was made for the Lab to consider allowing llSetMemoryLimit to request up to 128kb or 256kb of memory (whichever is more feasible), with a performance penalty for scripts using less than 50% of the memory requested – see BUG-9382.

The arguments for such an increase are not new; many coders run into problems with utilising memory for both code storage and code operation, resulting in having to write inefficient scripts and additional operations to communicate between scripts. A similar request has also been put forward (see BUG-8761), but which limits the additional memory allocation purely to Experiences on the ground that offering increased memory to all could lead to performance and other issues.

Commenting on the request at the simulator User Group meeting on Tuesday, June 9th, Simon Linden said:

I don’t think we’d want to limit performance … that seems like it would get into odd rules and conditions. Plus that’s likely to be in a place where we don’t want to add more code. FWIW, when you have lots and lots of scripts in a region, the time spent rotating through all the scripts becomes significant, so your script time isn’t just running scripts.

Oz Linden then added:

One of our frequent themes this year has been to look at various limits and consider making them better … perhaps we can look at the memory limit at some point too. One of the things I hope will happen as Experiences are adopted is that some of the code that’s being used to manage saving state and communicating can be replaced by simpler code to use the key/value store.

This drew agreement from Simon, who then continued:

I suspect larger script size has been limited by not having script memory limits. But at a smaller scale, it’s easy to add more scripts, so perhaps doubling or a bit more won’t really make it any easier to hog memory.

This doesn’t automatically mean that script limits will change in the future; as Simon also pointed out, script memory is the largest part of each avatar load, and can have an impact on things like physical region crossings and teleporting, which would likely have to be be considered. However, script memory is likely to get added to “The List” of things the Lab is looking at.

Viewer-Managed Marketplace

Some confusion has been evidenced over the use of the term “archived” in recent communications from the Commerce Team regarding what will happen during the auto migration process, and particularly with reference to items that have not seen sales in over a year.

  • The first point to remember is that any “archiving” will only occur for those merchants who have more than 5,000 items on the Marketplace when the auto-migration process reaches them. As noted in my last VMM update, all such affected merchants have already been notified
  • From information made available by those merchants so affected, it would appear that “archived” means “items will be returned to the merchant’s Received Items folder”. Firstly, any items the Merchant has stored on the Marketplace without any associated listing will be returned. If this fails to reduce their total count to below 5,000, then those items which have not seen sales for over a year will be unlisted and the items again returned to the merchant’s Received items folder.  From this it would seem that there will not be any actual “archiving” of listing information or items on the part of the Lab.

 

Sneaking a peek at birthday preparations in Second Life

SL12BCC: What dreams may come....?
SL12BCC: What dreams may come….?

Preparations for the 12th Second Life Birthday Community Celebration are continuing. With just over a week left until the regions close for walk-through and stress testing, exhibitors and stage creators are hard at work building wonders to woo and wow visitors when the gates are thrown wide to the public on Sunday, June 21st.

I’ve been fortunate enough to get the opportunity to slip into the regions and see what is going on; and I have to say that there is a lot of fantastic effort going into things, with people really focusing on the idea of dreams and what may come, and where they might lead.

SL12BCC: the stages take shape...
SL12BCC: the stages take shape…

The main reason for my early access is to put together sneak peek videos of the regions on behalf of the SL12BCC organising team.  This is an interesting exercise for me, as trying to piece together very short video and without giving too much away this early-on is taking me into new territory with my video making!

Nevertheless, it’s proving fun, so, with that said, here’s another video peek at the regions, which can also be found on the official SL12BCC website. Enjoy!

 

High Fidelity update users with a quarterly report

HF-logoHigh Fidelity have issues a progress report for the second quarter of 2015, which has been circulated to users via e-mail and made available as a blog post.

In the report, they highlight recently achievements / work, including:

  • The fact that they’ve been hiring-in new talent (and are still looking for more). It should be noted that the talent is restricted to employees, either. At the end of May, Professor  Jeremy Bailenson of the Virtual Human Interaction Lab at Stanford University  and Professor Ken Perlin both joined High Fidelity’s growing list of high-powered advisors
  • The instructions and video on setting-up the stack manager to run your own High Fidelity server has been updated, with the promise that next up will be an ability to optionally allow you share your server resources with other nearby users who need extra capacity
  • The ability to track and capture head movements and facial expressions with a regular webcam, as an alternative to needing a 3D camera
  • The arrival of the High Fidelity Marketplace, where you can drag and drop content into your server, and also to upload content you want to share with others. This is currently a sharing environment rather than a commerce environment, but the promise is that the commerce aspect will be coming soon
  • Commencing work on implementing distributed physics, building on top of the open source Bullet physics engine, with the aim of having low latency for interactions while maintaining the same state among participants – such as when people in different locations are playing Jenga or billiards together
  • The ability to import web content into High Fidelity – static web pages, videos, interactive web pages, etc., complete with a demonstration video and the promise of figuring out the best ways to allow the different types of shared browsing that people are going to need
  • My personal favourite: zone entities, skyboxes and dynamic lighting with spherical harmonic lighting and optional sync to real-world day/night cycles

Also in the Next Steps aspects of High Fidelity’s development is the intriguing promise of avatars with soft bodies, which are capable of interacting physically, or as Philip Rosedale puts it in the blog post, “imagine sword-fighting, for example”, while being driven by hand controllers such as those coming with the HTC / Valve Vive or for the Oculus Rift. This also links back to the work going on with the physics engine as well, which has, as Mr. Rosedale explains in the blog post, an added level of complexity within High Fidelity due to the distributed nature of the platform, and the need to maintain consistency between players as to what is happening, where things are, who is controlling what, and so on.

For those wishing to keep abreast with the key points of what is going on with High Fidelity, but who do not necessarily have the time to jump into every blog post that comes out, these updates are a useful means of tracking core events within the platform.

Second Life group list changes explained

A note of explanation. I first published on this update on Thursday, June 4th, PDT. However, that post was withdrawn out of respect of a request from Linden Lab that I not blog on the change at that time. Subsequent discussions with the Lab led to an agreement that I could blog in full on the matter once the change had been deployed across the grid. Hence this post.

Until now, it has been possible to open the details for any Second Life group you have joined and display all the information relating to that group, including the list of members.

However, with the new update, groups with 5,000 or more members will no longer display the list of members unless:

  • You are assigned the Owner or Officer role within the group
  • You are assigned an ability within the group which requires the members list to be displayed (e.g. you are able to assign members to assigners roles, or are able to eject / ban people from the group, etc.).

Instead, and until corresponding changes are made to the viewer, all you will see on opening the members list as a message stating “Retrieving member list (0 / XXXXX)” – where XXXXX is the total number of members in a the group, as shown in the images below.

The back-end cange currently on the server RC channels means that group member lists will not load (or may be truncated until the change is fully deployed) for those groups wil more than 5,000 members
The change to the logic on accessing group member lists for large (5,000+ members) groups means that the members list will no longer display for members of the group, unless they are assigned either the owner or officer role, or an ability that requires they can view the list.  Instead, and for the time being, the above message (illustrated using both the LL and Firestorm viewers) is displayed – click for full size

This update has been made for a number of reasons, including:

  • Where very large groups are concerned, the full list of members has rarely completely loaded into the viewer – it has only seemed that the list has loaded
  • Tests have shown that in order for very large groups (e.g. tens of thousands of members) to load can take on the order of 10 or more minutes, during which time no other activities within the viewer can be carried out
  • Opening the members group list for large groups can result in performance impacts elsewhere (notably in group chat, as we’ve seen with changes made to that service recently).

In particular, the update is related to additional changes the Lab intends to make to the viewer-side code for group management, as Oz Linden, the Lab’s Technical Director for Second Life, explains:

It turns out – and this was one of the reasons we made the change on the RC channel – because we weren’t really sure what it would affect. But it turns out there are a bunch of places in the viewer, where the viewer triggers these requests for all the members of a group where it’s not even going to use the data … So some of those requests are kind-of bogus and not helpful, and we’re going to be making a set of changes to take those out, and replace them with something more focused.

Do note, however, that this change is not in any way connected to the recent increase in the number of groups Premium members can join, and it is believe that around 600-700 groups are affected by the change.

The initial deployment of the update on the server RC channels on Wednesday, June 3rd gave rise to some concern, notably:

  • The message currently displayed by the viewer suggests that rather than the member’s list being prevented from loading, it has simply stalled or perhaps timed-out, which could result in elevated support calls
  • The change breaks a lot of ways in which a group’s members list is used – see BUG-9393
  • In particular, the change means that people unable to see the members list can no longer ascertain which owners / officers are on-line and in a position to assist with any group-related issues which might occur.

Acknowledging some of these points during the Server Beta User Group meeting on Thursday, June 4th, Oz said:

 There are some things we need to do in the viewer to make some of these changes clearer… those changes will be made as soon as we can … In the mean time, if large groups want their officers to be reachable, they may want to put something in the description to help with that.

Further to this, and in relation to making information on group owners / officer visible to all members of an affected group, and on improving the currently-displayed message in the viewer, Oz further stated during the TPV Developer meeting on Friday, June 5th:

We will find a way to make that information available in the fullness of time [owners / officers], but it probably won’t be real quick … We’re going to fix the problems, but it’s going to require building some new interfaces for things like, “show me who the officers are”.

There are certainly going to be some bug fixes for the viewer coming quite quickly, quite probably in the next maintenance viewer, not the one that will get released next week [week #24]  but the next one, that will clean-up how things look. You’ll actually get a positive indication that you can’t see this list, or whatever. But we’re still fiddling with that.

Thus, while the changes to large groups may initially seem a little confusing, they are part of a larger attempt to improve group management functions within the viewer, and the Lab does recognise that more needs to be done to make key information within groups clearer to members.

In the meantime, please remember this change only affects those groups with 5,000 or more members, and does not prevent those assigned roles / abilities that require them to be able to see the group’s member list. Groups with less than 5,000 members remain unaffected by the change, and all members will continue to be able to see the group members lists for these when viewing a group’s information.