Day: July 12, 2013

New viewer release process implemented

Posted on by Inara Pey

Update July 23rd: As release candidate viewers are now available for download on the Alternate Viewers wiki page, I’ve added some notes on manually installing and running multiple release candidates to this article.

secondlifeThe new viewer release process announced by the Lab in May 2013 has officially been implemented.

Officially called the Viewer Integration and Release Process, It is designed to improve how the Lab can put new viewers before users and progress them through to a release status while avoiding bottlenecks such as those witnessed in late 2012, when an issue with the Viewer Beta channel effectively stopped any new viewer releases for around a two-month period.

With the new system, early versions of viewers will still be made available through “dedicated” project and beta viewers, all of which will be available for download via the Official Alternate Viewers Page. However, the major change to the process is the use of “release candidates”.

When a viewer is ready for final testing, a release candidate will be readied. Rather than residing in their own dedicated viewer channel, these release candidates will be updates in the regular release channel, residing in a named “cohort” within the channel.

The new Viewer Release and Integration Process means that viewers can be better developed tested and prepared for release in parallel

This means two things. Firstly, release candidates are available for download alongside one another and the default release viewer. Who might receive a given release candidate is a random selection based on a viewer setting (see below) and a pre-determined quota of downloads for the candidate (once the quota has been reached for a given candidate, the system will no longer select it for download).

Secondly, when a specific release candidate is deemed ready for release (based on bug reports filed, issues reported and fixed, stats gathered, etc.), there is no longer any need to rebuild it as a “release” viewer, as it is already in the release channel. It is simply moved from its named cohort to become the default release version on the SL viewer download page. Any remaining release candidates are then rebuilt using the new default release code, and continue with testing until one is deemed ready to become the next release.

From a user perspective, release candidates are largely indistinguishable from one another and the default release viewer (other than their version number and the features they contain), and the chances are that some users will be unaware that they have been selected by the system to run a release candidate; they will simply see it as receiving an automatic / mandatory viewer update, and install it.

“Willing to Update” and Release Candidate Downloads

As mentioned above, users who receive a release candidate viewer are selected at random, based on a defined quota of downloads for a given release candidate. However, whether or not a user might be selected to receive a release candidate viewer depends on whether or not they have left the “willing to update” option enabled in their current viewer.

Located in Preferences > Setup, “willing to update to release candidates” (to give the option its full name) is enabled by default. But just because it is, does not automatically mean someone will be selected to test a release candidate viewer. This is because the download quota defined for any given release candidate will always be relatively small when compared to the SL user base as whole.

However, if you don’t wish to run any release candidate viewers at all, you can disable this option, and only receive viewer updates when the default release viewer is updated.

Another point to remember with release candidates is that users won’t be moved between release candidates as a result of updates. So if you leave the “willing to update” option enabled and you happen to be selected for testing “release candidate A”, you won’t suddenly start receiving updates for “release candidate B”; you’ll stay with the updates for “release candidate A” until such time as it becomes the default release viewer. Only then might you be selected to receive another release candidate download at some point in the future.

Download Page and Alternate Viewers Page updates

As a result of the move to the new release process, the SL viewer download page has been updated, and there is no longer any link to download the “Beta Viewer”. Instead, there is a link which takes you to the Official Alternative Viewer wiki page, which instead lists all available beta and project viewers.

The Beta Viewer section of the viewer download page now takes you to the Official Alternate Viewer wiki page
The Beta Viewer section of the viewer download page now takes you to the Official Alternate Viewers Page

The Importance of Version Numbers

An important aspect of viewer bug reporting has been to give details of the viewer you’re running, including the version number. This information is requested in the “Environment” section of the bug report form. Given that the new viewer release process means there can be a number of release candidates in use at any given time, as well as various beta and project viewers, it is even more important that this information is given when raising a bug report.

Displaying details of the viewer you are using, including its version number
Displaying details of the viewer you are using, including its version number

Viewer information can be found in the About Second Life floater (Help > About Second Life), if you’re not already familiar with it. Further, the information on this floater can be copied directly to your clipboard ready to be pasted in a bug report to save you having to manually enter it.

Notes on Manually Installing Release Candidates

Viewer release candidates are now listed on the Alternative Viewers wiki page, and can be downloaded and installed, if so desired. If you do opt to do so, please note that release candidates are contained in “cohorts” within the viewer release channel, and are designed to overwrite any release candidate viewer you have installed. Therefore, if you wish to manually install multiple release candidate viewers side-by-side and with the de facto release viewer, you much ensure, in accordance with your operating system, that:

  • Any shortcuts / start menu links (e.g. Windows) you have for the viewer are renamed before you install any release candidates
  • Each release candidate is installed into a unique folder
  • Any shortcuts / start menu links (e.g. Windows) which are created as a part of the installation process are given unique names before installing the next release candidate

Notes:

  • If you provide unique destinations for each release candidate installation thorugh the installer package (e.g. Windows), make sure the installer is listing the correct destination folder when manually downloading and installing a subsequent release / update
  • The Windows auto-updater will automatically install into the last folder defined in the viewer installer (so if you have manually installed “Release Candidate A” and then “Release Candidate B” into separate folders, then get an update for “Release Candidate A” via the auto-updater, it will install into the folder for “Release Candidate B”)
    • Disabling the auto-updater in Preferences may not stop this from happening.
    • Instead, go to  viewer install folder/app_settings, then edit settings.xml, and find the entry UpdaterServiceURL and change  https://update.secondlife.com to https://secondlife.com/no-thanks (or similar) and save. You may need Admin privileges to do this.

Changes to this Blog

I maintain a list of viewers recognised as being used with Second Life (predominantly, but not exclusively, based on the Third-party Viewer Directory), which is updated as a when I become aware of new viewer releases being made. The section of this page which deals with the SL viewer has been updated to reflect the new viewer release process, and now includes all SL viewers currently listed in the SL viewer download page and the Official Alternate Viewer wiki page (with the exception of the Amazon channel viewer, which is the version of the viewer offered through Amazon.com).

Related Links

SL projects update week 28 (2): server, SSB/A update

Posted on by Inara Pey

Server Deployments – Week 28

As always, please refer to the week’s forum deployment thread for news, updates and feedback.

On Tuesday 9th July, the SLS Main channel received the server maintenance package previously deployed to all three RC channels in week 26.

On Wednesday 10th July, the three RC channels received the following packages:

  • LeTigre had Server-side Baking / Appearance code enabled. See my mini-update here
  • BlueSteel received a further package of under-the-hood changes related to the experience tools
  • Magnum received a server maintenance project intended to fix a couple of pathfinding issues:

Week 29 Deployments

While the final arrangements for the week 29 deployments (week commencing Monday July 15th) have yet to be finalised, Maestro Linden indicated at the Server Beta meeting on Thursday July 11th that there is likely to be one new server maintenance package going to an RC channel during that week, This is likely to have:

  • Further fixes for various crash modes
  • An additional update for pathfinding characters with CHARACTER_STAY_WITHIN_PARCEL=TRUE, which should enable such characters to re-enter their assigned parcel should they accidentally exit it (as a result of being pushed out, for example), rather than getting stuck
  • Fixes for issues such as:
    • BUG-2931 ‘run_time_permissions no longer triggers in attachments after requesting 0 permissions’
    • BUG-969 ‘teleporting breaks collision detection state for volumedetect objects’

Obviously, I’ll have more on the deployments for the week when details have been published by the Lab.

Server-Side Baking / Appearance Deployment

The enabling of SSB/A on LeTigre on Wednesday July 10th proceeded smoothly, and there have been few problems noted. Most testing the capability are reporting it functions smoothly and are seeing improved avatar skin / clothing layer rendering with few periods of extended avatar blurring.

It’s not entirely clear how SSA/B will proceed from here; it appears as if the Lab plans to keep to the cautious approach previously indicated by Nyx Linden rather than rushing forward to enable the capability right across the grid. As such, Log Linden indicated at the Server Beta meeting on Thursday July 11th that either BlueSteel or possibly – given it has a slightly larger number of regions than BlueSteel – Magnum will have SSB/A enabled next.

Have you updated to a viewer supporting SSB/A?
Have you updated to a viewer supporting SSB/A?

Log Linden came in for a number of additional questions on the new baking / appearance service during the Server Beta meeting on Thursday July 11th. Although I’ve covered the topics asked about in previous reports, I’ll note them here for ease-of-reference:

  • The baking / appearance service is entirely separate from the simulator servers, operating on its own dedicated servers. This means that when the service caches your outfit, it is effectively cached “grid wide” and not the simulator you happen to be on when you update your outfit
  • When two avatars are wearing exactly the same outfit, they both use the same copy of the outfit cached on the baking / appearance service. The Lab is aware this will only happen on rare occasions, and will most likely only happen in the case of library avatars
  • How long an outfit remains cached on the baking / appearance service depends on how popular it is. So if it is an outfit you are frequently changing into, it is liable to remain cached for longer than an outfit you wear, change out of and then leave it unworn for several days or more
  • Outfits which are removed from the baking / appearance cache are not deleted from inventory or anything – it just means that the baking / appearance service no longer has the data for the outfit, and so must wait until the outfit is uploaded from the viewer once more (although this shouldn’t visibly slow down the baking process)
  • Rebaking functions differently on SSB/A enabled regions: rather than uploading your appearance from your viewer to the server for distribution to the users around you, using the rebake (CTRL-ALT-R or menu option) causes the viewer to request a fresh download of your cached appearance
  • Should the server cached version of your appearance somehow become corrupted, you must add a clothing item in order to force a fresh update of your appearance from your Current Outfit Folder to the baking / appearance service
  • When you enter an SSB/A-enabled region for the first time, your own avatar will initially render grey before your skin and clothing layers re-render correctly. This is expected behaviour and due to you switching-over to the new baking / appearance service.

Anomalies

There have been some reports of odd anomalies in LeTigre regions (where SSB/A is enabled). These include:

  • A report that if you wear a 50% gray textured skin, you appear invisible to SSA viewers
  • Rather than appearing as a cloud in SSB/A-enabled viewers, avatars on non-SSB/A viewer entering LeTigre regions will actually render, but any outfit changes they make won’t render to those using SSB/A-enabled viewers unless they teleport to a non-SSB/A enabled region to change, and then return to LeTigre (something which will obviously not be possible once SSB/A is grid-wide).

Notecard Issue

One problem which has been confirmed with LeTigre regions is BUG-3203 (Error when adding contents to a notecard and saving). If you create a notecard on a LeTigre region and embed another item within it (another notecard, an LM, a texture), the notecard will not save, but will generate the following error: Unable to upload (asset ID number) due to the following reason: The server is experiencing unexpected difficulties. Please try again later.

General Feedback

Overall, feedback appears to be positive, going on comments in the forum deployment thread and made at the Server Beta UG meeting. Some people have reported performance dips while on LeTigre regions and attributed them to SSB/A, although this may be a placebo effect. There have also been so reports of viewer crashes when trying to walk between a non-Le Tigre region and a LeTigre region.

Most people who have carried out comparative testing between LeTigre regions and regions on other channels are reporting that avatar rendering on Le Tigre is significantly faster, with avatar skins and clothing appearing fully rendered in around 15 seconds in regions with a reasonable number of other avatars, and none of the general fuzziness or “double rebakes” which can be witnessed on the “old” baking process. Some are also reporting that they are seeing some improvements on non-SSB/A regions when using an SSB/A-enabled viewer, although this again may be something of a placebo effect.

My own rather quick-fire tests with the SL viewer 3.6.1.278007, Firestorm 4.4.2 and Exodus 13.7.9.1 beta revealed no discernible issues. The majority of avatars tended to render together with visiting regions with a reasonable number on them. I didn’t notice any clouds around me in the more crowded locations I dropped into and where I did experience performance drops, although I put those down to the fact the locations (a club and a hub) were busy with 15-20 avatars in each and had a lot going on rather than being anything intrinsic to SSB/A, nor did I witness anyone remaining grey for an inordinate amount of time.

Related Links

Lance gives an update on the Dolphin Viewer

Posted on by Inara Pey

dolphin-logoWith Server-side Baking / Appearance starting to be enabled on the grid, the only two maintained viewers not to be SSB/A enabled are Dolphin and Imprudence.

I recently covered the state-of-play with Imprudence, and the fact that the team plan to ramp-up the viewer to support all of the new SL  capabilities and viewer changes, including CHUI, materials and SSB/A, but it is liable to be some time before they actually get there.

Now Lance Corrimal, the man behind Dolphin, has provided an update on the status of that viewer. The main part of his blog post reads:

I’m sure there are one or two people wondering what is going on with the Dolphin Viewer lately.

To put it simply, my life has been quite hectic the last few months, and it still is. I have a new job that demands a lot of my time and attention. I’ve moved to a different province because of the job, and when I am actually home (the new job involves a lot of travelling), I’m just too damned tired to spend time on working on the viewer.

That being said, there will be a new version, that will have all the new shinies from the Lab. The CHUI interface, SSA, Materials, you name it.

Just … please do not ask me when. “When it is finished” is all I can say right now.

So – SSB/A and more will all be coming to Dolphin – soon. Just give Lance a little room to breathe as the dust of a busy real life settles around him.

He also notes that Dolphin users seeing the advisory warning users of a mandatory viewer update which is displayed on the splash should be aware that clicking on the link will download the official SL viewer, not an updated version of Dolphin.

The splash screen advisory - comes from LL, and will download the official viewer, not Dolphin
The splash screen advisory comes from LL (along with the rest of the splash screen), and will download the official viewer, not an updated version of Dolphin