Update: The Interest list release to Magnum has been postponed due to a last-minute bug being found. Magnum has instead received the same code as deployed to Bluesteel and LeTigre, containing the threaded region crossing update.
Server Deployments for Week 2
Server deployment recommenced this week, with a main channel roll-out on Tuesday 8th January, which saw that channel get the same code as released to the RC channels just before the Christmas / New Year break and as reported here.
Wednesday January 9th will see two major deployments to the RC channels. LeTigre and BlueSteel should be receiving a package which includes threaded region crossing code while Magnum gets Andrew Linden’s work on Interest Lists.
The threaded region crossing code should help improve simulator performance when avatars are region crossing to and from a region. However, and as previously noted, while the code did give clear improvements when crossing between regions on foot, the results were less positive when using vehicles during a recent test. Whether this has been improved as a result of those tests remains to be seen.
Interest List Deployment
The Interest List work should reduce the bandwidth usage of viewers due to object updates, and should improve simulator performance, especially in sims with many connected avatars and which is busy in terms of object updates.
This is the first phase of work planned around interest lists and object caching as a part of the Shining project. Andrew’s work has primarily been focused on improving the manner in which object updates are handled, etc., in order to provide improved performance. However, even with this initial phase of the work, there should be some improvements in the actual order in which objects appear in world (those closer to your camera position appearing prior to items further away – although there is far more work to be done in this regards before the project is finished.
As it stands, there are already some updates to the work in the offing, as Andrew indicated at the Simulator User Group meeting on the 8th January, saying, “I’ve got some interest list work that didn’t quite make it into the Magnum RC … this work is almost ready for testing, so I’ll be trying to get it into a maintenance branch or something for a follow-up release.”
The new interest list code will see the final removal of the “legacy cloud” layer (at around the 170-200m mark). While this has been disabled viewer-side since around the introduction of Viewer 2, the data relating to the legacy cloud layer has still been sent out by the servers, allowing viewers which still incorporate the necessary code to render the clouds in-world. However, the server-side code relating to legacy clouds has been removed from the interest list code, so viewers will no longer be able to render the clouds.
The Magnum release notes are available here.
Teleport Elevation Issues
There have been some unusual effects in teleporting via the world map which the destination location does not have a set landing point.
The issue seems to be caused by the map now defaulting to an elevation of 2m when a region name is typed into the FIND box and then the teleport button is clicked. The result is that avatars are arbitrarily delivered to the 2m level for a couple of seconds prior to “popping-up” at ground level, or if the elevation of their point of departure (the place from which they are teleporting) is higher than that of their destination, they tend to arrive at that elevation prior to falling to ground level.
For example, when teleporting via the map from my Linden Home (elevation 43m) to a region where the elevation is closer to the more usual default of 21/22m, I invariably arrive flapping my arms and legs in mid-air. However, if I use the map to teleport to a region at more-or-less the same average elevation of the one I’m leaving, I’ll generally arrive underground prior to “popping up”.
Andrew Linden has seen this issue, but assumed it to be a part of his interest list work. It appears at least one JIRA is / has been raised on the issue to ensure LL are more aware of the problem.
Most people have experienced times when they have had to toggle the media player on / off in order to get the music URL to correctly update even though the updated information has been received by the viewer. Typical examples of this are teleporting to a region when already playing media, and the previous parcel stream keeps playing or when a live event features a change of artist (and thus a change of stream URL).
However, there can be times when the URL update isn’t received (a packet loss, for example, can prevent an update being received), and thus the stream fails to update. When this occurs, toggling the media play button will not work, as the viewer did not receive any information relating to the new stream URL, and the user has no other option than to teleport away and back or log off/on, in order the get the viewer to send the required parcel information request in order to receive the required data (including the current music stream URL). It might be possible to improve this situation through changes to the viewer code, and some poking around to see what might be done may be undertaken by a non-Linden code contributor.
Tuesday January 8th saw major network issues affect the majority of LL’s services, including Second Life itself. Issues initially starter being reported on the Main Release Channel, prompting some speculation that the problem was related to the code deployment to that channel earlier in the day. However, reports were also received on identical problems on the RC channels as well.
The problems initially manifested it the form of high lag (both in-world and through items such as open chat), rezzing issues etc. During the Simulator User Group meeting on Tuesday 8th, attendees all experienced high packet losses – some of them almost cyclical (packet losses would spike in a sharp burst every few seconds before dropping down once more before repeating).
Kelly Linden confirmed the issues was network related and that the Ops team were investigating. Shortly thereafter a grid status report was posted on the issue, which was later updated to reflect the fact that the issues were widespread across LL’s services including the grid, my.secondlife.com and the SL Marketplace.
Whether the issues related to the web services and those being experienced on the grid were down to the same network problem or not is currently unclear, as is the nature of the issue itself. As it stands, the “all clear” was given at 17:00 PST on the 8th January. Further information may become available at the Beta Server meeting on Thursday 10th January.