Deployments for Week 9
It’s a “lightweight” week for deployments, with all channels receiving one of two maintenance packages.
Server Life Server (Main) Channel
On Tuesday February 26th, the Second Life Server (SLS / Main channel) received the server maintenance project which was on all three RC channels last week. This project has miscellaneous bug fixes, along with an impoved restart notification (which will only be apparent when this new version restarts for the next update) – see the image on the right.
While this is much better than the previous notification, it does suffer from the fact it will still fade from the viewer’s window and become a chiclet whether or not the OK button is clicked – and thus can still be missed if attention is not on the screen when it appears. To help avoid this, it is possible to set a sound for the alert using the Debug Setting UISndAlert, which requires the UUID of the sound, which coule be one you’ve uploaded to inventory yourself (Firestorm additionally has UISndRegionRestart, which can be set through Debug Settings or Preferences > Sound & Media > UI Sounds 2).
This release means the until the RC channel deployments take place (see below), almost the entire grid is running the same server code – the only exceptions being a few “special” regions (such as the Linden Realms regions) – release notes.
Release Candidate Channels
On Wednesday February 27th, all three Release Candidate channels should receive a new server maintenance package which includes a fix for a crash mode – release notes (BlueSteel).
As always, there is a forum thread for discussing the deployments.
Following-on from his initial feedback given at the TPV Developer meeting on Friday 22nd February, Nyx Linden gave a further update on the recent Sever-side Baking (SSB) pile-on / load test when chairing the Content Creation User Group meeting on Monday 25th February
Thanks all for everyone who helped out with the pile-on test of server appearance last Thursday. The results tended to be that when the system worked, it was nice and speedy, however there were a number of issues that prevented it from working for everyone all the time. We got a good bit of data on the bugs we knew were there as well as a couple new ones. we’ve been crunching on the results and are starting to attack the issues, so it was definitely successful in achieving what we wanted: more data. There will be future rounds, so thanks in advance for anyone who comes back to help us test again.
Z-offset Issue and SUN-38
As noted in the comments following my quick SSB test using currently available TPVs with SSB enabled, there is an issue with the “Z-offset” capability common to many third-party viewers, which allows the vertical height of an avatar above the ground to be adjusted, such that sits and kneels don’t leave the avatar apparently floating in the air, and which allow those with very tall / giant avatars or very small / petite avatars and those wearing full body mesh to similarly adjust their vertical placement relative to the ground / floor.
The problem was reported to Nyx in week 8, and SUN-38 was subsequently raised by Henri Beauchamp on February 24th to officially log the matter. Commenting on the problem during Content Creation meeting, Nyx Linden stated. “It hasn’t escaped our notice. We’re considering a couple different approaches … we’re considering a few different options. Suggestions appreciated, but we haven’t officially settled on an approach we’re going to commit to publicly just yet.” He also suggested that any questions on the subject be asked again next week, presumably by which time LL will have had time to consider the problem in detail, and hopefully consult with TPV developers.
Interest List Updates
Andrew Linden is continuing to work on the interest list code, with more refinements to come, as well as looking at a number of bug fixes. The updates about to go to LL’s QA include changes which should make scenery load faster / more correctly when first logging-in to SL or teleporting to a region.
Motor Loon has reported an interesting issue which appears to have resulted from the initial interest list changes. Reported in the (non-public JIRA BUG-1767, Motor has found that if he is editing a script contained in an object immediately in front of him, then cams out a good distance for some reason, the script editor reports the script being edited is “out of range” of updates despite the fact he hasn’t physically moved from the object containing the script he is editing. The Lab’s QA people have confirmed there is a problem, and are investigating possible fixes.
This project is still awaiting the public roll-out of a project viewer. However, the subject of 1-bit alpha masks was again raised at the Content Creation User Group meeting on Monday 25th February, specific in reference JIRA VWR-6713. As per the second part of my week 4 news update, the Lab is looking to materials processing to do some of the lifting in answer to this, with the alpha channel option in the upcoming materials viewer offering four rendering settings for alphas:
- None – the alpha channel is ignored, rendering the face opaque, or
- Alpha blending – essentially the same as we currently have for any alpha texture, or
- A 1-bit alpha mask with each pixel either 100% transparent or 100% opaque, with a cutoff setting to determine where the threshold is (alpha masks should render faster than alpha blending, and eliminate issues with alpha layer sorting), or
- Emissive mask – so the alpha layer is interpreted as a per-pixel glow setting.
(Note that these options appear to suggest a surface cannot have both an alpha mask (or alpha blending) and an emissive mask; however, as Maestro Linden pointed out, there will still be options in the build floater to set glow or face transparency.)
These options will be present through a drop-down menu in the diffuse (texture) map options, as shown in the image below left. The updated Materials Data page on the SL wiki also provides information on handling alphas (see the Additional Parameters section).
Issues and Updates
The ongoing issues with the beta Aditi grid and inventory syncing may be coming to an end. Speaking at the Simulator User Group meeting on Tuesday 26th February, Simon Linden said, “I had one other bit of news … there was some maintenance work done on the Aditi grid inventory database. Hopefully things will be much better behaved now.”
As reported in this blog in the past, a number of options for resolving the problems have been under consideration by the Lab, ranging from purpose-written scripts to remove stale / unused accounts from the Aditi database through to the repurposing of hardware specifically for use on the beta grid to help carry the load.
While there may yet be a repurposing of hardware in the future, it was finally decided to, “Clean out the garbage first,” in Simon’s words; work which saw the removal of a lot of unused test accounts and additional optimisation work on the Aditi database.
The hope is that this work should now smooth the way to ensuring the Aditi inventory database is properly synced with Agni on a password change, and that people accessing Aditi will no longer have issues with inventory only being partially available, or with inventory changes being lost between log-ins, etc.
If you have experienced issues in using Aditi in the last few months, the advice is to reset your password (which should trigger an inventory sync), wait the allotted 24 hours or so and then log-in to Aditi.
Teleporting and Terrain
I last reported on this issue in week 4, wherein teleporting via the map can lead to some odds results, including the potential for arriving underground. A (closed to public viewing) JIRA – BUG-1280 – has been raised on the problem, and there was speculation that the problem may be related to other terrain issues arising from the deployment of the new Havok physic engine alongside pathfinding. While no specific fix for the issue has been deployed as yet, there appears to be some anecdotal evidence to suggest the frequency with which the problem is being encountered is decreasing.