On Tuesday, September 15th, the Main (SLS) channel was updated with the server maintenance package previously deployed to the three RC channels, comprising internal simulator fixes and a fix for BUG-9504 “Clicking on any object that affects the navmesh while in Mouselook dirties the navmesh”.
On Wednesday, September 16th, the RC channels were updated as follows as noted below.
Magnum and LeTigre
Magnum and LeTigre received a server maintenance package providing llGetAttachedList(), which returns a list of all visible attachments worn by an avatar in the same region (i.e. it does not currently include details of any HUDs) as per feature requests BUG-9683. The wiki page for the function is still appears to be in preparation. Also completes feature request and BUG-9891.
Commenting on data relating to HUDs during the Simulator User Group meeting on Tuesday, September 15th, Simon Linden said, “I’m likely to change that a bit in the future to maybe allow some restricted access to HUD info, so you can get info on those too, but I need to figure out the right restrictions so it doesn’t become a privacy issue … I’m concerned about it as a privacy thing, like I give you something, you rez it, and it sends me an IM listing all your HUDs.”
BlueSteel
The BlueSteel RC received a further roll of the server maintenance package containing internal simulator fixes to improve inventory performance. These updates had previously been deployed in weeks #36 and #37, only to be rolled back due to various issues (e.g. the “zombie eyes” situation and problems with note cards and scripts as reported in BUG-10183).
SL Viewer
On Wednesday, September 16th, the Quick Graphics project viewer updated to version 3.8.4.305063, with further tweaks to the Avatar Complexity elements. On Thursday, September 17th, the mesh importer viewer RC updated to version 3.8.4.305119.
It appears that the obsolete viewer supplied for users on XP and OS X 10.6 or earlier (version 3.7.28.300847) , may cease working with anything involving monetary transactions (e.g. the Marketplace, buying L$ through the viewer, etc.), possibly by the end of the year. This appears to be the result of compliance reasons preventing the Lab from continuing to provide that backward compatibility.
llGetEnv
During the Simulator User Group meeting, Simon threw out a question and comment relating to llGetEnv:
How useful would some new items for llGetEnv() be about simulator health? … I can imagine wanting to know both temp and normal rez counts, maybe for a specific item too – like if there are 10 projectiles already waiting.
He requested a feature request be filed on the matter, which was duly filed by Lucia Nightfire – see BUG-10263, and simon requested the people add their thoughts / ideas, noting that, “simplest ones are most likely to get attention and stand a chance of getting done.” If adding to the feature request, remember to specify how any additional data requested will help improve the SL experience for those using the function.
At the TPV Developer meeting on Friday, September 11th, the Lab provided further information about the ongoing work to improve inventory handling and management in Second Life.
As has been reported through these pages, the Lab has been tackling a wide range of issues related to inventory, inventory management, inventory losses, etc., over the last several months. The updates given at the TPV Developer meeting were to provide information and news on both the work to help fix issues around large “flat” inventories, and on new and upcoming work in rationalising inventory related code within the viewer, with Izzy and Aura Linden providing the updates.
The video of the meeting can be seen here, and time stamps are given below to the relevant points in the video where the items are discussed.
“Flat ” Inventories
[10:15] This is something that has been mentioned through a number of project updates in these pages. However, in summary: if you have a large “flat” inventory structure with tens of thousands of items contained in single folders at a time, rather than being split between multiple sub-folders, you can experience significant issues in logging-in to Second Life, up to and including being completely unable to log-in at all.
Earlier in the year, the Lab developed an inventory transform tool which, when run, can take the contents of such large folders and split them into smaller, easier-to-load sub-folders. This tool has been undergoing testing for some time, but has now been issued to the Lab’s support teams. So, those encountering log-in issues and know they have large, relatively “flat” inventory structures can raise a support request (Premium or Basic) and have the tool run against their inventory, thus hopefully fixing matters for them.
Inventory Code Improvements
Task Paths
[12:50] Currently, the viewer has multiple paths and mechanisms by which inventory tasks can be undertaken / completed. Aura is therefore working through the viewer code to try to rationalise how inventory is handled, ensure that older paths / mechanisms are properly deprecated / removed and replaced by newer and more robust mechanisms.
[14:20] The first set of changes Aura is working on is to remove from the viewer all of the old UDP inventory messaging paths which have already been replaced by more robust mechanisms (and in some cases already had the server-side support for them removed), but which have until now remained a part of the viewer’s code.
These changes should be appearing in a project viewer for testing by TPVs in the next month or so. This is to allow them to identify possible impacts on any dedicated inventory handling mechanisms they may use (e.g. RLV / RLV/a) which may also use the older UDP messaging paths, and address any updates they may need to made as a result.
Once this viewer reaches release status, the Lab will seek to remove any server-side support for legacy UDP for inventory operations from the simulator code. Again, this will be done in consultation with TPVs, with testing regions available on Aditi beforehand, so the Lab can again be warned if they are triggering potential problems which may need to be thought about / addressed.
Code Refactoring
[19:35] The second element in the work is a refactoring of the viewer inventory files. This work will initially rationalise inventory functions within the viewer so that they are more closely coupled with their actual purpose, rather than being more widely scattered through the viewer code, and will not involve any actual code changes.
However, a further part of the work will involve code changes, with the overall aim being to make the code a lot more readable, easier to test and maintain and understand.
Server-side Inventory Rules Enforcement
[23:32] Additionally, once the above work has been carried out, new checks will be added server-side to prevent actions which are known to cause inventory problems from happening.
For example, there have been issues where people have found themselves with more than one Current Outfit folder or with multiple Trash folders, both of which can result in complications when using the viewer. The simulator-side rules, when put into place, will be designed to prevent these kinds of instances occurring.
Time Frames
As noted, the first phase of Aura’s work – the initial code deprecation work – will be appearing in a project viewer in the next month or so, and the work will progress from there in the stages, thus:
Remove the deprecated inventory message paths from the viewer
Remove any remaining simulator support for deprecated inventory messaging support
Rationalise the inventory functions in the viewer
Refactor the viewer’s inventory code in the interests of stability, maintenance, testing and update
Add simulator checks to prevent folder duplications, etc
How long it will take to implement each phase isn’t currently clear, and will to a degree depend on feedback about issues discovered by TPVs, as well as the results of continued testing by the Lab.
Note: Due to a lack of concentration on my part, I managed to originally publish this article in Private mode, and only realised when looking to obtain the details of BUG-9504 for the Week 38 update! I’ve now flicked it to public for completeness of reports.
On Tuesday, September, 1st, the Main (SLS) channel received the server maintenance package deployed to all three RC channels in week #35, comprising:
A fix for BUG-9504 “Clicking on any object that affects the navmesh while in Mouselook dirties the navmesh”
Internal simulator fixes
On Wednesday, September 3rd, the BlueSteel RC received an updated version of the server maintenance package first deployed (and subsequently rolled back) in week #34, which comprises internal fixes aimed at improving inventory performance.
BlueSteel Issues
The BlueSteel deployment was followed by issues with note cards and scripts, including issues trying to create / save scripts and note cards created on BlueSteel regions and when trying to open scripts / note cards created on other channel regions while in a BlueSteel region (see BUG-10183).
As a result of these problems, and following investigation by the Lab, the BlueSteel deployment was rolled back on Thursday, September 3rd.
SL Viewer
The Quick Graphics project viewer, comprising the new graphics presets capabilities and Avatar Complexity options updated on Thursday, September 3rd to version 3.8.4.304761. An overview of the capabilities can be found in this blog, and official information on Avatar Complexity can be found in the SL wiki.
On Tuesday, September, 1st, the Main (SLS) channel received the server maintenance package deployed to all three RC channels in week #35, comprising:
A fix for BUG-9504 “Clicking on any object that affects the navmesh while in Mouselook dirties the navmesh”
Internal simulator fixes
On Wednesday, September 3rd, the BlueSteel RC received an updated version of the server maintenance package first deployed (and subsequently rolled back) in week #34, which comprises internal fixes aimed at improving inventory performance.
Due to the issues experienced when this latter package was deployed to all three RC channels (such as the “zombie eyes” situation), the package is only being deployed to the one RC; Magnum and LeTigre will remain unchanged from week #34, keeping them on the same release as the Main channel.
SL Viewer
On Tuesday, September 1st, the Mesh Importer RC viewer updated to version 3.8.4.304605, making its promotion to the de facto release viewer in week #36 unlikely, but not impossible.
Region Restarts and Caps Failures
A problem often encountered following region restarts is that some regions come back with a caps failure (so a lot of things that should work, don’t). While less frequent an occurrence than has previously been the case, the problem does still occur. The problem is thought to be at the server level, as regions hitting the problem tend to all be located on the same server.
Commenting on the matter at the simulator User Group meeting on Tuesday, September 1st, Simon Linden said:
I have a good theory about caps failure on the rolls but the last time I tried to fix it, the update went badly and we rolled back :). My theory is good, the side effect was bad. When we restart regions, we do them all at once. My fix was to pace that slightly, and not overwhelm the caps system. However, the delays confused the system starting the grid, and it started the same regions multiple times, which didn’t go well. And of course it didn’t do that on the beta grid.
Since his initial attempt at correcting things, Simon has been engaged on other work (such as getting group chat fixed), but he is hoping to get back to working on this problem at some point in the future.
Avatar Complexity (aka Jelly Babies) is now available in the Quick Graphics project viewer
Update:See BUG-9962 for issues relating to avatars becoming stick as Jelly Babies when using Avatar complexity.
On Friday, August 21st, the Lab issued their Project Quick Graphics project viewer. Version 3.8.4.304433 brings with it the much-anticipated Avatar Complexity and graphics presets capabilities, both of which are intended to assist in improving viewer performance for those on lower-specification computers.
I provided an overview of the viewer while it was still in an early version, so this is offered as a further update.
Avatar Complexity introduces a new slider to the viewer which can be used to set a level above which avatars requiring a lot of processing will appear as a solid colour (including their attachments), giving them the nickname ” Jelly Babies” after the sweet (candy) of the same name.
As avatars can often be the single biggest impact on the viewer in terms of rendering, particularly in crowded places, using this slider is intended to greatly reduce the load placed on a system compared to having to render them in detail, allowing users to adjust the setting according to circumstance – the setting can be increased, rendering more avatars as solid colours in crowded regions, and turned down for quieter spaces. At the same time, there’s also the ability to set how individual avatars are rendered on-the-fly during the current log-in session.
The Avatar Complexity slider in Preferences > Graphics > Advanced Graphics Preferences (l) and the new format of information displayed when Advanced > Performance Tools > Show Avatar Complexity Information is enabled (r)
The Avatar Complexity slider can be found on the Advanced Graphics floater (Preferences > Graphics > Advanced Settings…), The values run from 19,999 to 300,000, above which it switches to No Limit, meaning all avatars in your field of view will fully render, with the default based on the rendering performance of your system. As noted in my last piece on this, the values used by this slider are based on those previously used to determine Avatar Draw Weight / Avatar Render Cost.
It is possible to see the render complexity of all avatars in your field of view (including your own) by enabling Advanced > Performance Tools > Show Avatar Complexity. This displays a series of figures above avatar heads which is updated in real-time. The one likely to be of interest to most users is at the top: the actual render complexity value. This should remain fairly constant, allowing for how people might change their appearance by adding / removing items and changing their appearance.
The viewer also generates information messages in the upper right corner related to Avatar Complexity. One is displayed each time you change your own avatar’s appearance and impact your own rendering complexity. The second acts as an indicator for when you’re over the limit of “too many” of the avatars around you, and are being rendered as a Jelly Baby.
The viewer displays notifications when you (l) make a change to your own avatar which impacts its render complexity; (b) if your avatar is largely rendered as a Jelly Baby by others
A further element of Avatar Complexity is the ability to selectively alter how individual avatars are rendered on-the-fly. This is achieved via the right-click Avatar context menu, which includes three new options:
The right-click avatar context menu has options to allow you to define how you want specific avatars to render during the current session
Render normally – the avatar will render as defined by the Avatar Complexity setting. If the avatar’s complexity is lower than the setting in the viewer, it will render correctly; if it is higher, it will render as a Jelly Baby
Always Render Fully – does exactly what it says – the avatar will always be fully rendered, regardless of it exceeding your set complexity limit
Do Not Render – renders the avatar as a Jelly Baby (or even not at all save for name tag if already very easy to render) regardless of your Avatar Complexity setting. Note that this setting does not persist across log-ins (so if you re-log, those avatars you’ve used it against will render normally), and it will not block the ability to read their local chat or receive their IMs, etc.
There are a couple of final points worth mentioning with Avatar Complexity. The first is that it is not a replacement for Avatar Imposters, but can be used alongside it. The second is that with this project viewer release, the colours of Jelly Babied avatars has been muted when compared to test versions of the viewer, making them a lot easier on the eye (the image at the top of this article shows the former, more vivid colours).
Graphics Presets (see STORM-2082) allows users to create, save and use their own graphics presets, each designed to meet a specific requirement, and which can be quickly switched between with the overall aim of helping with viewer performance.
For example, one preset may have all the performance hitting items (shadows, projectors, etc.) turned on / up for times when the overall quality and depth of detail in a scene is important for taking photos, another may have them dialled-down for crowded places, and a third might have them adjusted further for “indoor” use (so draw distance is greatly reduced, sky and terrain details are set to low, water reflections turned off, etc.).
The viewer includes the means to create and save sets of graphics presets which can be quickly loaded according to need / circumstance to help maintain a viewer’s performance
Once a preset has been set-up, using the revised Advanced Graphics Preference panel, it can be uniquely saved, and then applied at will using the either via Preferences > Graphics > Load Preset, or more directly by the Graphic Presets icon located in the top right of the viewer.
When the mouse is hovered over this icon (shown right), a list of all saved presets is displayed, a tick appearing alongside the one currently being used. Clicking on any other preset will immediately apply it.
In addition, this panel also has a button which will open the viewer’s graphics settings in Preferences.
As noted in my previous article on these updates, the Advanced Graphics Preferences panel has been seen as less-than-optimal due to its size; the Lab have acknowledged the feedback, but have not made any significant changes to the layout as yet with this project viewer release. Whether they do or not may depend on feedback they receive directly from users, and what they feel can be done to improve clear deficiencies.
The ability to create and save graphics presets is a welcome addition to the viewer – these are not the same as backing-up and restoring viewer settings as seen in other viewers, but do provide a fast and efficient way to adjust graphics settings according to situation, if needs be.
Avatar Complexity is liable to be an interesting addition to the viewer. While there is a risk of seeing a return of ADW / ARC drama, it also provides the means for people to accurately judge the impact their avatar might be having on others – and their own, given their avatar must be rendered by their own computer as well – SL experience. It also potentially offers content creators to better understand how the use of mesh and textures can impact other people’s SL experience, allowing them to further improve their products.
Those wishing to try the viewer for themselves can find it here. Keep in mind, that is it s project viewer, prone to possible bugs and to further changes from the Lab, and issues should be reported via the JIRA.
There was no main channel roll on Tuesday, August 18th. The LeTigre and Magnum release candidate channel will also remain as they are for week #34.
The BlueSteel release channel received a new server maintenance package on Wednesday, August 19th, which includes internal improvements for inventory performance.
Commenting on the changes rolling to BlueSteel, at the simulator User Group meeting on Tuesday, August 18th, Simon Linden said:
If you notice anything on the Bluesteel RC channel after the roll, please file a jira on it with all the info you can about time and place and what happened … these changes aren’t about per[mission]s, I believe, but items and folders getting mixed up … Someone dug deep into the inventory system and identified some problems and tried to fix them.
The mention of permissions in his description of the update was the result of a question on whether the update would correct “perms bypassing”, which he addressed directly:
I know there’s been some talk about permission issues but from what we can tell, there are no _new_ permission problems. The best advice I can give is that you have to be extra careful about changing permissions in inventory (or in an object inventory) and then transferring it before it gets rezzed. And what I mean by “be extra careful” is, “don’t do that.”
There is a possible conflict if you change permissions while in inventory, and then pass it (without rezzing) to someone else. In that case, the “next owner” permissions can conflict with what you tried to set, so the result may not be what you expect. That’s been around forever and is often the reason people end up making copyable objects that they want “no-copy”.
SL Viewer Updates
On Tuesday, August 18th, the Lab promoted the summer Maintenance RC viewer, version 3.8.3.304115 as the de facto release viewer. This viewer includes over 50 maintenance fixes and update – please refer to the release notes for details.
The anticipated arrival of the Avatar Complexity / Graphics Presets project viewer in week #33 failed to occur, so perhaps it will arrive later in week #34.
Pandora’s Box of Dreams September 2015 – blog post
Inara Pey: Living in a Modemworld 