As always, please refer to the week’s forum deployment thread for news, updates and feedback.
On Tuesday July 16th, the SLS Main channel received the server maintenance package previously deployed to Magnum in week 28.
On Wednesday July 17th, the three main Release Candidate channels received the following updates: individual updates:
Magnum became the RC with the server-side baking / appearance project enabled (SSB/A is disabled on LeTigre). This move was made to expose SSB/A to a larger number of regions and a larger number of users as a result
BlueSteel received a further package of under-the-hood changes related to the experience tools
LeTigre received a new server maintenance project, which included fixes for several issues, including a further updated for pathfinding characters using CHARACTER_STAY_WITHIN_PARCEL getting stuck if they somehow exited their home parcel. It also added “RenderMaterialsCapability” to the /simulator/features cap, which indicates the access rate allowed when accessing the “RenderMaterials” capability, and Increased the “RenderMaterials” capability access rate to 4 requests per second (up from 1).
SL Viewer Updates
Release Candidate Viewers & the Release Process
The first of the viewer Release Candidates became public on Thursday July 19th. This is a maintenance update (3.6.2.278602) with a number of individual fixes from LL’s viewer maintenance team.
While the actual order of release is not clear, it appears that the next Release Candidates which will be added to the viewer release channel will be:
Viewer Breakpad changes
The Vivox updates
A Snowstorm (code contributions) build.
Which of these RCs is promoted to be the defacto release viewer will be depend upon a number of factors, including how well each performs as a release candidate (in terms of performance, crash rate, etc.).
Because Release Candidates are “cohorts” within the viewer release channel, you cannot download them as a distinct viewer installer package via the Official Alternate Viewers wiki page. However, release candidates can be tracked (and the source code obtained by those interested in self-compiling viewers) from the Official Viewer Source Repository page.
To give some idea as to why the new process has been introduced, Simon Linden indicated there is around four months of viewer work currently backed-up and awaiting release. This may mean that initially, there might be a higher bumber of RC viewer cohorts in the release channel than will be the case once the backlog starts to clear.
I’ll be endeavouring to keep pace with official viewer updates, including cohorts, through my Viewer Round-up Page.
Settings.xml
The plan to use a single settings.xml file for all installed versions of the SL viewer is currently dependent upon a snowstorm code contribution which is currently in the pipeline. Once this has been implemented within the viewer code, it should help eliminate problems of users on the SL viewer reporting their settings have been “eaten” / overwritten should they move between different versions of the official viewer (i.e. swapping between the release viewer and a project viewer and back again).
Group Ban List
Baker Linden continues to work on the group ban list project (see JIRA VWR-29337). The last time he was available for an update at the Simulator User Group on Tuesday July 10th, he indicated that he was working on the back-end code, which required a lot of refactoring and which he was hoping to get finished by the end of week 28 prior to moving to the viewer-side code.
Speaking on his behalf at the Server Beta meeting on Thursday July 18th, Simon indicated that Baker may have achieved his goal, and is now working on the viewer side of things and the UI.
Experience Tools
Again, no major news here. The server-side updates (which presumably include the long-awaited permissions system updates) continue to reach RC channels, but there is no news on the viewer-side updates which are expected to be appearing in a project viewer at some point in the (hopefully) near future.
As always, please refer to the week’s forum deployment thread for news, updates and feedback.
Second Life Server (SLS Main) Channel
On Tuesday 16th July, the SLS Main channel received the server maintenance package previously deployed to Magnum in week 28, intended to fix a couple of pathfinding issues:
A fix for the navmesh bug whereby pathfinding rebakes are continuously triggered if a region has more than one parcel and has no parcel edges above water, then it thinks it needs to rebake (BUG-2975) – see part 2 of my week 26 report.
A slight issue at the start of the rolling restart process on Tuesday 16th July meant that some regions on the main channel experienced to restarts, with the second updating to the correct release.
Release Candidate Channels
On Wednesday July 17th, the three main Release Candidate channels should each receive individual updates, as follows:
Magnum will become the RC with the server-side baking / appearance project enabled
BlueSteel should receive a further package of under-the-hood changes related to the experience tools
LeTigre should receive a new server maintenance project, which includes the following fixes and new features:
Fixes:
BUG-969 “teleporting breaks collision detection state for volumedetect objects”
BUG-2931 “run_time_permissions no longer triggers in attachments after requesting 0 permissions”
A further fix for the issue of pathfinding characters using CHARACTER_STAY_WITHIN_PARCEL getting stuck if they somehow exited their home parcel
New Features:
Added “RenderMaterialsCapability” to /simulator/features cap, which indicates the access rate allowed when accessing the “RenderMaterials” capability
Increased the “RenderMaterials” capability access rate to 4 requests per second (up from 1)
Viewer Updates and Release Process
As I reported at the time (see New viewer release process implemented), the new viewer release process went live in week 28. I’ve provided a complete breakdown of the process and what it means in general, for those who wish to know more.
This has seen a number of beta and project viewers appear on the revised Official Alternate Viewer wiki page, with updated viewers including:
On July 15th the Second Life Beta channel saw a new release – version 3.6.2.278491 (release notes)
CHUI updates continue to appear first in the CHUI project viewer, which released version 3.6.2.278372 on July 9th
The project Cocoa viewer for the Mac also updated on July 15th, to version 3.6.1.278025.
SSB/A Update
In a late change to the deployment schedule, Magnum will the RC channel to have SSB/A enabled following the rolling restarts on Wednesday July 17th.
This will include a fix for BUG-3203, the “notecard bug” I reported on in week 28 (with thanks to Whirly Fizzle), wherein if you create a notecard in an SSB/A region (i.e. a region on the LeTigre RC at the moment) and attempt to embed anything in it (e.g. LMs, textures, other notecards), the notecard will fail to save with the message: Unable to upload (asset ID number) due to the following reason: The server is experiencing unexpected difficulties. Please try again later.
This summary is published every Monday and is a list of SL viewer / client releases (official and TPV) made during the previous week. When reading it, please note:
It is based on my Viewer Round-up Page, a list of all Second Life viewers and clients that are in popular use (and of which I am aware) and which are recognised as adhering to the TPV Policy
By its nature, this summary will always be in arrears
The Viewer Round-up Page is updated as soon as I’m aware of any releases / changes to viewers & clients, and should be referred to for more up-to-date information
The Viewer Round-up Page also includes comprehensive links to download pages, blog notes, release notes, etc., as well as links to any / all reviews of specific viewers / clients made within this blog.
Updates for the week ending: July 14th, 2013
Official LL Viewers
Project CHUI channel updated to 3.6.2.278372 on July 9
Update, September 15th, 2024: the viewer release process defined below has been replaced:
Linden Lab now maintains a single Develop branch for the viewer, into which updates all pass for internal viewer builds, and from which Release Candidate viewers are peeled and made available.
This is tied to a “featurettes” approach to new features and capabilities, whereby these may be added to the viewer and deployed within Release Candidates, but place behind debug settings / remain “turned off” until such time as all dependencies on their use (e.g. back-end support) are in place / LL are confident they are ready to be made fully available.
Update July 23rd, 2013: 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.
The 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.
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.
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
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).
A fix for the navmesh bug whereby pathfinding rebakes are continuously triggered if a region has more than one parcel and has no parcel edges above water, then it thinks it needs to rebake (BUG-2975) – see part 2 of my week 26 report.
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?
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.
With 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 (along with the rest of the splash screen), and will download the official viewer, not an updated version of Dolphin
Inara Pey: Living in a Modemworld 