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

Advertisements

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.