Update August 27th: In reference to the “z-offset” notes at the end of this report. Marine Kelley has issued an important fix for her implementation of the capability for the Restrained Love Viewer (184.108.40.206). If you’re already using 220.127.116.11 as originally referenced in this article, you’ll need to update. I’ve revised the piece to point to 18.104.22.168′s release notes (download will also go to 22.214.171.124).
Week 34 saw Server-side Appearance go grid-wide in Second Life. Overall, the deployment went smoothly for the majority of people, although some have encountered issues, of which more below.
Commenting on the deployment in general terms, Nyx Linden said:
The roll-out this week went really well and seems to be performing well. We definitely have enough ovens to do the baking with, and there have only been a handful of users with issues, as far as I’m aware currently.
Where problems have occurred, there appear to be a mix of known issues and issues which appear to be related to the user’s connectivity between their viewer and the SL servers.
Nyx reports that the Lab has been analysing the issue, and as a result has a list of accounts likely to be affected by it. They are currently putting in place a system by which these accounts will be flagged and automatically fixed when they next log-in. If all goes well, this new system should be coming into play in week 35, or at least in the not-too-distant future.
The Lab is reasonably confident that this work will eliminate the SUN-99 issue; however, Nyx has requested that if people continue to see multiple instances of their Current Outfit Folder appearing, to please raise a JIRA, including the viewer (and version) being used, so that it can be investigated for other possible causes.
Nyx also indicated that there has been one report of a user who was able to move their duplicate COF folders to their trash and then flush them, although this shouldn’t be possible. So if you do encounter the problem, it might be worth a try.
Until the new automated fix solution is implemented, instructions have been passed to LL’s support team, and they generally will try to provide a manual fix when contacted, and will do so for both Premium and Basic members. It has been suggested that the best way to gain support’s assistance is to file a ticket under Account Issues and then clearly marking it as being a BUG-99 / Current Outfit Folder problem.
High Bandwidth and Draw Distance
Issues relating to a poor connection between the viewer and the SL servers are resulting in people having either fully grey avatars or one of the three skin layers (head, upper body, lower body) remaining grey. The Firestorm support team in particular have had reports on this. Commenting on it at the TPV Developer meeting, Lead Support for Firestorm, Ed Merryman, said:
For the most part, in my personal experience, it’s been people with bandwidth and draw distance settings that were, let’s say, “extreme”. Normally, if we get them to drop their bandwidth and draw distance to a reasonable setting, they’re fixed.
The Firestorm team have a wiki item about checking and setting the viewer’s network bandwidth which is useful as a rule of thumb for all viewers.
Ed also reported that some users who found a part or all of their avatar grey were seeing the problem resolved if they disabled HTTP textures from within the viewer.
Whether this was due to a poor connection with the SL servers or a hardware issue is unclear. However, the thinking is that it is most likely due to something in the network path between the viewer and the SL servers getting hit with too many HTTP connections (which now include avatar baking). Disabling HTTP textures in the viewer forces regular texture downloads to shift back to the UDP service, thus reducing the number of HTTP connections, allowing avatar textures to load.
Issues when Connecting to SL via a Cell Phone
Problems have also been reported for those using a connection via their cell phone (non-public JIRA BUG-3323). This appears to be down to a issue whereby the size of the packet that the viewer is expecting from the SSA servers doesn’t align with the amount of data actually in the packet. The Lab is currently investigating this, but the issue does seem to be constrained to only a few users.
Commenting on what is coming up next while at the TPV Developer meeting on Friday August 23rd, Nyx Linden said:
I also have the next round of [viewer-side] changes ready to push from Sunshine internal [LL's private repository] to Sunshine external [the public repository] … In it, you’ll see what should be all of the new inventory capabilities for the new inventory functionality for getting your Current Outfit Folder set. These changes appear to work on our developers’ machine, but are completely untested as far as you’re concerned. So this code is definitely not ready for merging into a mainline branch but feel free to do a merge into a side dev branch.
COF Mismatch Fix
Once this update is ready for formal inclusion into viewers, it should put a final end to any risk of Current Outfit Folder duplication, and should also help prevent further COF mismatch issues.
To explain: essentially, your appearance is keyed to the version number of your Current Outfit Folder (COF). This represents everything required to render your avatar (height, shape, etc.) and a set of texture IDs representing the avatar’s baked textures. As such, the version number increments with appearance changes.
However, because the inventory system currently relies on two message protocols (UDP and HTTP), there are cases when changing outfits / appearance where the messages which pass between the viewer and the baking service can get misinterpreted by the viewer, resulting in a disagreement between it and the baking service on the actual COF version number. This results in a”COF mismatch” error, and parts of your avatar appear blurry as a result (see FIRE-11143), which aren’t always resolved using the normal rebake function (CTRL+ALT+R).
Currently, to fix the problem, users can do one of the following:
- Relog. This sends a fresh appearance request from the viewer to the baking service which uses the current version of your COF from the servers
- Switch outfits – although this has been shown to be less reliable than relogging
- If the viewer has a texture refresh function, use that with the avatar.
When Might Things Happen?
It is currently unclear as to when the viewer updates are liable to appear in a fit state to be included in release versions at present. Even though the code is now available for TPVs to take an pre-merge into test versions of their viewer, there currently aren’t any regions where the updated code and new fixes can be tested. Before any can be set-up on Aditi, the code needs to go through several more rounds of internal testing at LL, so it might be a while before such test regions appear.
A further complication is that the Lab is still working on the code. In particular, they are removing all of the old baking service code from the viewer (something TPVs who connect to both SL and OpenSim need to be careful around), and there are further bug fixes to go into the viewer.
One of the additional fixes which will be included in the code will reduce the number of times the viewer requests your appearance from the baking service, which Nyx describes as happening “far too frequently at present”.
While this isn’t seen as an issue for the back-end of the service because requests are cached and the data can be easily re-sent, there is a throttle in place for such requests, and in certain situations a viewer can hit that throttle. Should this happen, it slows down responses from the service and impacts the user’s experience until such time as the viewer backs-off on the number of requests it is sending. Reducing the number of requests the viewer makes to the back-end services should also assist those suffering from network issues as a result of the viewer sending too many requests or generating too many connections.
There have been interesting developments on the TPV Z-offset situation.
Cool VL Viewer
In July, frustrated with LL’s apparently unwillingness to look further into the situation, Henri Beauchamp managed to find a means to implement the new hover function the Lab developed so that it works in much the same way as the old z-offset. He explains how in his release notes for Cool VL Viewer v126.96.36.199, v188.8.131.52 and v184.108.40.206 (and which I confess to missing at the time):
I managed to implement it in a way that allows to modify the Hover parameter without having to edit your avatar’s appearance each time (even though the result is the same: your avatar shape gets modified, saved and “rebaked” each time).
Henri has done this by linking the hover functionality provided by LL to the z-offset spinner in the Movement floater of the Cool VL Viewer, onc again allowing users to make “on-the-fly” height offset adjustments. As each change is made, the avatar shape is saved into the asset server and the avatar rebaked by the servers, allowing adjustments to be made without editing appearance and triggering an update on exiting the appearance editor.
There are some caveats with the capability which need to be borne in mind:
- As with LL’s hover feature, that avatar shape must be modifiable (if not, the Z-offset capability is unavailable)
- There will be a delay in setting the offset because each change does require viewer / server communications. Multiple quick changes to the z-offset should therefore be avoided, as they may not propagate correctly
- The function may have problems when the asset server is under heavy use (e.g. during peak hours)
The function can be found in all current version of the Cool VL viewer.
Restrained Love Viewer
- TPV developer meeting video (SSA discussion between 5:00 and 18:45 minutes) – with thanks to Pantera