Server Deployments Week 19
Second Life Server (Main) Channel
On Tuesday May 7th, the Main channel should receive the maintenance package which has been running on Magnum. This project brings some new minor features to LSL, and fixes some crash modes and well as additional LSL HTTP support – release notes.
Release Candidate Channels
On Wednesday May 8th, all three Release Candidate channels (BlueSteel, LeTigre and Magnum) should receive server-side support for experience permissions which was running on BlueSteel in week 18. The update, as usual, will also include the changes which are going to the Main channel on May 7th – release notes (BlueSteel).
I was somewhat confused by the release notes for 13.05.04.275247 package, as on the one hand they suggested the new LSL AO capabilities would be absent from Agni following the RC deployments (“Changes since 13.04.19.274370 … Removed changes introduced by Second Life Server 13.04.12.273874”), while on the other, the line originally following this comment suggested otherwise.
I contacted Maestro for clarification, and he confirmed that the AO capabilities will be present on the RC channels following the deployment, and that the release notes have been revised to prevent any further confusion.
As always, there is a discussion thread in the forums for the deployments.
Server-Side Baking / Appearance
As noted in the last part of my week 18 report, there will be at least update to the viewer-side SSB/A code, which Nyx referred to at the Content Creation meeting on Monday May 6th as being, “Mostly reliability and some related polishing”. From the TPV Developer meeting on Friday May 3rd, the release will be addressing some additional ways in which baking can fail as well as addressing stability in general, although as Nyx noted at the TPV Developer meeting, “Nothing that we know of right now that would be mandatory for the system to work.”
The question of when constrained testing would commence again came up at the Content Creation meeting. This will see a number of regions across the main grid have the server code for SSB/A enabled in order for LL to carry out further load tests on the system ahead of the “switch being thrown” and SSB/A enabled across the entire grid. All Nyx would say on the matter is, “We don’t have a timeline to announce today.”
Whether this means there will be a formal announcement when testing does commence, remains to be seen. However, the Lab is still intending to make a formal announcement on SSB/A, mostly likely via a blog post, ahead of the service being enabled across the grid in the hope of further communicating the change, and the need to upgrade to an SSB/A-capable viewer to as many users as possible.
During her tests with SSB/A on Aditi, Kitty Barnett noted that when changing a wearable or reordering the layers of an outfit, the updated bakes could take a while to come through. Concern that this might be the case when SSB/A is enabled on the main grid prompted her to ask:
For server-side baking, would there be any issue with turning on local baking to make getting dressed more pleasant? it could be Aditi, but [when] wearing something it takes a very long time before the server bake comes through, particularly reordering clothing or taking something off … I actually just turn local baking on as soon as there’s a wearable change and it seems to be working nicely and turns itself off when the server bake comes through… but I was wondering if that would cause any undesirable issues [if the same was done on Agni]?
Local bakes already occur when using the Editing Appearance options, so Kitty’s question appears to be more broadly aimed at general outfit changes (people simply swapping individual clothing layers directly from inventory, and (possibly) using the capability in some TPVs to re-order clothing layers directly from inventory, rather than going via the appearance editor).
Responding to the question, Nyx said:
I’m not certain how you’re turning on local baking, and can’t really speak to whether there are undesirable behaviors as a result. The code to switch between the different types of bakes is rather complex and sometimes fragile, and bugs in that area can be subtle … Proceed with caution and best of luck :). Report back if it works well (or if you find interesting bugs!)
Whether such a delay will be noticeable enough to be an irritant on Agni is hard to say as we’ve yet to see the server code up and running on the main grid, so it’ll be interesting to see what further tests on Kitty’s part reveal as testing commences.
It is anticipated that there will be a further release of the project viewer “shortly”. The hope is that this will fix most of the rendering issues which have been reported. As I noted a few weeks back, the Lab’s approach has been to focus on the rendering side of things, the thinking being that if you can’t tell what the rendering code is doing, you cannot be certain whether or not an issue seen through the viewer is a rendering pipe issue or an actual viewer UI bug. So if LL’s QA do agree the rendering issues have been taken care of, the focus should shift to the UI side of things.
With regards to the latter, I asked Oz at the Open-source Dev meeting on Monday May 6th if anyone had been able to poke at MATBUG-16 (described here) and MATBUG-38 (described here and see image below), even with the focus on rendering within the Lab.
“Those two issues you asked about are being worked on,” Oz replied. “16 is almost certainly one of several issues we have open that are symptoms of some race conditions in the build UI. Fixing that is pretty much our top UI issue at this point. 38 I’m less sure of, but it’s probably relatively easy.”
There is a report that the OPEN-173 fix for issues of audio streaming stuttering has not entirely worked in the current SL beta viewer (220.127.116.115087), and issues are still being encountered when moving between parcels running different streams (the stream fading-in can often stutter, stop, and then pop back on at full volume). The issue appears to be most noticeable when moving to a parcel which is playing a stream with adverts. According to discussions, this might be the result of different sample rates used by the stream, or a possible stream starvation issue related to the default sizes of the stream buffers. A suggestion had been made to alter the latter to see if this improves matters, although initial feedback indicates this may make no difference, so investigations are continuing.