SL project updates 16 9/1: server deployments; SL viewer, misc news

Casabalanca: Rick's Café Américain - "Of all the gin joints, in all the towns, in all the world, she walks into mine."
Casablanca: Rick’s Café Américain – “Of all the gin joints, in all the towns, in all the world, she walks into mine.” – blog post

Server Deployments

The Main (SLS) channel was updated on Tuesday, March 1st, with the server maintenance package deployed to the three RC channel is week #8. This comprises a server crash fix and “minor internal improvements.”

The server deployment thread lists any RC deployments for the week as “TBD”. however, speaking at the Simulator User Group meeting on Tuesday, March 1st, Simon Linden indicated it is unlikely there will be any RC deployment until week #10 (week commencing Monday, March 7th 2016). These will apparently have an update that addresses a means by which a simulator can be intentionally crashed.

SL Viewer

Currently, the official viewer from LL remain unchanged from the end of last week:

  • Current Release version:, January 15 – formerly the Maintenance RC viewer download page, release notes
  • Release candidate viewers:
    • Maintenance RC viewer version, dated February 26th
    • HTTP updates and Vivox RC viewer version, dated February 22nd
    • Quick Graphics RC viewer version, dated February 17th
  • Project viewers:
    • Project Bento (avatar skeleton extensions) version, dated January 20th
    • Oculus Rift project viewer version, dated October 13th, 2015
  • Obsolete platform viewer version dated May 8th, 2015.

OpenSSL Update

As noted in my last TPVD meeting notes, the Lab were awaiting an update to OpenSSL. This has now been released and there is minimal impact for SL. This therefore should require any fast-tracked update to the viewer.

Grid-wide Experiences

The simulator user group meeting saw a general discussion about allowing broader access to the Experience Keys database (the KVP) without land owners necessarily having to grant permission to specific Experiences.

The idea here is that there are applications which rely on persistent data or utilise grid-wide data exchange (e.g. a teleport network, a vending system network, etc.), and applications which require script settings survive the script reset. Currently, the way to achieve this is to use external data stores (see BUG-11499 for one example).

Some feel that if there were a way to dissociate the KVP database from things like avatar influences, then it could be used for such applications, removing the need for external data stores and the rick of those data stores vanishing / not being available. However, this is not something the Lab is particularly keen on, for a number of reasons. For example, it could result in their servers storing a lot of data and carrying a lot of database quires and updates, something that might not scale terribly well with volumes and associated storage space cost. Nor would it necessarily safeguard the data any better (if the Experience owner downgrades to Basic or ceases paying their Premium subscription, the data will be lost).

During the discussion Oz indicated that the Lab has no plans to make grid wide experiences available any time soon, due to concerns about how “certain internal features” would scale.