Eclectica – Mystica – blog post
The majority of the notes in this update are taken from the TPV Developer meeting held on Friday, August 12th. The video of that meeting is embedded at the end of this update, and references to it are indicated through the use of time stamps in the paragraphs below. My thanks as always to North for recording and providing it.
Server Deployment – Recap
There was only a Main (SLS) channel deployment this week. This saw the roll of the server maintenance package previously deployed to the three RC’s in week #31, on Tuesday, August 9th. This comprised internal fixes and an update to prevent BUG-37573.
Release Viewer – Texture Handling Fixes
[0:35] The Maintenance RC viewer release on Monday, August 8th gained a rapid promotion to the de facto release viewer on Thursday, August 11th. Version 18.104.22.1688301 (dated August 8th).
This viewer includes a number of fixes in the image pipeline (e.g. fixes for “bad” textures – those texture files which have invalid data in them). Also included is a fix to prevent the viewer crashing when you system runs out of main (not GPU) memory while attempting to load a texture file. Instead, the viewer will substitute a plain grey texture. So, when you start to see grey everywhere instead of expected textures, it’s time to restart the viewer. This may be a pain to look at, but it is considered preferable to having the viewer crash at a potentially inconvenient moment.
[1:35] The Lab intends to move along similar lines for other issues within the viewer which can result in a hard crash, and also go through cleaning-up how exceptions are generated and caught by the viewer, and this work should be appearing in the next but one Maintenance RC update. The overall goal is to improve the image pipeline and some other points in the viewer where a relatively low-level thing results in the viewer crashing. Some of this work might also help prevent attempts to deliberately crash other viewers using textures.
In the meantime, issues have emerged affecting attachments and the Current Outfit Folder with this release – see BUG-37646 “Attachments get ghosted at login on 22.214.171.1248301”; and BUG-37653 “Every time I delete Cache and Relog, my Saved Appearances do not load and I am left as a White Cloud in Second Life Viewer 126.96.36.1998301”, for details.
Remaining Viewers in the Release Channel
[4:20] The VLC Media Plugin RC viewer, version 188.8.131.528152 dated July 28th at the time of writing, which contains the LibVLC-based replacement for QuickTime for Windows, is liable to be the next RC that will be promoted to release status. A new RC version of this viewer, merged-up to the 184.108.40.2068301 code, should appear in the release pipeline in week #33 (commencing Monday, August 15th).
[4:32] The plan remains to update the Mac version of the viewer to use VLC as a part of the 64-bit viewer development.
[6:10] The Visual Outfits Browser RC viewer, version 220.127.116.118263 dated August 1st at the time of writing, which allows users to preview images of outfits in the Appearance floater should be updated in week #33 following a merge with the 18.104.22.1688301 code. This update will also include a further round of bug fixes for this project.
[7:35] A new project viewer is being readied, which includes bug fixes and which has been merged with the 22.214.171.1248301 code. This should hopefully appear in week #33. See my Bento update 22 for more on the project.
[6:43] A new Maintenance viewer should appear in week #33. This will contain further fixes and improvements, although not the exception handling improvements referred to above.
[7:00] Work is expected to resume on the 64-bit versions of the official viewer in week #33.
[9:45] Work is progressing on Voice, with a further SL Voice plugin update expected from Vivox soon. Oz has been debugging an upcoming project / RC viewer with more Voice fixes – although this isn’t yet ready to be issued.
It has been noted that Avatar Complexity values can fluctuate when seen from different systems, on average by around 5%. This is because it is next to impossible to come up with a single figure that s accurate across all systems, as the calculations have a degree of hardware dependency (GPU, rendering capabilities, etc),
However, the Lab will continue to tweak the calculations to try to make them as consistent as possible, but this will be a gradual process for reasons Oz discussed in the meeting, and which I’ve extracted in the audio file below
A couple of particular issues which have been reported for avatar complexity calculations are BUG-37631 “Rigged mesh with partially transparent texture on it have 4 times higher complexity”, and BUG-37642 “ACI randomly changes (often at login or following a TP)”.
Memory Bloat Crashers
[8:50] With the arrival of Avatar Complexity, which provides protection against worn graphics crashers (just don’t set your Maximum Complexity slider to No Limit), it appears that inconsiderates in the virtual world are swapping to use attachments which cause memory bloat in order to crash viewers. There are, for example, attachments which can raise viewer memory to 4 Gb which immediately crasher 32-bit viewers, even if the offending avataris “Jelly Dolled”.
Oz has requested the Lab be supplied with examples, so they can start looking into the matter and hopefully come up with a fix.
Abuse Report Categories
[10:31] One of the possible issues for some Abuse Reports (ARs) appearing to go unanswered is that there are still viewers using the “old” AR categories, rather than the newer categories (as found in the official viewer). This is particularly true where users are still on versions of the viewer which do not have the revised list of AR categories.
To prevent this is the future, the Lab plan to make Abuse Report categories a capability handled by the simulator and downloaded to the viewer. This removes storing the categories in the viewer & having older viewer fail to reflect more recent category updates. It will also make it easier for the Lab to update AR categories to better meet users’ needs. A project viewer will be appearing at some point in the future supporting this new capability.
Also, within the official viewer, appending a snapshot to an AR is to become mandatory, rather than optional, to further help support identify issues and deal with them. Having a picture may not be relevant for all ARs, but for those where it could help in identifying issues, it ensures the picture is provided, rather than ignored.