In short, there are no deployments scheduled for this week. The Main (SLS) channel will remain on release 17#17.01.27.323172.
While there had been an RC release planned, it apparently didn’t clear QA in time, so all three RC channels will remain on 17#17.01.27.323172 as well. However, all three channels will be restarted on Wednesday, February 15th, in keeping with the Lab’s policy or restarting channels every two weeks, whether or not there is an associated deployment.
The Maintenance RC viewer updated to version 126.96.36.1993567 on Tuesday, February 14th. As reviewed in this blog, this viewer includes a number of updates and new features, including the ability to select your own preferred folders for uploading image, animations, sounds and mesh models.
Outside of this update, the viewer pipelines remain as per the end of week #6:
Current Release version: 188.8.131.523027, dated January 25, promoted February 3 – formerly the Maintenance RC viewer.
Love Me Render RC viewer version Version 184.108.40.2063361, dated February 9th – rendering pipeline fixes and improvements
Project Alex Ivy (LXIV), 64-bit project viewer, version 220.127.116.111863 for Windows and Mac, released on January 10
360-degree snapshot viewer updated to version 18.104.22.1681712 on November 23, 2016 – ability to take 360-degree panoramic images – hands-on review.
Obsolete platform viewer version 22.214.171.1240847 dated May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.
Nvidia Driver 64-bit Viewer “Blue World” Bug
As I reported in week #4, Nvidia’s release of their 378.49 driver on January 24th resulted in many 64-bit viewer users (TPVs and the Lab’s own Alex Ivy 64-bit project viewer) seeing their Second Life world view turn decidedly blue when running with Advanced Lighting Model (ALM) disabled.
On February 14th, Nvidia release the 378.66 driver package, and this reportedly fixes the SL issues.
On Tuesday, January 24th, the Main (SLS) channel was updates with the same server maintenance package deployed to the RC channels during week #3. This includes a partial fix for (non-public) BUG-3286, “Can’t move object” fail notifications (fixes for regions/objects with longer names are pending), together with enhanced server logging and minor internal server enhancements.
There will be no RC deployment on Wednesday, January 25th – but the RC region will be restarted in keeping with the Lab’s new policy of restarting the channels every 2 weeks, regardless of whether or not there is an associated deployment.
The next RC deployment is expected to be week #5 (commencing Monday, 30th January, 2017).
No changes since my last update. The status of viewers in the pipeline remains thus:
Current Release version: 126.96.36.1991958, dated December 1st, promoted December 5th, 2016 – formerly the Project Bento RC viewer
Release channel cohorts:
Maintenance RC viewer, version 188.8.131.522791, dated January 12th
Project Alex Ivy (LXIV), 64-bit project viewer, version 184.108.40.2061863 for Windows and Mac, dated January 10th
360-degree snapshot viewer, version 220.127.116.111712, dated November 23, 2016 – ability to take 360-degree panoramic images – hands-on review
Obsolete platform viewer, version 18.104.22.1680847, dated May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.
As I noted in a recent TPVD meeting update, Jonathan Yap is working on a code contribution for the official viewer which will allow users to set and save their own preferred camera presets in the viewer.
The idea is that, like the graphics presets functionality Jonathan contributed to the viewer in 2016, users will be able to define their own placements for the SL camera around their avatar (e.g. an over-the-should view, a view from overhead, etc.), which can then be saved and selected / used as required. Jonathan has only recently started on the work – which has an associated feature JIRA, STORM-2145 – but that should hopefully change once various decisions have been made by the Lab.
Nvidia Driver 378.49 + 64-bit Viewer Bug
Nvidia release their 378.49 driver on Tuesday, January 24th, and it can cause an unusual bug / issue with 64-bit viewers. The problem was first noted on Firestorm 5.0.1 (see: FIRE-20774), but I have repro’d it on the Lab’s own 64-bit project viewer (version 22.214.171.1241863 at the time of writing) and on Alchemy 4.0.0 (a crash issue had prevented comprehensive testing on Alchemy 5.0.0 at the time of writing).
The issue only manifests when Advanced Lighting Model (ALM) is disabled in a 64-bit viewer, and renders the in-world view with an odd blue tinge which almost looks like the blue colour channel is impinging on the red channel. As noted in the Firestorm JIRA, enabling ALM can prevent the issues, as can toggling Glow off when ALM is disabled. See the Firestorm JIRA for workarounds, should you encounter the problem.
The issue was raised at the Simulator User Group meeting on Tuesday, January 24th, a JIRA for the issue on the Lab’s 64-bit project viewer is available on BUG-41294.
There are no planned deployments for the week. However, all servers on the three RC regions will be subject to a rolling restart. This is in accordance with the Lab’s new policy of restarting channels every fortnight, whether or not there is an associated deployment. As the Main (SLS) channel underwent a restart on Tuesday, January third, server on this channel were not restarted this week.
Project Alex Ivy
The 64-bit versions of the official viewer arrived in project viewer form on Tuesday, January 10th, under the code name Project Alex Ivy – which I take to be a reference to 64 (LXIV being 64 in Roman numerals, hence aLeX IVy).
The viewer, version 126.96.36.1991863, has been built using the newly updated and upgraded libraries and build process the Lab has been putting together, which will also be used for 32-bit Windows builds. Thus, the project viewer is available in three flavours:
There is no Linux viewer as yet, but the Lab has indicated it is their intention to provide one, although TPVs and open-source contributors are likely to still be asked to help with its ongoing support.
Additionally, the following points, as specified in the release notes, should be underlined (although please ensure you read the release notes in full if you intend to try this viewer:
The Mac build has several known limitations:
There is currently no Mac Havok build,so pathfinding paths cannot be visualised, and it may not be possible to upload mesh assets.
Video media using QuickTime does not play.
The 64-bit version will not run on Windows 10 systems with Intel HD 2000/3000 GPUs and may not run on other systems that do not have GPUs explicitly supporting Windows 10.
These shortfalls will be addressed as the viewer progresses through the project and release candidate phases to release status in the next weeks / months. Once released, it will signal the end of the 32-bit MAC version of the viewer (and possibly the 32-bit Linux version). The Windows version will continue to be available as a 32-bit build as well as having the new 64-build available.
Also, note that this viewer doesn’t include any functional updates / changes to the existing viewer.
Remaining Viewers Pipelines
Outside of the 64-bit project viewer, the various viewer pipelines remain as my last SL project update:
Current Release version: 188.8.131.521958, dated December 1st, promoted December 5th – formerly the Project Bento RC viewer
Maintenance RC viewer, version 184.108.40.2062513, dated December 21st – some 42 fixes and improvements + Bento support
360-degree snapshot project viewer, version 220.127.116.111712, dated November 23rd – ability to take 360-degree panoramic images – hands-on review
Obsolete platform viewer version 18.104.22.1680847, dated May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.
On Monday, January 9th, many users were hit with significant issues, with many finding themselves unable to log-in, or being disconnected from the simulators and unable to log back in. On Tuesday, January 10th, April Linden from the Ops team posted another of her excellent post-mortem blog posts on what happened, and I recommend it as a worthwhile and informative read.
In essence a failure within a third-party provider used by the Lab failed to trigger the expected automatic switch-over of connections for all users accessing Second Life through that provider. As a result, those users were disconnected from the service, and due to the volume of people trying to re-connect, couple (I assume with those simply trying to log in, unaware of problems) generated a backlog, forcing the Lab to bring additional log-in servers on-line.
Once again, April does an excellent job in explaining things – revealing more of the complexities of SL in the process (which, as I’ve oft said in the past, goes well beyond just the simulator servers), and also offers apologies for the Monday problems.
As always, please refer to the server deployment thread for the latest updates and information.
On Tuesday, December 13th, the Main (SLS) channel received the same server maintenance package, as deployed to the RC channels in week #49. This includes the following feature requests:
BUG-6377 – llGetObjectDetails(id,[OBJECT_ATTACHED_SLOTS_AVAILABLE]) – Returns a value that is number of attachment slots allowed by the server minus the number of attachments worn by avatar. Returns 0 if avatar is not in the same region or if UUID is not an agent.
BUG-40871 – llGetEnv() constant “region_object_bonus” – returns the object bonus set for a region.
On Wednesday, December 14th, all three RC channels should receive the same new server maintenance package, comprising improved internal server logging.
The Maintenance RC viewer updated to version 22.214.171.1242219, bringing it to parity with the current release viewer, incorporating the Bento updates. This leaves the remaining viewers in the pipelines unchanged from week #48:
360-degree snapshot viewer, version 126.96.36.1991712, dated November 23rd.
Obsolete platform viewer, version 188.8.131.520847, dated May 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7.
No Change Window
The Christmas and New Year 2016/17 No Change window comes into effect from Friday, December 16th. This means there will be no further server deployments and no further official viewer promotions after that date, through until Monday, January 2nd, 2017.
Mesh and Texture Rezzing
As noted in my week #49 update, people have been noticing increased delays in object mesh and texture rezzing, with fingers being pointed at the Lab’s CDN supplier(s). The issues are continuing for some, while for others they appear to have cleared up. It’s still not obvious if it is a potential LL / CDN issue or a network problem in general.
As Simon Linden said in the meeting, the problems have been seen by the Lab, but are proving to be intermittent and hard to pin down. The problem also seems to manifest differently for people: some report very slow texture rendering, other report textures load and render fine, but mesh items are prone to failing to fully render, others report a mix of the two.
Region crossings have been widely reported as increasing again – including avatars being dumped at 0,0,0 (again). Some are reporting the issue as cumulative: the more regions they cross, the greater the likelihood they’ll encounter a serious issue (becoming unseated, return of vehicle, forced log-out). The usual advice is being circulated – reduce script load, handle crossings with caution, etc. However, the Lab are again aware of the uptick, but have not come to any specific conclusion on the cause.
The avatar appearing at a region’s 0,0,0 co-ordinates appears to be linked to connection problems and / or UDP packet loss (usually the first packet) resulting in messages arriving in the wrong order and the viewer and simulator falling out of synch with one another.
With both the rendering issues and the region crossing issues, fingers have been directed at the increased land impact allowances. This may be a case of post hoc, ergo propter hoc. In particular, it has been claimed that region crossings “became” bad after the mainland LI allowance increase, although people were reporting issues before the LI increase took place.
Appearance Issues / Bake Fails
Some are finding their avatar is failing to render in their view (bake fail) when logging-in. Changing outfits, camming away / back to your avatar may fix this, or a re-log. In extreme cases reverting to the default Character Test avatars may be required, or deleting and recreating the affected avatar appearance folder on your hard drive.
Rider Linden is looking into the problem, and believes it may be due to a missed inventory fetch at log-in, leaving the viewer thinking you’re missing a critical part of your appearance (e.g. your shape), but he is not 100% certain at this point in time.
On Monday, November 28th, Linden Lab launched their new Grid Status update service.
Now delivered by a new service provider, it is designed to provide more detailed information on the overall status of the grid and Second Lifer services, whilst making it easier for the Lab to update the information presented through the pages.
While the new Grid Status pages are hosted by a different provider, existing grid status page and RSS links should redirect automatically.
Steven Linden first announced these changes would be coming during the TPV Developer meeting held on Friday, November 19th. The new page is more informative, with the most recent update / information displayed at the top, with drop-down sections displayed beneath it, with historical information displayed below these.
The drop-down sections can be used to display expanded information on the three main grid simulator channels; information on the various SL web-based services (secondlife.com, marketplace, wiki, community pages, JIRA, etc.); updates on major in-world services, (group chat, L$ transactions, rezzing, Voice services, teleporting, inventory, etc) as well as further information on various external services such as the log-in service and the chat / phone / Case support services.
As well as more information being available on the page, there is also an expanded set of subscriptions options to the service. These can be accessed via the orange button in the top right corner of the page, and they include the option to have Grid Status updates SMS’d directly to a mobile ‘phone. In addition, a separate option can be used to subscribe directly to a specific incident in progress via e-mail and / or SMS.
The new service also means the Lab’s Operations team can now update incident reports directly via a bot system, rather than relying on a manual update process involving different teams, as was the case in the past. This should help ensure the status information reflect updates and situations in a more timely manner.
With a faster means for staff to update information, more means by which users can access updates outside of visiting the Grid Status page itself (so often a bottleneck in the past), this new service should hopefully prove to be a lot more flexible, informative and accessible to SL users.
Note: at the time of writing, the Grid Status section on users’ secondlife.com dashboards was reporting “RSS Feed has no items”, suggest the RSS feed to the dashboard may have just to be updated. This has been reported to the Lab.
Update, November 30th: Cinder Roxley has updated the Radegast installer to work with the most recent SLVoice package. See her comments here and here (following this article). There is also a separate blog post on her work, for easier future linking.
It was recently discovered that the Radegast client was no longer installing the SLVoice extensions with a new / clean installation. On hearing of the problem, Beq Janus and Whirly Fizzle decided to investigate, and thanks to their work, we now two workaround solutions. As they had put the effort into sorting things out, I asked them if either would like to write about the issue and the solution, and Beq, with Whirly’s blessing, agreed to do so.
by Beq Janus
A few days ago when I was invited to reprise my role as a videographer for a special episode of Designing Worlds on the Future of Second Life, which will air in early December. The panel for the discussion included Gentle Heron of Virtual Ability Inc, the group who work to enable access to virtual worlds for those who, through disability or illness are unable to make ready use of regular viewers.
During the show, Gentle urged Linden Lab and us all to look for ways to make Virtual Worlds more accessible, remarking, somewhat fatefully, that many of her communities are limited to a single, troubled viewer, Radegast.
A subject of reviews in this blog, Radegast is a lightweight, extensible client which has been the ideal foundation for the disabled communities to build upon. It boasts an impressive set of speech to text and text to speech integrations and can be integrated with other devices such as braille screen readers. Sadly, Latif Kalifa, Radegast’s creator, passed away earlier this year and despite the code being open source, no-one has yet stepped forward to maintain it at a time when the Lab viewer is moving ahead in leaps and bounds, with the risk that non-maintained viewers and client might lose functionality.
As if to underline this, Gentle fell silent towards the end of the show, as she was dealing with a number of users who were reporting they were unable to use Voice with Radegast as it was failing to install the all important SLVoice extensions. While I am unfamiliar with Radegast, I offered to try looking into it for Gentle.
SLVoice is a pre-built binary package supplied by Vivox and distributed by Linden Lab. During the summer, it had been upgraded to address some security concerns and so it seemed likely to me that Gentle’s problem might be that the older SLVoice package had been deprecated and removed from the download server. Sure enough, a quick check on the package URL resulted in the dreaded 404 not found error. I sent an email to Oz and Patch Linden asking them to confirm whether older versions of SLVoice had been moved.
The next day Oz confirmed that all old SLVoice packages were still available and nothing had changed. Whirly Fizzle, the powerhouse behind Firestorm QA, leapt into action: she cracked open the installer and discovered the URL actually pointed to a separately hosted Voice package which was no longer available, causing the Voice installation to silently fail during a new or clean Radegast installation as a result. However, Whirly also found a working back-up archive we could perhaps use. Unfortunately, neither Whirly or I are C# coders and cannot update the installation package directly; so how could we get a Radegast installation to work with the back-up Voice package?
I hit on the idea of first installing the backup package that Whirly had discovered, and then running the standard Radegast installer. Success! So, for anyone who is performing a clean / new install of Radegast and needs Voice, I’ve produced a set of instructions – see the link below. There is, however, more.
I mentioned above that Linden Lab had updated the SLVoice packages over the summer to deal with security concerns. Because of this, older versions of SLVoice are to be blocked from connecting to the service, and Radegast would once again be without a Voice option. Knowing this, and never one to leave a job half done, Whirly successfully tested my approach using the most recent SLVoice package available from the Lab, and confirmed it will also work.
This means that providing that there is no internal dependency within Radegast on the legacy Voice package, we now have an upgrade path for Radegast users that will ensure continued voice support after the block on older SLVoice packages comes into force. To help ensure people know what they need to do, Whirly’s instructions can also be found in the link below.
These instructions are only a workaround. We still need to find a way to have Radegast install the correct Voice extensions automatically, as a part of the client install process. So, if you are a C# (C-Sharp) developer and are willing to spare a few hours looking at this, please take a look at the Radegast codebase and see if there is a way to incorporate the correct binaries into an installer package. Thank you.