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
Update Wednesday July 10th: In checking the forum deployment thread for this week’s roll-outs, I see that KarenMichelle Lane has provided a list of regions on LeTigre where SSB/A will be enabled once they have restarted. Again, you’ll need to have an SSB/A-enabled viewer to avoid issues with avatar rendering on these regions. If you find that once the restarts have completed you are encountering issues with avatar rendering (for example, you are using an SSB/A viewer and find you avatar fails to render for yourself or others), or other issues which appear to be linked to SSB/A, please consider raising a bug report detailing the problem, how to reproduce it, and including your environment information (Help > About (Viewer Name) > Copy to Clipboard), which references Project Sunshine.
Server Deployments – Week 28
As always, please refer to the week’s forum deployment thread for news, updates and feedback.
Second Life Server (SLS Main) Channel
On Tuesday 9th July, the SLS Main channel received the server maintenance package previously deployed to all three RC channels in week 26. This comprised:
A fix for ‘llApplyImpulse now works only in the root prim’ (SVC-8227)
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.
Viewer Updates and Release Process
The Second Life Beta viewer updated to release 3.6.2.278133 on July 2nd – see the release notes for change details.
The Materials Project viewer was also updated on July 2nd, to release 3.6.2.278221.
Speaking at the Opensource UG meeting on Monday 8th July, Oz indicated that he hoped the new viewer release process would go live on Tuesday July 9th. If this has in fact happened, the first viewer to pass through the new process is likely to be a project (or beta viewer) with further third-party code contributions to the SL viewer.
However, as both the SSB/A deployment and the new viewer release process both require an update to the login code, it is possible the new viewer release process will not go live until Wednesday 10th July.
The login change for the viewer release change is to update the automatic check which is carried out to see if a mandatory upgrade is required (see my week 20 report). To prepare for the new release process, is check has been updated. , the login change for SSB/A is described by Oz Linden as, “a very minor change to ensure that inventory is correct” .
Group Ban List
Baker Linden and his new harido
Baker Linden continues to work on the new group ban list functionality (JIRA VWR-29337). Speaking at the Simulator User Group on Tuesday July 8th, he said:
For my update: I’m making really good progress on group bans. I’m doing a bit of a refactoring because I changed the way the backend works slightly. Hopefully by the end of the week I’ll be finishing up the backend code.
There’s currently no date as to when the viewer-side changes might see the light-of-day, but given Baker is currently working on the back-end, this is hardly surprising. He’s also indicated that while it won’t be available when the new functionality goes live, he is considering adding scripting functions to group bans. He also confirmed that group bans would have their own moderation capability, rather than being tied to estate ban moderation.
Particle System Updates
Particle Blocking
As previously reported in these updates, the new “right-click on particles to block and emitter” (MAINT-2268) code for the viewer has been released in the SL Beta Maintenance Viewer. As well as allowing people to click on particles to prevent the viewer generating any more particles in someone’s world-view, the code also has a FPS limit on particles and will stop generating new particles when frame rates drop to 4 FPS.
Those who have tested the capability report it works well and it is very easy to right-click on particles and block them. A slight bug has been reported whereby when unblocking a particle generator / person owning a particle generator, the viewer will not resume generating the particles until the user changes their group tag.
New Particle Capabilities
First reported on in these pages back in week 12, the new particle capabilities – glow, ribbon and blending optionshave had server-side support for some time. The Beta Maintenance viewer mentioned above now has the first part of the viewer code, and speaking at the Simulator User Group meeting on Tuesday July 8th, Simon Linden said, ” Once that one is out, we’ll get the next one going,” so expect these capabilities to be becoming more radily available in the near future.
Ribbon particles – one of the new particle capabilites
Other Bits
Snapshot Fixes
The SL Beta Maintenance veiwer includes further snapshot fixes (MAINT-2152) which are designed to overcome the problem of black rectangles / borders appearing in very high resolution snapshots. These fixes are in addition to the “tiling” fix issued last year.
However, Whirly Fizzle reports that if very high-res snapshots are captured with the Beta Maintenance viewer and post-processed, the tiling artefact tends to return.
Post-processing high-res images captured using the additional snapshot updates (as found in the current SL Beta Maintenance viewer) can result in tiling artefacts reappearing (image, originally in PNG format, courtesy of Whirly Fizzle.
Simon Linden reports that a further update to these fixes is about to be released, although it is not known at this time if it will fix this issue, or a reported issue of GPU crashes when using the Beta Maintenance viewer for snapshots.
Your Skin – In the Sky
The issue of avatar skins appearing in the sky at very high altitudes (see JIRA VWR-28962) came up for discussion at the Simulator User Group. First reported in 2012, there is some speculation whether SSB/A will impact the frequency with which the issued manifests; it appears to be linked to the local bake process, and so may only occur in the future when people at high altitudes are editing their appearance.
The “face-in-sky” issue (image courtesy of Eku Zhong)
In the meantime, if you are up high and encounter this phenomenon, try toggling the Advanced Lighting Model option in Preferences > Graphics off / on.
With Server-side Baking / Appearance due to be enabled on the LeTigre Release Candidate Channel on Wednesday July 10th (from which it will gradually roll across the grid), the Exodus team have issued a new version of the popular Exodus viewer. Classified a beta release, the new viewer update has the version number 13.7.9.1, and includes the latest code updates from the Lab.
This means that with this release, Exodus is:
Server-side Baking / Appearance ready
Includes the Lab’s Communications Hub User Interface (CHUI)
However, the release:
Does not include materials processing support
RemovesRLVa support.
CHUI and SSB/A
VHUI now a part of the Exodus viewer
There is not actually much to report here per se, other than both work entirely as expected. CHUI sees the LL integrated chat / IM conversations floater working in Exodus.
Simlarly, SSB/A works exactly as expected on SSB/A-enabled regions, with other avatars rendering correctly in Exodus, and your own avatar rendering correctly to others.
Exodus SSB/A: (l) my avatar on Exodus and my CTA on the SL viewer – both render correctly in Exodus on the Aditi SSB/A test regions. (r) The same agin, but this time my avatar (foreground) on Exodus, as rendering in the SSB/A-capable SL viewer.
That both SSB/A and CHUI do work flawlessly tends to hide the amount of work the Exodus team have put-in getting both ready to go prior to SSB/A being enabled server-side.
Why No Materials and RLVa?
Materials
Both the integration of CHUI and SSB/A capabilities into a v3-based viewer are very large amounts of work (CHUI has something like over 1200 change sets of its own). They therefore require time and effort to implement – and have likely been keeping the Exodus team more than a little busy (on top of some of them being actively engaged in developing the materials capabilities in SL as well as working on other items such as the Mac Cocoa project).
There’s also the fact that while materials doesn’t use CHUI itself, both the materials code and the CHUI code touch on other areas of the viewer code. Therefore, it makes sense for the Exodus team to focus on implementing CHUI first and then merging and cleaning the materials changes sets (which is exactly the order in which the Lab did things), rather than racing to implement materials, only to find those updates impacted at a later date by required CHUI updates.
So for all those hoping to see materials in Exodus – it will doubtless be coming, you’ll just need to wait a little longer.
RLVa Removal
The blog post for the release explains the reasoning behind the removal of RLVa support from Exodus thus:
By its nature and by necessity, RLVa is an extremely invasive patch. We do not have the resources to maintain this code, and it is the primary reason for our lack of updates recently. We hope that this removal enables us to produce more frequent updates going forward and apologise for the inconvenience.
While the loss of RLVa is perhaps to be regretted, how much it is likely to be missed obviously comes down to the number of Exodus users who make use of it, obviously – and it is worth pointing out that RLVa was something of a late arrival to Exodus in the first place, so it may not be that greatly missed.
Other Updates
This release also sees Exodus:
Using Cocoa instead of Carbon on Mac computers
Gain full screen support on Lion
Fain Retina support for the Retina MacBook Pros.
Feedback
This is not an in-depth test of the latest Exodus beta, but a quick spin around the Aditi block. Everything works, as notes, as expected, and the rendering enhancement which have been part and parcel of Exodus for a long time certainly make their presence felt even in a default rough & ready snapshot such as the one grabbed above for the SSB/A comparison.
I didn’t do any performance tests this time around, as I was on Aditi – I’ll save that for another time :). That said, I’ve always found Exodus to be a solid performer on my current hardware, where it has tended to be my “reserve” viewer (along with Dolphin).
This is a very tidy and timely update to Exodus which brings it back to a par with other popular v3 viewers, and perhaps even a little ahead with the Cocoa support. Kudos to the team!
Inara Pey: Living in a Modemworld 