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.
Update, November 28th: Dee Linden pinged me in-world to let me know the forest quest guns have now been updated with the revised script, and should work with all viewers.
On November 19th, I wrote about how recent changes in behaviour to llTakeControl meant that some users on TPVs such as Firestorm and Alchemy have found the guns used in the third of the Horizons Experience quests (Quest 3, the forest shoot-out with robots) may not work with their viewer.
At the time, the problem appeared to be due to behaviour changes made to llTakeControl as a result of SVC-7532. As these changes with this fix could “break” existing weapons in Second Life, it was not adopted by some TPVs, and so the Horizons Gun would not work with them.
However, following my article, Sue W left a comment indicating that Firestorm 4.7.9 allowed the gun to work (but not Firestorm 4.7.7 or 4.7.10). This, together with the problem as a whole, prompted further investigation on the issue by members of the Firestorm team, several of the LDPW Moles and staff from the Lab, using the Horizons staging regions.
These investigations revealed that the Horizons gun works with Firestorm 4.7.9 due to a partial fix for llTakeControl issues (quite separate to SVC-7532) which had been implemented with that release. However, as the fix had problems of its own, it was backed out for Firestorm 4.7.10 – hence why the horizons gun would not work with either 4.7.7 or 4.7.10 (except under very specific circumstances, as detailed in my previous article).
Further and extensive tests set-up by Quartz Mole, using both the Horizons Experience gun and the gun scripts used with Winter Wonderland (soon to officially reopen) revealed changes made to llTakeControl as a result of BUG-8265 were in fact responsible for the issues being experienced by some TPV users when trying to operate the Horizons gun. As a result, Quartz has re-worked the Horizons gun script, and testing shows it should now work with all viewers, and it will be deployed to the public gaming regions in the very near future.
This still leaves the issue of SVC-7532, which can still break the behaviour of older gun systems. To avoid this, Firestorm have indicated that with their upcoming release, they will introduce a toggle option, as Alchemy is doing. This will take the form of an option in Preferences which will allow users to switch between “old” and “new” llTakeControl behaviours in accordance with the weapons they are using.
With thanks to Whirly Fizzle for the update information, and Quartz Mole for extensively banging on things or the Horizons gun fix.
Update, November 24th: This issue now has a fix, please refer to my update article.
Note: this issue was discussed at the TPV Developer meeting on Friday, November 18th, together with wider issues around llTakeControl. You can follow he full conversation via the meeting video, between the 10:16 and 36:22 marks. In this report, I have attempted to focus solely on the Horizons Experience issue.
The TL;DR short form of what follows is that if you playing the Horizons Experience using a TPV, you may find the gun required for Quest 3 in the game – the forest shoot-out with robots – doesn’t work (Firestorm and Alchemy have the issue, for example). If so, you’ll need to switch to the official viewer to complete that Quest. When you have done so, you can then switch back to using your preferred viewer.
For those interested in the background, as in as small a nutshell as possible: the function llTakeControls has a long history of not behaving well. One of the issues was that it prevented interaction (left-click touch) with objects when in Mouselook, prompting SVC-7532 to be raised.
A fix for this problem was implemented in February 2016. However, while it fixed the left-click touch issue, it broke many weapons systems (see BUG-37693) as well as causing other problems (see BUG-11602). As TPVs tend to be a used a lot by people involved in SL combat environments, some – such as Firestorm and Alchemy – didn’t implement SVC-7532.
The Horizons Experience gun used in Quest 3, however, is designed to work with the SVC-7532 behaviour change, and so may not work for everyone using a viewer which does not have SVC-7532 implemented. Note the “may not” there. If you happen to be on a TPV viewer without SVC-7532, but are wearing an attachment already using llTakeControls when you enter the Horizons Experience, then the gun might work for you (this has been my own experience).
The problem now is what to do. Rolling back the behaviour change implemented in SVC-7532 is not seen as ideal, as it breaks expected functionality elsewhere. Similarly, any “blanket” implementation of SVC-7532 is going to completely break a lot of weapons systems, which the Lab would rather avoid. There’s also the fact that this is one issue among a number caused by llTakeControl (see BUG-8265 for other issues with it), so the Lab is going to have to spend time in further investigations to determine how they’ll handle things going forward.
At the moment, two possible short-term solutions for the “Horizons gun problem” were suggested at the TPV Developer meeting on Friday November 18th (video):
Re-scripting the Horizons gun / shooting system
Implementing some kind of toggle via the Advanced or Develop(er) menu so that users can switch between the two llTakeControl behaviours depending on the weapon system they are using.
At present, the Lab might be leaning towards the second option. However, and as noted, no decision has been made as yet.
In the meantime, if you encounter the “Horizons gun problem” when using a TPV, you’ll need to switch to the official viewer to complete Quest 3.
llGetObjectDetails() will have a new OBJECT_GROUP_TAG function (feature request BUG-20064) – when pointed at avatars it returns the group tag you see floating above them; and also OBJECT_TEMP_ATTACHED – to tell you if something is a temp attachment (feature request BUG-5195).
There have been no changes to the current batch of viewers in the various pipelines since the end of week #44, leaving things as follows:
Current Release version: 184.108.40.2060331 (dated October 4th), promoted October 10th – formerly the VLC media plug-in for Windows RC
Release channel cohorts:
Project Bento RC (avatar skeleton extensions), version 220.127.116.111250, dated November 2nd – bug fixes
Maintenance RC viewer version 18.104.22.1681183, dated October 28th – over 70 crash fixes, improvements and other fixes
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.
Avatar Attachments Being Unexpectedly Detached
This has been an issue for a while, but has recently seen an uptick in occurrences. IN essence, and for some reason, when undertaking at TP or physical region crossing (both amount to the same thing), a “kill object” (attachment) message can be sent by the simulator.
Essentially, there is an issue in messaging between the simulator and the viewer during region crossings (physical or teleports), which can result in attachments being detached or, harder to detect, attachments being removed server-side, but remaining visible (but effectively ghosted) in your view, and which cannot be individually removed, as the simulator doesn’t recognise them as being there.
Whirly Fizzle has posted on possible fixes for the issue, including details of an experimental fix from the Firestorm team which might be included in the next release, pending Linden Lab addressing the root cause of the problems
One of the most common occurrences for the problem is having multiple items on a single attachment point (rigged meshes can often all default to the right hand, for example). So, should this problem occur, and once you’ve corrected matters (such as be a forced rebake (CTRL-SHIFT-R) or a complete change of outfit, for example), check the items affected by the problem, and if they do share an attachment point with one another or other attachments your avatar is wearing, trying relocating them to unoccupied points (this should be particularly easy to do with rigged mesh, which can be attached pretty much anywhere and render at the correct point on your body.
In September I blogged about the OpenGL issue affecting many Windows 10 users, including some using Second Life. An intermittent problem, not encountered by every Windows 10 user, the issue results in exceptionally low FPS rates (on the order of 1 or 2 fps) when experienced.
The root cause appears to be the Cumulative Update for Windows 10 (KB3176938) released at the end of August 2016, intended to fix a lot of issues encountered with the Windows 10 Anniversary update, However, since its release on August 31st, 2016, KB3176938 has given rise to renewed Windows 10 / OpenGL issues which have been impacting a number of games – and also affecting Second Life.
However, it now appears as if the problem has been resolved. As indicated by reader Lee McKay, both Nvidia and AMD have released new drivers which should address the problems Windows 10 users have been experiencing as a result of this issue.
As I’m not a win 10 user, I cannot verify if these drivers (or at least the Nvidia driver, as I’m a GTX 970 user) do fix the problems, but Lee indicates they have been tested and verified as correcting the problems.
So, if you are a Windows 10 user with an AMD or Nvidia GPU, and you’ve been experiencing fps issues of late, you might want to try downloading the relevant driver and giving it a try.
With thanks to Lee McKay for the updates on this situation.