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: June 16th, 2013
SL Viewer updates:
Materials Processing beta updated to version 3.6.0.277285 on June 12th and then to 3.6.0.277409 on June 14th (release notes)
A Beta Maintenance viewer, version 3.5.4.276827 was release on June 14th – core updates: lots of fixes and improvements (incl. updates to the ongoing ultra-high resolution snapshot issues, mesh improvements, etc.) – release notes
Catznip released version R8 on June 8th (missed from last week’s summary as a result of a website redirector error) – core updates: SSB/A and pathfinding – release notes
Littlesight Android client updated to version 1.4.0.1 on June 12th, no release notes
Lumiya updated to version 2.4.6 and then 2.4.7 on June 12th – core updates: general bug fixes; support for multiple attachments and clothing layers; in-world hovertext display; search places; updates SSB/A support; improved support for emotes in chat – release notes
Mobile Grid Client updated to 1.20.1185 on June 10th (and slipped into the week 23 report as a result) – release notes
Pocket Metaverse updated to 1.8.1 on June 10 (and slipped into the week 23 report as a result) – release notes
Depreciated / Discontinued Viewers
SL Development viewer – depreciated as of version 3.5.2.274629 April 24, 2013
Zen Viewer – discontinued by developer and no longer available, January 27th, 2013
Phoenix viewer – development and support ended on December 31st, 2012
SUN-74 – Asset Corruptions With Non-SSB/A-enabled Viewers
I’ve recently reported on the issue of BUG-74 in relation to server-side baking / appearance. This affects some non-maintained viewers which do not have SSB/A support and which might result in some worn modify assets (skin, hairbase and eyes) being corrupted – see here for details. The issue was finally repro’d successfully by the Lab in week 23. Since then, investigations have been ongoing.
Commenting on the situation during the TPV Developer meeting on Friday 14th June, Nyx Linden said, “we have a technical solution for SUN-74. I have tested it against 1.23[.5], and the old behaviour is no longer reproducing. So hopefully that will mean that once we get it in a place where we can test against Phoenix there should be no more asset corruption.”
Nyx Linden (stock)
It’s not clear when this will happen, but it seems likely the updates will be deployed to the “closed beta” regions where TPV testing of the SSB/A code has been ongoing for the last couple of weeks, and tests will be taken there to ensure non-SSB/A viewers will not be negatively impacted when moving between SSB/A-enabled and non-SSB/A regions during the initial deployment of Server-side Baking / Appearance.
However, this does notmean that people on older, non-maintained viewers no longer need to update to an SSA/B-compatible viewer.
Regardless of the fix for SUN-74. people on non-maintained viewers will start to see increasing numbers of grey avatars around them as SSB/A is rolled out, and willfind that others see them as a permanent cloud. So the only way to be sure of being ready for the deployment of SSB/A is – update or upgrade your viewer if you have not already done so.
Additional Viewer Patch
A side effect of the work carried out on this issue is that the Lab will also be producing a small viewer-side patch which is not any kind of “bug fix” for SUN-74, but which will help viewers get their own appearance messages “just a little bit faster” than is currently the case.
While TPVs are encouraged to incorporate the patch once it becomes available, it is not seen as a mandatory requirement ahead of SSB/A being enabled on the main grid. As such, TPVs have been encouraged to integrate the patch once it becomes available and as it best fits their own release schedules.
Grid-wide Deployment
When asked about how the Lab plans to deploy SSB/A server-side at the TPV Developer meeting on Friday June 14th, Nyx replied:
Carefully. Definitely carefully. We are doing a lot of testing, and as most of you know, we’re doing an Agni pile-on [see later in this report] … and we have been doing a lot of load testing and we’re pretty confident we have enough hardware on the back-end to handle the load.
[So] We’re going to start with a small group [of regions] and go to an RC channel, and then more, and then take over the entire grid.
Whether “go to an RC channel” means enabling SSB/A across an entire RC channel (Magnum, BlueSteel or LeTigre) or enabling across a portion of regions on the selected RC channel is currently unclear. That decision doesn’t rest with Nyx, but will be dependent upon on number of factors including how well the initial steps in the deployment go.
In light of things like the pile-on test (see the next section) and readying the SUN-74 patch, the Lab remains unwilling to commit to specifying a date by which SSB/A deployment might be expected to start. This is understandable as there is still no guarantee that further issues such as SUN-74 won’t be uncovered as a result of either the pile-on test or as a result of further closed beta testing, which the Lab continues to monitor.
Main Grid Pile-on Test
On Friday 14th February pile-on test was conducted across a number of regions which had been specifically set-up to stress test Server-side Baking with some “real world” avatar numbers. Some fifty or so people turned up for the tests using various viewers with Appearance debugging enabled, including a version of the official viewer which had been pre-set with debugging enabled. The test was in three parts:
Baseline testing on regions using the current avatar baking mechanism
Testing on regions in the Snack RC channel running a version of the SSB/A code
Testing in the “closed beta” region specifically set-up for TPV testing running the SSB/A code
The precise differences between the code on the Snack regions and the code on the TPV test region (the Testylvania Sandbox). Questions were asked in open chat, but the nearest answer which seemed to be given was that the Testylvania region was the one the Lab “cared about the most”.
Testing on the current baking mechanism saw familiar issues of slow clothing / skin rendering and the need to use manual rebakes to try to encourage non-blurred appearances. Things appeared to be a lot better on the SSB/A-enabled regions (I personally experienced no issues in changing skins / clothing layers and found rendering of both fast and error-free, for example). However, some did report issues with rendering, and filed JIRAs / provided log files as a result.
There were multiple reports of attachment rezzing failures as of the asset service coming under pressure as a result of so many outfit / look changes going on simultaneously and in rapid succession. Whether these will see further work undertkaen on the inventory system (some work has already been carried out in a wider context by the Sunshine team), remains to be seen.
Expect more on the tests once LL have had time to chew on the data gathered and review the logs of those who did encounter issues.
Catznip slipped out R8 on June 11th. I actually missed it, as it appears the redirector to their wiki page was still pointing to the old blog, so when checking I was still seeing R7 as the last release; so I was a little surprised to check the link this evening and end-up at the Catnip wiki and see Catznip R8 sitting there and purring at me!
Anyway, the important thing is the release is here and sees Catznip join the ranks of Server-side / Appearance ready SL viewers, gain pathfinding functionality and become the latest viewer to offer full Havok support, as a part of the Lab’s Havok sub-licensing arrangement. As well as these two major updates, R8 gets a number of improvements and bug fixes.
Server-side Baking / Appearance
Not actually a lot to say here, other than “it works”!
Catznip R8: SSB/A ready: (l) my Alt (at the back), running the SL SSB/A-ready viewer, renders correctly in Catznip R8, while (r) I render correctly in the SL SSB/A-ready viewer
When tested on an SSB/A enabled region, Catznip R8 rendered my Crash Test Alt (running on the official SL viewer, which is SSB/A ready) and my avatar correctly, as did the official SL viewer. No grey ghosts or clouds with either.
Pathfinding and Havok Sub-licensing
A major element missing for the last Catznip release – R7 – was pathfinding support. This wasn’t because the Catznip team have anything against pathfinding; they simply found time working against them, as I noted in my R7 review:
Catznip R7 does not include any pathfinding tools, as the team had enough on their hands getting all the updates, changes and fixes already planned for this release merged, tested and made ready for release. This doesn’t mean pathfinding is being ignored, however. Expect to see it in a future release.
R8 rectifies this. Not only does it provide the expected Linksets and Characters options, Catznip R8 becomes the latest SL viewer to sign-up to the Havok sub-licence agreement, meaning it also gains the ability to visualise the navmesh when working with pathfinding.
Pathfinding arrives in Catznip with the release of R8, and the Havok sub-license agreement means that the release includes navmesh visualisation
A further benefit with the agreement is that Catznip can also use the official Havok-powered mesh uploader.
Further Updates
In addition, Catznip sees the following added / updated:
Addition of a “Per user” option to the “Show friends permissions” in the friends gear menu to always show non-default permissions
Addition of an Edit Hover button functionality to show the shape editor, scrolled down to the “Hover” wearable param
Addition of a further toolbar at the top of the world view
Addition of a Close All Folders button to the inventory outfits view toolbar
Addition of alignment options to toolbar buttons. Those at the bottom of the screen can be centred or left or right aligned, while those to the side can be aligned to the top or bottom of the screen as well as in the centre.
Catznip R8 adds left/right alignment to bottom toolbar buttons and Top/bottom alignment to side toolbar buttons
changed : highlight the currently worn outfit folder in bold
changed : rearrange the avatar inspector to add extra lines to the profile description
one extra line added by default through layout changes
two extra lines are added by expanding the textbox to fill the volume slider space if voice is disabled
changed : report more useful information about memory state in case of a crash
changed : allow multiple crashes to be selected in the “Crash reporting” preferences panel.
There are also a number of bug fixes which have been implemented by the Catznip team and / as a result of fixes coming out of the Lab; there are also a number of updates to RLV/a. For details on all of these, please refer to the R8 release notes.
Feedback
This isn’t a huge update compared to others, but it marks a significant step forward for Catznip both with the Havok su-licence support and, most importantly, the SSB/A support. I also have to admit I like the button alignment options (something we’re unlikely to see in the official viewer, but which is so very handy in making screen space more usable.
Given this release is to ready Catznip for the grid-wide deployment of Server-side Baking / Appearance, it is strongly recommended that if you are a Catznip user and have not updated, that you do so ASAP.
Performance-wise, Catznip R8 on my PC offers around the same performance as most viewer releases over the past few months. Running with Advanced Lighting Model off while in my home region with around four other avatars, FPS varies from the high 20 through the high 40s, depending on my altitude. When running with Advanced Lighting Model enabled but no shadows enabled, rates tend to range from the low teens through to high teens / low 20s.
As always, please refer to the week’s forum deployment thread for news, updates and feedback.
Second Life Server (Main) Channel
On Tuesday June 11th, the SLS channel received getting the server maintenance project that was on BlueSteel and LeTigre in week 23, and which is intended to fix a simulator crash mode, and a disconnection issue whereby multiple avatars would be disconnected from a simulator simultaneously, giving the impression the region had crashed when it had in fact not done so, and which also impacted LSL HTTP-in URLs.
Based on data since the deployment, it appears the disconnection issue has been addressed, although there was a report that problems of LSL HTTP-in URLs being dropped, Commenting on this issues at the Server Beta meeting on Thursday 13th June, Maestro Linden said, “I managed to confirm that it was a separate problem [to the avatar disconnection problem] Kelly has looked into it, and we think we’ll have a fix for that soon.”
Kelly Linden added, “I’ve been working on some http-in bugs for the last couple of days. I have some fixes but I can’t guarantee they will be 100% effective. There is more Rube Goldberg in that system than I’d like.”
Magnum Release Candidate Channel
On Wednesday June 12th Magnum received an update to the current interest list changes running on that channel, which addresses two bugs introduced by the project. The bug fixes were for the problem of the text of large scripts failing to display in the script editor for people on lower bandwidth connections, and a fix for the simulator spamming the viewer with AvatarAppearance messages when avatars were in view and were moving around, also resulting in bandwidth issues.
There have also been reports of an “invisible avatar” problem occurring on Magnum regions since the week 22 deployments. which take the form of avatars in the local vicinity de-rezzing following an in-region teleport, and will only re-appear following a relog. The issue was reported as still be present in week 23, and again following this week’s deployment. So far, the Lab has been unable to reproduce in-house, so investigations are proving difficult. As BlueSteel and LeTigre are now also on the same release (see below) the Lab will be watching to see if there are additional reports of this issue.
BlueSteel and LeTigre Release Candidate Channels
Maestro Linden likes to work-out during meetings
On Wednesday June 12th BlueSteel and LeTigre initially received a new server maintenance project to fix a number of crash modes, addresses an issue with neighbouring region visibility, and which added new adds new LSL pathfinding capabilities and object return capabilities.
However, soon after deployment, an issue was found on BlueSteel / LeTigre regions – Bug 2850 (Cannot rez objects in Bluesteel and LeTigre parcels which disallow object entry), which resulted in a rollback which saw BlueSteel and LeTigre updated with the Magnum release package.
“it turned out that if a parcel allowed build but disallowed object entry for your avatar, then your avatar would not be able to rez from agent inventory into the parcel,” Maestro explained at the Server Beta meeting on Thursday June 13th, “And your scripted objects (like the pop-gun) would also be unable to rez. Also, Lucia [Nightfire] reported a tangential issue, which was that rezzing in some group-owned parcels required your avatar to have the parcel’s group active, which is not usually a requirement. These bugs were bad enough that … we rolled BS and LT to the same version as Magnum.”
Fixes are underway for this issue, but it is currently not known if they will be ready for next week’s deployments.
Object Return Capabilities Update
Prior to the rollback on BlueSteel and LeTigre, an issue was noted with the llReturnObjectsByID function, resulting in the function being disabled server-side. “It should be (probably) re-enabled with the next release of that code,” Kelly Linden noted. “However it will have a new limitation – it will no longer be able to return objects owned by the parcel owner.”
“We were concerned about a potential griefing vector if a parcel owner absent-mindedly grants the permission,” Maestro added.
I’ve updated my overview of the new capabilities to reflect this change.
Lumiya, the mobile client for Android devices saw two rapid-fire updates on June 11th. First came version 2.4.6, offering a lot of new and improved functionality, which was followed by 2.4.7 with a round of bug fixes which demonstrated again that no matter how hard you try to stomp on the little sods before a release, some of them will still be there to blow raspberries at you after a release…
Given the rapid-fire nature of the updates, I’ll be reviewing them all under the banner of the 2.4.7 release.
The Fixes
The under-the-hood fixes to Lumiya with this release comprise:
Minor inconsistencies with avatar shape rendering correctly
Fixed terrain rendering in regions with default terrain textures
Fixed a crash on clearing cache while connected
Updates for server-side baking compatibility.
Multi-wear / Multi-attach
Lumiya now supports multi-wear for clothing at attachments.This is enabled via an ADD option appearing in the pop-up menu when selecting items from inventory or outfits to be worn / attached.
Currently, the order in which items on the same clothing layer are displayed is a little random (so if you wear shirt layer item 1 first and then shirt layer item 2, the second item might appear to be worn over the first, but the next time you add them in the same order, the second might appear to be worn under the first). There is also no ability to re-order items once worn, as is possible with a viewer.
At the moment, system clothing in Lumiya all utilises the same icon in inventory & outfits (a shirt icon), regardless of the layer on which it is worn. Alina does plan to improve this in time, however her attention is on other functionality right now.
Lumiya 2.4.7: (L) – The new ADD option for multi-wear, allowing additional clothing items to be worn on an occupied layer / attachments to be worn on an occupied point, a-la most viewers, and accessible from both inventory and outfits; (c) – the new Places search option, which can be selected from within Search; (r) – the three options available from within Lumiya’s settings for displaying hover text in-world
Search Places
Lumiya’s Search option has been expanded to incorporate places and well as people. You can toggle between the two on entering search (e.g. by selecting it from the menu displayed when tapping the Menu button on your device) by tapping on the displayed option (People is the default) and selecting the required option from the drop-down.
Emotes and Hover Text
Lumiya now supports emotes in chat (e.g. /me smiles) and will also now display hover text above objects. By default, this is only on for hover text associated with worn HUDs. This is to prevent smaller screens being over-run with lots of on-screen hover text (because you’re roaming through a breedables store, for example). However, it can be enabled for in-world objects (or disabled altogether) by tapping the Menu button on your device and then going to Settings and scrolling down to 3D View and tapping Display floating text. This will display a pop-up menu with three options: On all objects, Only on HUDs, and Do not display – tap the radio button for the desired option.
Feedback
All told, another nice little package of updates to Lumiya which again further increase its capabilities and which enhance it as a worthwhile alternative to a full-blown viewer for those who need to access SL while on the go and away from their computers. All of the additional functions are nice-to-haves, and the server-side baking / appearance updates ensure that Lumiya remains SSB/A-ready, once the latter starts to go live across the grid. There is something of a delay in changing / updating outfits as a result of SSB/A, so if you do try Lumiya for the first time, please bear this in mind and remember the app is doing an incredible amount of work in order to bring you both a mobile client and a functional in-world, real-time view of the world.
Update June 12th, 22:40 BST/14:40 SLT: The BlueSteel / LeTigre deployment which includes these capabilities has been rolled back due to an issue whereby objects cannot be rezzed in BlueSteel / LeTigre parcels which disallow object entry (even if Create Objects is enabled) – BUG-2850. Both regions are now running the week 24 Magnum deployment.
In week 23, Kelly Linden announced new LSL capabilities for the scripted return of objects within a region / parcel. In making the announcement, he indicated the capabilities would be available “some time in the future”, a comment which appears to have been a little overly cautious, as the new functionality received its first outing on the Main channel in the RC deployments to BlueSteel and Le Tigre on Wednesday June 12th.
The new object return functions are llReturnObjectsByOwner and llReturnObjectsByID, and are designed to be used to enable the automated return of specified linksets to their owners.
The object containing scripts using the functions can either be placed in the land, or worn as an attachment but will only work on land held by the object owner.
The primary aim of these functions is to make for easier clearing of private sandboxes and rental parcels in cases where previous users / tenants may have left objects behind on leaving (thus removing the onus on the land owner to locate and manually return items). They are not intended as anti-griefing tools, nor are they a “replacement” for the parcel / region auto-return functions.
The Functions
The functions are defined within the BlueSteel and LeTigre release notes as follows:
OBJECT_RETURN_PARCEL to return all objects on the same parcel as the script which are owned by ‘owner’. The script must be owned by an estate manager or over a parcel owned by the owner of the script.
OBJECT_RETURN_PARCEL_OWNER to return all objects owned by ‘owner’ which are over parcels owned by the owner of the script.
OBJECT_RETURN_REGION to return all objects in the region owned by ‘owner’ – only works when the script is owned by the estate owner or an estate manager.
Parcel owner, estate owner and estate managers can not have their objects returned by this method.
Objects which are owned by the group the land is set to will not be returned by this method.
Throttled at max parcel land impact region-wide per hour.
Returns the number of objects that were returned to their owners or an error code.
Additional Notes and Q&A On Capabilities / Limitations
There are also some additional notes which go with the new functions:
There are no cases where one of these new LSL calls would return an object that you could not manually return yourself
The functions will only work on objects in the same region/parcel as the object containing the script using them. Objects which are returned are coalesced in the recipient’s inventory, rather than being returned as individual objects
The functions work if and only if the user would have permission to return the object via the viewer, and it does not handle encroachment
To prevent severely damaging accidents the mass returns by owner (llReturnObjectsByOwner) will not work for your own items, items owned by an estate owner or manager or items that are owned by the group the land is ‘set’ to
llReturnObjectsByID will not return objects owned by the parcel owner
In order to work on group-owned land the object containing the script using the functions must be deeded to the group by the group owner
The return capabilities are throttled to a maximum hourly quota based on a parcel’s Land Capacity (under About Land > Object). So, if your Land Capacity is 500, then using these LSL functions you can return up to 500 linksets per hour
The throttle is there primarily to prevent a silent war between a rezzer and returner that could impact the back-end servers
Even with the throttling, it is anticipated that the functions should be able to return everything on your land within a region in one go, but not necessarily more than once an hour for large-scale returns.
Inara Pey: Living in a Modemworld 