Maps as metaphors: Second Life and Sansar

The map is Second Life offers a powerful metaphor for the grid being a contiguous whole, even where private reagions may be remote and physically isolated from their neighbours
The map in Second Life is seen as a powerful metaphor for the grid being a contiguous whole, even where private regions may be remote or physically isolated from their immediate neighbours

Just how important a metaphor is the concept of a “world map” to Project Sansar? Given it has been a topic of discussion in both the first and second instalments of LabChat, and has been given by some as a reason for not wanting to be involved at all in Project Sansar, one might say “very important”; and there is no denying it does have its uses. But is it really as intrinsic to our use of Second Life as has been portrayed, and because it may not exist within Project Sansar in the manner we’re accustomed to seeing in SL, is it really a reason to proclaim we’ve no interest in the Lab’s new platform?

Within LabChat, the discussions on the Map have revolved around two ideas: that without the map, there will be “no sense of community”, and that it gives Second Life a greater sense of presence and of being a place when we’re within it.

I admit that in terms of the map being somehow central to the ideal of community, I find myself in agreement with Ebbe Altberg; that when all is said and done, the world map (and mini-map) don’t hugely contribute to a genuine sense of “community”. Yes, they help us find busy places we might want to visit (or avoid!), or see how busy a venue or store is, etc. But really, this doesn’t add to any feeling of “community” within SL. That comes from the people we meet within those spaces and how they interact with one another and us; how we in turn relate to them; what is going on within those spaces in terms of activities and events, etc. These are the things which are going to bring us into a community, and in that regard, the map really places no larger a role than search; it is simply a means to an end.

Is it really the map which gives SL its sense of community - or is it the people themselves. I'd tend to go with the latter (image: Richard Finkelstein (Leko Littlebird), SLCC 2011)
Is it really the map which gives SL its sense of community – or is it the people themselves? I’d tend to go with the latter (image: Richard Finkelstein (Leko Littlebird), SLCC 2011)

However, the idea that the world map presents Second Life as a place, adding to our sense of presence, is harder to deny. In fact, given that Second Life is intended to be a single world of (largely) interconnected spaces, its representation via a map can be a vital aspect of reinforcing this view. In other words, the map is, for many  – but not necessarily all of us – an intrinsic part of how we see Second Life as a connected whole, a place.

When it comes to Project Sansar, however, things are slightly more complicated. For one thing, it is not designed to be a single “world” in the same manner as Second Life. It’s a platform for hosting multiple “worlds” (“experiences”, “spaces”, “environments”, call them what you will), many of which may well have nothing whatsoever in common with one another – and certainly no way of moving directly from one to another in-world as we can in Second Life. Thus, presenting a single, all-encompassing map of “Sansar spaces” actually makes a lot less sense that it does with Second Life.

Within specific spaces, maps do have enormous value for visitors, so providing the means / support by which experience creators in Sansar can produce them could be of enormous benefit to the platform
While having some kind of over-arching map of all Project Sansar experiences might not be either practical or useful, providing the means by which experience creators can represent their spaces in a map which can be accessed by their users / clients / visitors remains both a useful tool and a powerful means of adding to the sense of presence within a space

Which is not to say the map is entirely redundant for Project Sansar. While some kind of all-encompassing map of “every” Sansar experience might not hold much value, the fact remains that as noted, maps do assist in giving one a greater sense of presence in an environment (as well as being useful for things like navigation!). As such, providing the means for experience creators to provide maps of their environments, and those to which they connect, would appear to be something Project Sansar should provide. In fairness, this isn’t something the Lab has ruled out, as Ebbe Altberg noted in the first Lab Chat:

So, that’s where we’ll start, and then it could be that maybe people create continents, or whatever you want to call it, even worlds, and maybe over time we’ll think about ways in which those can figure out how to have a map of that experience, and those could be vast.

The only caveat I’d have here is the idea that “over time” consideration will be given to enabling people to graphically represent their spaces. As noted, a map does provide a powerful metaphor for giving the environment you’re in a sense of greater presence. It’s also often the best means of showing people what is where, allowing them to see what might be of interest to them, and  – most basically – how to navigate from A to B to C.

Given this, and the fact that there may often be circumstances within Project Sansar where direct “in-world” transfer from one experience to another may not be possible, I’d say that having some kind of all-encompassing “world map” of every available experience within Sansar actually isn’t that important or something we should perhaps get too hung up about. Certainly, it doesn’t seem to be as important as perhaps encouraging the Lab to fully appreciate how useful a tool a map can be to visitors within a specific experience  (or connected group of experiences), and thus provide the means by which experience creators can easily create such maps sooner rather than later.

SL project updates 16 7/1: server and viewer

Sorrow; Inara Pey, February 2016, on Flickr Sorrowblog post

Server Deployments

There are no server deployments planned for this week, and no planned restarts for any of the channels.

There is an RC deployment planned for week #8 (week commencing Monday, February 22nd), details of which are still TBA.

As there have not been any rolling restarts, and won’t be any across the entire grid until around week #9, the advice is that if your region is behaving abnormally, file a support ticket to have it restarted. The Lab’s support team are aware that there are no scheduled restarts at present, so they should process requests OK.

SL Viewer

With Monday having been a holiday in the United States (Presidents’ Day), there was no meeting at the Lab to discuss viewer promotions.  This leaves the current list of Lab viewer unchanged from the end of week #6:

  • Current Release version: 4.0.1.310054, January 15 – formerly the Maintenance RC viewer download page, release notes
  • RC viewers:
    • HTTP updates and Vivox RC viewer updated to version 4.0.2.310660 on February 4 – combines the Project Azumarill RC and Vivox Voice RC updates into a single viewer  (download and release notes)
    • Maintenance RC viewer version 4.0.2.310545 released on February 2 – 38 updates. fixes and tweaks for memory leaks; viewer crashes; UI, permissions and mesh uploader bugs; visual muting issues, autopilot issues and duplicated calling cards (download and release notes)
    • Quick Graphics RC viewer updated to version 4.0.2.310127 on January 20 – provides the new Avatar Complexity options and the new graphics preset capabilities for setting, saving and restoring graphic settings for use in difference environments / circumstances (download and release notes)
  • Project viewers:
    • Project Bento (avatar skeleton extensions) version 5.0.0.310099 released on January 20 – adds 90+ bones to the existing avatar skeleton (download and release notes)
    • Oculus Rift project viewer updated to version 3.7.18.295296 on October 13, 2015 – Oculus Rift DK2 support (download and release notes)
  • Obsolete platform viewer version 3.7.28.300847 dated May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7 (download and release notes).

As noted in my recent TPVD meeting report, further updates are expected to the HTTP / Vivox RC viewer and the Quick Graphics RC viewer, but these may not appear this week.

Region Crossings – Grey Box Issue

There have been increasing reports of region crossing issues, including the return of the “grey box” attachment issue which was originally seen in 2013 when crossing from a BlueSteel RC to any other region. This would see any passenger(s) sitting on a vehicle surrounded by (or even replaced by) a grey prim, and left with no choice but to relog, leaving the prim behind, attached to the vehicle.

Caitlyn recently got caught by the "grey box" issue as we were sailing on the north side of Blake Sea. If you encounter the problem, please file a JIRA with as much information as possible (see below)
Caitlyn recently got caught by the “grey box” issue as we were sailing on the north side of Blake Sea. If you encounter the problem, please file a JIRA with as much information as possible (see below)

At the time of the problem first appearing, Kelly Linden described it thus:

Every agent has a ‘task’ representation on the server that is the same as a prim. The bug is in sending the linked set w/ avatars to the other region: avatars after the first are losing the special avatar treatment and getting passed as a regular linked prim. So that prim is what the server thinks all avatars look like.

Simon then added:

The region crossing code basically un-sits avatars from an object, sends both the avatars and object to the next region [as separate sets of data], which puts them back together. In this case, the 2nd avatar doesn’t get detached properly and things go south from there. So the 2nd avatar gets sent over bundled up with the object … which it’s not designed to do.

It had been thought this issue had been dealt with via a fix for (non-public) BUG-3547. However, if it is resurfacing, the problem now is to pin it down in a reproducible manner, if indeed it is returning. Should you encounter it, please make sure you file a JIRA providing as much information as possible, including your viewer log files, the regions you were crossing between when it happened yo you (or your passengers), the date and time, details of the vehicle you were using, etc.