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 as the week progresses
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.
As reported in the first part of this update, the SLS Main channel was rolled back to release 13.04.05.273580, as a result of a widespread performance issue. This unfortunately saw the removal of the new LSL animation capabilities from the channel.
The issue itself is related to problems with regions locating their neighbours. “The sim were hitting the [region presence lookup] service too hard, causing stability problems.” Maestro Linden said at the Server Beta meeting on Thursday May 2nd. Release notes.
In the original notes for this week’s deployments, BlueSteel and LeTigre were scheduled to receive the same deployment package. However, this was subsequently changed so that:
BlueSteel received the same reversions as the Main channel due to the performance issue between neighbouring regions, but also received updates for the Experience Keys project as originally planned. Release notes.
LeTigre received the same code that was on the main channel in week 17, the only difference being that it fixes the performance issue that caused the Main channel to be rolled back this week. Release notes.
Maestro described the deployment of the fix for region lookup issues as the “conservative option”, rather than deploying the fix to multiple Release Channels, “In case the changes from the other two channels have their own problems.”
Magnum received the package originally scheduled for it, described as bringing some new minor features to LSL, and fixes some crash modes as well as the fix for grid performance issue, and fixing an issue in which llDialog() messages sent to the object owner could be incorrectly throttled. Release notes.
The hope is that if all is well with the Magnum update, it is liable to be deployed to the Main channel in week 19.
SL Viewer Updates
Beta Viewer Release
A new beta version of the viewer emerged on May 2nd, using the 3.5.2 code (3.5.2.275087). This release includes the update from FMOD to FMOD Ex, and well as a number of other maintenance and other fixes as specified in the release notes. However, it does not include the anticipated Vivox updates to improve SL Voice. These will be coming along at a later date.
The current plan is for this release to remain in the beta channel for at least one further update prior to it appearing in the release channel. As such, it is unlikely to be in the release viewer until late in week 19 or in week 20. Once it has appeared in the release viewer, LL will probably deploy the new viewer release process, and the beta channel will cease being used.
Viewer Release Process
Oz Linden
As previously reported, the viewer release process will be changing in the coming weeks. As a part of this, the development viewer channel has already been deprecated; however it will still be a while before the new process is put into place, as further infrastructure changes are still required on LL’s part.
Concerns have been raised by TPV developers about a side-effect of the new process potentially being that the rate at which code becomes available to them may slow down, thus causing them to “fall behind” the LL viewer in terms of new functionality or capabilities. Stressing that this is not the intent, Oz Linden described process in further detail at the TPV Developer meeting, indicating that under the new system:
Viewer projects will each have their own repositories, which will be made available to TPVs (and others) once it is deemed they are “safe to share” as a project or “beta” viewer
While it has yet to be formally decided within LL, and may take a little time to work up to, critical bug fixes are liable to have their own repositories, from where they can be merged into other viewers
Users will be able to pick which beta / project viewer(s) they download from the Alternate Viewer wiki page without being tied to any specific update route (so you can download and run as many project / beta viewers as you like)
Once a project is believed to be of release quality, it will be put into a release candidate, built on the current viewer release code and released to a target number of users (as chosen by LL), alongside other release candidates being used by other users
When a user receives a release candidate viewer via the download page, the updates they receive will be offered on the basis of the release candidate they are currently running (for example, if a user is running the Materials RC viewer, they won’t be offered updates from, say, the SSB/A RC viewer)
After some period of time, and when LL have looked at the results, one of the release candidates will be promoted to the default download (without the viewer having to be rebuilt) and will be available on the main download page
The remaining viewer projects (at least those at release candidate status) will then be merged with the newly-released viewer code, and re-test and issue a further release candidate, which may in turn be selected as the next candidate for promotion to the default download.
He added that in terms of TPV’s concerns over code being made available to them, the level of co-operation which has been evident in the Sunshine project (SSB/A) has “not gone unnoticed” within LL’s management, and that the team involved has received a lot of kudos for the way they have handled interaction with TPVs. As such, it is likely that the Lab will endeavour to build on this going forward.
The Carter and Dar Show, hosted by Carter Giacobini and Dar Writer, isn’t something, I confess, I watch on a regular basis. There’s no bias here on my part, it’s just that I don’t have time to take everything going on in and around SL to take everything in.
However, on May 3rd, they broadcast a show featuring Jessica Lyon, recorded just after the release of Firestorm 4.4.0, so I tuned in to take a look. The show is just under an hour in length, with the interview with Jessica starting at the 12:50 mark.
Jessica Lyon with
During the show, Jessica talks about a range of topics, including: Server-side Baking / Appearance; the HTTP updates, very LOUD users, viewer bugs (and how it’s not always easy to catch everything), the “missing prim” issue and the interest list, why the z-offset Quick Preference is no more in Firestorm, and more. She also explains some of the reasoning behind Firestorm and why it focuses so much on features and capabilities in comparison to the official viewer.
So, if you’re looking to find out more about Firestorm and what might be coming down the road, take a look at the Carter and Dar Show.
Following-on from the announcement of a new process for viewer releases Oz Linden provided more information on the process as it will operate going forward during the Open-Dev meeting on Wednesday May 2nd, and gave a clarification on my original post after I’d mistakenly referred to individual viewer “release candidate channels”, rather than more correctly, “release candidates”. His comment in full reads:
Oz Linden
The release candidates will be updates in the regular release channel, not separate candidate channels. The candidates will be in a named “cohort” within the channel, but the cohort name is not built into the viewer the way a channel name is, which means we will be able to move a candidate from its named cohort to the default without rebuilding it – the build we test will be exactly what we release. Candidates will be indistinguishable from the default release viewer (the one on the main download page) except for the version number and the new features.
The new process also means that officially, individual viewers will no longer be referred to by specific project channel names (such as CHUI, Materials Processing, etc.). Instead, they’ll be referred to by their full 4-part number (i.e. 3.5.1.274847 rather than the “Materials project viewer”). This also means there is likely to be at least one update to the Bug Tracker so that the Environment box in the form will no longer allow a report to be submitted until viewer channel and version number have been recorded.
As a result of these changes, Oz indicated that the development viewer channel has already been depreciated, and that the beta channel, as mentioned in my original piece will be depreciated as the Lab switches over to the new system. When a candidate viewer is ready for public consumption, it will appear on the Alternate Viewers wiki page where it can be downloaded.
I’ll be making changes to my Viewer Round-up Page to match the new system as it comes into play.
Current SL Viewer Status Update
In the meantime, and in the lead-up to the new release process, there is expected to be a further beta viewer release (3.5.2 code), which will include the FMOD Ex updates in it, and for which Oz extended thanks to the Singularity team for their work.
The Mac Cocoa project is a little stalled. This is because, to quote Oz, “We’ve been stealing people [TPV devs] from Cocoa to get Materials done. The good news is that it’s working, we’re really knocking down bugs at a steady clip.”
The mesh deformer also remains stalled. This is again due to manpower issues but this time internal to LL. However, Oz again wanted to reassure people, stating of the deformer, “There are things I’ve given up on at this job, but that isn’t one of them.” Sadly, his plate is also full with the Materials project at the moment, together with things like the new viewer release process.
Linden Lab have announced a revamp to the way in which they will be releasing viewer updates in future.
Currently, the process for the majority of viewer changes is that they go through a progression – generally being seen first in the development channel (or sometimes prior to that in a project viewer), before moving through to the beat viewer (where updates go through what is effectively a final validation / user test) prior to being adopted into the SL release viewer.
This system has generally worked, but can cause problems, particularly when there is a lot going on in terms of projects and updates, and things end up being “queued up” for the release (as is currently the case, where CHUI, Server-side Baking / Appearance, and a host of other updates / fixes are concerned all being “queued” awaiting their turn in the beta viewer release channel.
Another problem – as seen at the end of last year – can be that should a significant issue occur within the beta viewer code, it can completely block further viewer releases until such time as the problem can be tracked down and effectively fixed. Last year this meant that viewer updates were effectively stalled for around a two month period while LL sought to isolate and fix the problem.
To try to overcome any bottlenecks which might occur with viewer releases, the Lab is adopting a similar process to that used by the server-side code release mechanism, as the blog post explains:
We’ll release more than one new version at the same time in parallel to subsets of users for final validation, and then promote the most important of the best of those to the default Release Viewer when that testing shows it to be ready.
If a development project wants to put out an early version for testing prior to it being ready for the Release channel, a channel specific to that project (either ‘Project <project>’ for very early versions, or ‘Beta <project>’ for more mature ones) will be created, just like we do today. These will be shut down when the project is ready to move to final testing in the Release channel, and users in the early project test channels will automatically be upgraded to the corresponding Release candidate version.
This means that in the coming weeks, we’ll start to see different versions of the viewer start to appear in parallel in their own “release candidate” channels, and people will be able to choose which versions they want to download and try-out. Once it is deemed the code from a specific “release candidate” viewer is ready for release, it will be integrated into the SL viewer and made available to the community through the established mechanism. As such, the beta viewer channel will be vanishing in the near future.
Quite how well different flavours of the viewer will run together on a single computer for those who want to try-out more than one upcoming release remains to be seen. Generally, different versions of the SL viewer tend to play nicely together. However, as was seen with the 3.4 and 3.5 code base changes problems can occur. In that particularly instance, running a development or beta viewer using the 3.5 code and then swapping back to the SL release viewer on the 3.4 code resulted in all the toolbar buttons vanishing from the latter.
The overall hope is that this change will mean that specific features and updates will reach the release version of the viewer at a greater pace than can be achieved with the current process, which in turn should not only smooth the path for new capabilities and features to reach users quicker (allowing for the inevitable bugs and hiccups such projects tend to encounter anyway), but perhaps also help in get fixes for significant issues and problems out to the mainstream viewer.
On Tuesday April 30th, the Main channel was rolled back to release 13.04.05.273580, as a result of a widespread performance issue.
Release Candidate Channels
BlueSteel and LeTigre: both of these channels should remain on the Experience Keys project, but will also be reverting some changes, due to the same performance issue which is affecting the Main channel – release notes
Magnum: should remain on the same server maintenance project as week 17. This project brings some new minor features to LSL, and fixes some crash modes. This update fixes the grid performance issue, and fixes an issue in which llDialog() messages sent to the object owner could be incorrectly throttled – release notes.
The performance issue which caused the Main channel to see the re-deployment of an older release was described by Simon Linden as being related to problems with regions locating their neighbours. “The performance problem was really showing up between any one region trying to locate another on the grid … the system was actually working, but too close to the cliff for comfort.” The re-deployment means that the new LSL AO capabilities can no longer be compiled / run on any Main, BlueSteel or LeTigre regions, until the supporting code is rolled-out once more.
There is still no further detail on the Experience Keys project and whether this may / may not be more than a deployment of the Advanced Creation Tools permission system.
Interest List Update
Andrew Linden has been working on fixing a bug related to Meeroos (but which I’ve seen affecting other animals as well), which he describes as, “If you turn your camera away from a crowd of Meeroos, wait several seconds, then turn back around… the Meeroos will be updated, but not quite in the right order. So sometimes you’ll see a head move to the new position, then a fraction of a second later the rest of the body. So I have a theoretical fix that doesn’t crash the simulator (anymore).” The fix in question has yet to be tested and QA’d, so there is no time frame for any release.
“Missing” Prims
While talking about the interest list work, Andrew answered a question on missing prims / linksets, again acknowledging it to be a viewer-side issue, before going on to say:
We think maybe it is fixed in a new viewer. But this new viewer I mention happens to be very crashy, so we haven’t opened up the source code for it yet nor have we submitted it to our QA team since they’ll just crash … This is the viewer that goes with our new interest list changes which I mentioned a few weeks ago and people were wondering when the code would be put up on a public repo.
“Missing” prims – viewer-side fix possibly on the way?
So a viewer-side fix, along with viewer-side interest list updates, looks to be somewhere on the horizon.
Region Crossings
There have been a number of reports of region crossings worsening again after seeing a significant improvement with the release of the fix for BUG-1814. A common issue has been avatars becoming “snagged” at a region boundary while the vehicle they were travelling in continuing on its way, sometimes being returned to their Lost and Found folder from a location two or three regions beyond where the avatar became stuck. Both prim/sculpt and mesh vehicles are affected when the problem occurs, and it is an issue which had been encountered prior to the widespread deployment of the BUG-1814 fix.
Getting “snagged” at a region crossing while my aircraft flew on was a problem I encountered several times over Blake Sea early in April. The problem has again manifested itself to many, and I’ve again encountered it while flying my mesh Spitfire Mark IX
I’d actually encountered the problem on April 4th during a series of region crossing tests, but the problem no longer appeared to be occurring by the middle of the month.
The issue of region crossings was raised at the Simulator Meeting on Tuesday May 30th, but the discussion was dominated by the problems being encountered by one particular type of train. In commenting more generally on region crossings, Andrew Linden said, “I agree that region crossing on vehicles needs more work. I can’t promise that I’ll be working on that as soon as I’m done with this interest list project, but I’ll try to bring it up in the next ‘what do we work on next’ brainstorm that we have.”
Inara Pey: Living in a Modemworld 