SL projects update 18 (4): servers, viewer release process, group bans and bits

Server Deployments – Week 18

As reported in the first part of this update, the SLS Main channel was rolled back to release, as a result of a widespread performance issue.  This unfortunately saw the removal of the new LSL animation capabilities from the channel.

The issue itself is related to problems with regions locating their neighbours. “The sim were hitting the [region presence lookup] service too hard, causing stability problems.” Maestro Linden said at the Server Beta meeting on Thursday May 2nd. Release notes.

In the original notes for this week’s deployments, BlueSteel and LeTigre were scheduled to receive the same deployment package. However, this was subsequently changed so that:

  • BlueSteel received the same reversions as the Main channel due to the performance issue between neighbouring regions, but also received updates for the Experience Keys project as originally planned. Release notes.
  • LeTigre received the same code that was on the main channel in week 17, the only difference being that it fixes the performance issue that caused the Main channel to be rolled back this week.  Release notes.

Maestro described the deployment of the fix for region lookup issues as the “conservative option”, rather than deploying the fix to multiple Release Channels, “In case the changes from the other two channels have their own problems.”

Magnum received the package originally scheduled for it, described as bringing some new minor features to LSL, and fixes some crash modes as well as the fix for grid performance issue, and fixing an issue in which llDialog() messages sent to the object owner could be incorrectly throttled. Release notes.

The hope is that if all is well with the Magnum update, it is liable to be deployed to the Main channel in week 19.

SL Viewer Updates

Beta Viewer Release

A new beta version of the viewer emerged on May 2nd, using the 3.5.2 code ( This release includes the update from FMOD to FMOD Ex, and well as a number of other maintenance and other fixes as specified in the release notes.  However, it does not include the anticipated Vivox updates to improve SL Voice. These will be coming along at a later date.

The current plan is for this release to remain in the beta channel for at least one further update prior to it appearing in the release channel. As such, it is unlikely to be in the release viewer until late in week 19 or in week 20. Once it has appeared in the release viewer, LL will probably deploy the new viewer release process, and the beta channel will cease being used.

Viewer Release Process

Oz Linden
Oz Linden

As previously reported, the viewer release process will be changing in the coming weeks. As a part of this, the development viewer channel has already been deprecated; however it will still be a while before the new process is put into place, as further infrastructure changes are still required on LL’s part.

Concerns have been raised by TPV developers about a side-effect of the new process potentially being that the rate at which code becomes available to them may slow down, thus causing them to “fall behind” the LL viewer in terms of new functionality or capabilities. Stressing that this is not the intent, Oz Linden described process in further detail at the TPV Developer meeting, indicating that under the new system:

  • Viewer projects will each have their own repositories, which will be made available to TPVs (and others) once it is deemed they are “safe to share” as a project or “beta” viewer
    • While it has yet to be formally decided within LL, and may take a little time to work up to, critical bug fixes are liable to have their own repositories, from where they can be merged into other viewers
  • Users will be able to pick which beta / project viewer(s) they download from the Alternate Viewer wiki page without being tied to any specific update route (so you can download and run as many project / beta viewers as you like)
  • Once a project is believed to be of release quality, it will be put into a release candidate, built on the current viewer release code and released to a target number of users (as chosen by LL), alongside other release candidates being used by other users
  • When a user receives a release candidate viewer via the download page, the updates they receive will be offered on the basis of the release candidate they are currently running (for example, if a user is running the Materials RC viewer, they won’t be offered updates from, say, the SSB/A RC viewer)
  • After some period of time, and when LL have looked at the results, one of the release candidates will be promoted to the default download (without the viewer having to be rebuilt) and will be available on the main download page
  • The remaining viewer projects (at least those at release candidate status) will then be merged with the newly-released viewer code, and re-test and issue a further release candidate, which may in turn be selected as the next candidate for promotion to the default download.

He added that in terms of TPV’s concerns over code being made available to them, the level of co-operation which has been evident in the Sunshine project (SSB/A) has “not gone unnoticed” within LL’s management, and that the team involved has received a lot of kudos for the way they have handled interaction with TPVs. As such, it is likely that the Lab will endeavour to build on this going forward.

FMOD Ex Packaging

In terms of FMOD Ex packaging, as reported in week 17, Drake Arconis (Sovereign Engineer) has contributed a public packaging mechanism for the required FMOD EX files (see OPEN-74). Commenting on this at the TPV Developer meeting on Friday May 3rd, Oz Linden indicated he is in the process of merging that with LL’s internal packaging mechanism so there will be just the one packaging process, which will be made available through a public repository for TPVs to adopt and use, which should both ease the process of getting FMOD EX into third-party viewers and make it consistent with the process used by LL.

Materials Processing

The viewer code still remains in an alpha status. While TPVs can start examining the code now, it is still not ready for integration into viewers intended for widespread release, and the code is very likely to undergo further changes. Given the current status, materials looks set to be one of the first projects to switch-over to the new viewer release process as that comes into effect.

Server-side Baking

There will be at least one more update to the viewer-side SSB/A code. A primary aim of this is to address some additional ways in which baking can fail and provide a more stable service. This will include some additional HTTP code and some new inventory code, although this code is not considered critical to preventing the server-side of the capability from starting to be switched on.

There is still no timescale as to when the server-side of SSB/A will be fully turned-on; again this comes down to the results obtained from whatever testing is underway / about to start now the SSB/A code is in the SL release viewer.


Monty has been engaged in looking into a series of connection / time-out issues which have started showing up. One of these has so far only occurred with one user, but has caused Monty to dig a little deeper into how things are being handled, and is considering, “Deeper and stronger and slower retries for things that are expected to succeed,” as the project moves forward. In the meantime, there is some more recent viewer code for the project which has yet to be merged by TPVs which may also help improve matters.

Some TPV developers have expressed concern that users may still be adversely affected by the ongoing HTTP work, combined with the addition of new dedicated HTTP-based services such as with SSB/A. Because of this, they’ve requested a list of “known better routers” from LL which can be published to help users to determine whether any connection issues they are encountering may be down to a need to update their router. It appears that such a list may be furnished, but how much depth it goes to is open to question – it simply is not possible for LL to test every individual router which is on the market.

Baker Linden: Group Bans and Bug Stomping

Baker Linden: stompin' dem bugs
Baker Linden: stompin’ dem bugs

Baker Linden continues to be a little side-tracked on the group ban project (JIRA VWR-29337), as he works to stomp a number of related bugs within the People API. Two of these relate to searching people using the choose resident floater. Another is an issue where in some cases you can’t unmute an object or person in your mute list.

Speaking after the Server Beta meeting on Thursday May 2nd, Baker also indicated another reason for the hold-up is that he’s been familiarising himself with the Django web framework which, he said,”We use for a lot of other user-related services. I’m adding group ban lists in there.” This doesn’t mean he’s developing a web-based service for group bans (or anything else); it’s just that Django is the framework LL use to build various capabilities.


3 thoughts on “SL projects update 18 (4): servers, viewer release process, group bans and bits

  1. >> This doesn’t mean he’s developing a web-based service for group bans (or anything else)
    I wish they did work on a web API for groups. I am working on a CMS for my community and it would be great if I could manage groups and send group notices through it.

    Another great improvement is if they added an option to extend a group ban to group land. We don’t have estate bans on Mainland and whenever we need to ban someone from our land we need to add the name to the ban list of dozen of parcels.

    Hmm… can we still suggest improvements through JIRA?


    1. There have been discussions around improvements to land bans and possibly hooking group & land banning more closely together in various ways, but none of it is currently in-scope for Baker’s work at the moment.

      One thing he has made clear, tho, is that he is open to ideas and feature requests, even if they end up being marked “for future reference”. So the way to do things is raise a JIRA (Bug Tracker) but clearly specify the fact that it is a FEATURE REQUEST in the report title & provide a concise explanation of what you’d like to see.

      You might find that the BUG request gets closed after initial triage – this doesn’t necessarily mean it’s being ignored, just that it has (hopefully) been recognised as a feature request and the details moved to the appropriate system / list, because the JIRA / Bug Tracker isn’t for handling feature requests (but the Lab currently has no other mechanism by which they can be submitted.

      The problem here is, of course, is because so much relating to JIRA is closed-off from public view, it’s hard to tell what is / is not being noted and recorded or marked for a future response – and this includes feature requests.


Comments are closed.