The Viewer Release Process and Viewer News
There are currently five viewer release candidates sitting in the viewer release channel. These are:
- CHUI updates
- Cocoa updates for the Mac version of the viewer
- Google Breakpad updates (fixes and updates to improve the level of crash reporting from the viewer)
- Maintenance viewer updates
- Snowstorm updates (third-party contributions to the viewer)
As the first release candidate has now become the de facto viewer release (the Vivox updates, see part one of this report), all of the remaining release candidates are undergoing rebuilds using the “new” release viewer code base, and this is expected to be completed in week 33.
The current number of release candidates is considered to be atypical of the process, and reflects the fact that there is a backlog of viewer updates to be cleared. Once this has happened, it is anticipated that the number of release candidates within the viewer release channel will fall. In the meantime, it means we could be seeing new viewer releases (i.e. release candidates being promoted to the de facto release viewer) at the rate of one a week, depending upon how well individual RCs perform in user testing, until such time as the number of RC viewers becomes more manageable.
Installing Multiple Release Candidate Viewers & the Auto-updater
By default, release candidate viewers are intended to install / be installed into the same location as the de facto release viewer. Therefore, if you wish to run multiple RC viewers, you must install them manually into separate folders.
However, there is a problem in installing multiple RC viewer under windows, whereby the last location used to install a viewer is recorded by the installer (presumably as a registry setting), and the auto-updater will automatically use that location to install any update. So, if you manually install “Release Candidate B” into its own folder, and then receive an update for “Release Candidate A” (already installed on your PC) via the auto-updater, it will be installed into the folder containing “Release Candidate B”, overwriting it. This may even happen if the auto-updater is “disabled” within viewer preferences (see here for notes on how to avoid this).
At least one JIRA (non-public BUG-3522) has been raised against this issue. However, while LL are still investigating the problem, if it lies within the installer itself, it may not be addressed as there is an unwillingness at the Lab to get deeply involved in the mechanics of the installer.
There have been reports of the auto-updater mechanism forcing people to downgrade their installed viewer to an earlier release. While it “shouldn’t happen”, and may have been fixed, anyone who does experience the problem when auto-updating a viewer is asked to raise a bug report with as much information as possible on what happened (i.e. version being run before the update, version running after the update, date of update, etc.).
Making the Viewer Management System Available to TPVs
The Lab is experimenting with making the viewer management system available to TPVs if they wish to make use of it. This will mean that TPVs will have to port the code for use in their own viewer / environments, but it could help them with automating viewer updates if they don’t already have such a mechanism in place. One of the potential benefits of this for those TPVs following the Lab’s lead is that, as a result of changes also being made to the Lab’s reporting mechanisms, they will be able to receive a range of stats reports on their viewers directly from the Lab.
The current Snowstorm release candidate includes a change to how the settings.xml file works (the file which controls your viewer settings). This change will only affect those who have more than one Linden Lab viewer installed on the same computer (for example, someone who has the release viewer, a beta viewer and several project viewers installed), and will see all of the installed LL viewers using the same settings.xml file, rather than each creating a separate version of the file. This should prevent issues where the settings from one LL viewer are incorrectly applied to another, as can sometimes occur at present.
Interest List News
As noted in earlier parts of this report, Andrew Linden has wrapped-up his current work on interest lists. However, the project viewer for some of the work still has yet to appear, and is apparently still encountering problems getting through LL’s QA process. The code has been “real close” to being ready for release in some form on a number of occasions before getting kicked back for further work. The hope is that it will appear as a project viewer – or possibly a beta or release candidate – “soon”.
Server-side Appearance Update
Number-crunching has been continuing with the current deployment of SSA on Magnum and LeTigre and Nyx Linden reports that it is still all looking “pretty good”.
Further to Simon Linden’s comments at the Server Beta meeting on Thursday August 8th, Nyx confirmed that no additional regions will be SSA enabled in week 33, but that grid-wide enabling could occur in week 34 (week commencing Monday August 19th).
In terms of the back-end updates which Simon also mentioned, Nyx gave further information on the work:
We are going to be rolling-out some changes to the back-end servers, the ones that are actually doing the baking. You shouldn’t see much difference, but there were a couple of scenarios where the viewer would have to re-try requests when it shouldn’t have to. So we’re trying to get that cleaned-up before we roll-out to the whole grid.
Again, just to emphasise: the changes Nyx is talking about are to the dedicated server-side appearance servers, not to the simulator servers, so there will be nothing in the deployment notice in week 33 relating to the work.
SSA Viewer Updates
Nyx reports that the next set of viewer-side changes will be available for TPVs soon; he’s currently waiting a further merge-up with viewer release. He also indicated the Lab is getting close to having a “pretty good set” of the new inventory functionality (AIS updates – see part one of my week 30 report), which will see Current Outfit Folder communications between the server and the viewer handled as capabilities within the service, rather than relying on UDP messaging (a possible point of failure). While the code is not yet ready for public testing or TPV integration and has yet to pass LL’s own QA, he is hoping to get the code to an external repository so that TPVs can at least start looking at it.
Monty Linden has been carrying out further performance testing on his mesh related HTTP work. “It looks good,” he informed the TPV Developer meeting on Friday August 9th, “The goal with this one isn’t so much performance improvements, but much better connection behaviour. Generally, I’m getting the same mesh throughput with one-quarter of the number of connections [eight as opposed to the original 32]”.
He still hopes that his work will emerge in a project viewer before the end of August, although this is not certain. In the meantime, the associated server-side changes are ready to be QA’d, although there is also no date as to when they will be incorporated into a deployment package.
A complicated series of questions were asked at the TPV Developer meeting as to whether Kelly Linden’s work on adding server-side LSL AO capabilities might at some point herald the arrival of a client-based AO capability within the LL viewer (such as implementing an API which would allow the viewer to utilise the new LSL capabilities).
It’s not clear whether this has been considered within the Lab, and Oz indicated he would check on what the plans (if any) are for the new capabilities going forward, given that the Lab is trying to “make AO work better” (which doesn’t necessarily mean they are trying to make all existing AO systems work better, but rather that there should be a better way to build AO systems), and whether any API might be in anyone’s thinking.
Object and Texture Caching
During the TPV Developer meeting in week 26, the issue of problems within the object / texture caching came up, with Oz suggesting it might be an idea to consider forming an LL / TPV project to look into the issues and determine possible remedies.
While the idea has been taken back to the Lab for consideration, there is a certain reluctance to commit to it on the part of product managers because complex relationship between the viewer’s multiple caches and its core code. Or, as Monty Linden put it, because “there are surprising couplings between cache designs and functional code – it is hairy like a Sasquatch.”
This means the work required in teasing them apart to determine root causes to problems and resolving them could be a long and intensive process, with the end benefits difficult to quantify and qualify from the outset.
A further problem with such a project is gaining consensus on what actually needs to be done in order to fix issues and problems which come to light – a fact demonstrated by the fact that a TPV team looked at caching themselves and could not agree on the best means to handle the issues they uncovered.
Therefore, while such a Lab-led project is not outside the bounds of possibility, it will likely remain at the back of the queue behind other things which can be done within the viewer which are either easier to achieve and / or less likely to generate disagreements as to how they should be handled.
Liquid Mesh Concerns Voiced
Liquid mesh is the brand name for mesh items which (I’ve been informed) is based on the technique first proposed by Redpoly Inventor. It first appeared at the end of 2012 (Nalates Urriah has a review). This technique works by rigging to the avatar’s collision volume rather than the avatar’s skeleton and which, more particularly, uses unsupported bones outside of those recommended for mesh rigging.
While the Lab has repeatedly stated the technique is unsupported and could therefore be adversely affected by future changes to Second Life, concern has been expressed that these warnings are largely invisible to users who purchase mesh items using the technique, and that unless something is done to clarify matters, the Lab could face a huge PR backlash among users should something happen which does end up “breaking” this content.
One way of overcoming the situation would be for the Lab to accept the technique and regard it as supported. Should they decide to continue to regard it as unsupported, views were expressed that they should consider stopping the mesh uploader accepting mesh content which is rigged to unsupported bones – although this also is not without issue.
Nevertheless. the current situation is perceived as being the worst of all possible situations. Whether or not the Lab moves on the matter – and how – remains to been seen, although the indications are that they are unlikely to adopt the technique as a supported capability (although the reasons why were not entered into at the meeting).
- TPV Developer meeting video – Chakat Northspring