SL Viewer Updates
Release and Beta Viewers
The release and beta version of the viewer are effectively on a par with one another at this point in time, following the roll-out of SL viewer 184.108.40.2060263 on February 14th. There is currently nothing “in” beta at the moment in terms of specific SL projects.
Development Viewer and CHUI
The development viewer and the development version of the CHUI (Communications Hub User Interface) project viewer are also pretty much on a par, and it is anticipated that the CHUI code will be merged-up to viewer development “any minute now”, to use LL’s parlance, although a date has not been indicated. The viewer development code branch is pretty much waiting for this to happen, and CHUI remains in pole position as far as LL’s code merge plans are concerned, so potentially there could be more news on this in week 9.
Work is progressing on Project Cocoa within LL. This is a rarely talked-about project to update LL’s Mac support to the Mac OSX Cocoa API specifically for OSX 10.8 support, and remove dependencies on old Mac APIs which are not well-supported any more. The overall goal of this project, as commented on by Widely Linden is to, “Get people building cleanly with 10.8,” although OSX 10.6 will continue to be supported, although it will no longer be possible to build a Mac viewer using 10.6 once this project has been deployed. Widely also commented that there is a project viewer and source code for this work, which interested parties “should snag.”.
Work is underway to update the SLvoice plugin to use the latest release of Vivox. This should bring with it a number of benefits including: security updates, stability improvements (although perhaps not improved connection reliability), better echo cancellation and – anecdotally, at least – better voice quality. There is no ETA on when this project will be deployed.
Linden Lab continue to work on utilising FMODex as a replacement for FMOD.
There has been significant progress in fixing the known outstanding issues on the project which are standing in the way of a public project viewer and viewer code appearing. Speaking at the TPV Developer meeting on Friday 22nd February, Oz Linden said, “Our list of things which must be fixed before we can hand it out to people is now down to one.” However, there is still no estimated date as to when a project viewer and source code will actually appear Real Soon NowTM, which appears to put them both closer than Pretty SoonTM and Real SoonTM on the LL scale of things :).
As has been reported in my server-side news for the week, the server code for materials is deployed to the whole of the main grid, and so the system will be usable as soon as project viewer surfaces.
What is likely to be the first in a number of Server-side Baking load / pile-on tests took place on Thursday February 21st. Results were, at best, mixed, for a variety of reasons.
The test was held in the Sunshine project test regions on Aditi, immediately following the Server Beta User Group meeting. Those participating were asked to use the latest iteration of the official project viewer, which had been set-up for LL to do a certain amount of data logging. Anyone encountering issues was asked to raise a JIRA under the SUN project, listing issues encountered, with the viewer session log attached.
the test was in two parts:
- Part one: performed on a region still running on a region using the current baking system, this saw people change between three of four outfits so that some baseline data could be obtained at the LL end of things. As this was using the current baking system, the usual baking issues were apparent
- Part two: performed on a region running the new baking service, this again saw people changing between a number of outfits, this time monitoring and reporting on their own experiences.
Results were, it is fair to say, mixed. They were also not helped by the fact that Aditi itself has significant issues with inventory, etc., which made the test considerably more complicated than perhaps needed to be the case (for example, people were getting “object failed to rez”-style messages and other errors as items could not be fetched from inventory, etc.).
As an overall load test on the service itself, this should have generated some interesting numbers for LL with at least 40 people participating in the test at its peak. Commenting on the test on Friday 22nd February, Nyx Linden said, “A big thank you to everyone who participated in the pile-on yesterday. We got a lot of data out of it, [and] it looks like the majority of the issues were inventory-related, and we’re going to be digging into those. Anecdotal evidence suggests that when the system worked, it worked pretty darn well; but there were some people who had more trouble than others … We are looking into the remaining issues; we’re going to be fixing them as quickly as possible.”
While Nyx indicated that the majority of problems were inventory-related, he also stated that he and his team were still digging into the data to see if the problems were purely related to the known issues with Aditi’s inventory handling, or whether some of the issues are apparent in the inventory system itself, either on the server-side of things or within the viewer itself.
Future Testing and Testing on the Main Grid
There are liable to be further tests in the future prior to SSB being deployed in any way to the main grid, and the Lab is already looking into ways of carrying out further tests on Aditi while avoiding some of the known inventory issues there – although how this might be achieved is far from clear. number of questions have been asked over the last couple of weeks as to why it is not possible to set-up two or three regions on the main (Agni) grid for SSB testing, particularly given issues around testing things like RLVa issues. Speaking at the TPV Developer meeting, Nyx answered these questions, “It’s not possible because there are some back-end things that we need to deploy first before we can do that; and once someone visits a server bake region, their appearance will be set as server bake, even when they leave that region. so for that reason, we really need people to have updated their viewers before we start doing main grid tests.”
Once SSB does reach a point where main grid deployment can commence, it is likely to be a progressive programme, with the code initially deployed to just a small subset of regions prior to being deployment to a Release Candidate channel and then most likely going to two RC channels prior to a full deployment to the grid as a whole.
Open Group Ban Lists
Those owning popular open enrollment groups will doubtless be familiar with the issue of spamming: a person (/bot) will sign-up to open groups and then spam them with adverts, links and so. Some will even join, spam, leave. Currently, the most common ways of dealing with these people is to either manually boot them from the group (if they don’t depart themselves), or to set-up a bot to monitor chat and take action against known offenders.
Both of these solutions are of limited value as they can only occur after someone has spammed the group in question. Furthermore, as the group is open enrollment, there is no way from preventing the individual from rejoining and resuming their activities after they’ve been ejected from the group.
The question has therefore been asked if the Lab to look into providing some form of ban list, potentially working in the same way as the estate ban system, which would allow group moderators to prevent offenders from rejoining a group once ejected from it and added to the list. Ideally, this would be a server-side mechanism (again like the estate ban function).
While the Lab is not currently working on such a capability, the response from both Oz and Widely Linden to hearing the request was broadly positive, with Widely commenting, “This is something we are very interested in,” before he continued, “I’m not saying anything more about this issue, but it is one I’ve been fascinated with for some time, and I am beside myself with joy in hearing it coming from you guys.”
Whether this means something may be forthcoming in the future, remains to be seen. However, as Jessica Lyon pointed out during the meeting, were LL to introduce something, it would be extremely popular among those managing openenrollment groups across the grid.
Suspected Interest List Issues
During the Server Beta meeting on Thursday 21st February several issues were raised which were being linked to the deployment of the interest list code across the grid this week. Whether these issues are widespread and / or are actually linked to the interest list code is unclear. They include:
- A report that the Area Search common to third-party viewers is “broken”, although in tests I carried out with Firestorm on regions running on the SLS, BlueSteel and LeTigre channels Area Search still functioned as expected
- Some reports of TPV client-side AO crashes. Again, I’ve failed to encounter any issues with my own client-side AO since the Thursday deployment
- Reports that particles from small objects are no longer rendered by the viewer if the emitter drops from / returns to the update list as the camera is moved arround
Again, there is no empirical proof these problems are caused by interest list changes, and it is not clear how widespread they may be. However, if you encounter similar problems, then TPV issues are best reported to your TPV developer and particle issues reported via the SL Bug Tracker.
Region Restart Notification Message
The week 8 deployments brought about a change to the notification pop-up displayed prior to a region restart. To highlight the difference between the old and new notifications, Maestro Linden provided an image of both at the Server Beta meeting, which I’ve reproduced on the right.
As can be seen in the image, the new style message is better highlighted and requires acknowledgement via the OK button, both of which should significantly increase the visibility of the notifications.