As always, please refer to the week’s forum deployment thread for the latest news and updates.
Main channel: Tuesday November 5th
The Main channel was updated with the same maintenance package previously deployed to the three release candidate channels, and which comprised bug fixes and crash modes.
Release Candidate Channels, Wednesday November 6th Currently Cancelled
All three release candidate channels should receive the same maintenance package, comprising further infrastructure changes for the yet-to-be-announced Experience Keys (experience tools) project.
SL Viewer
There have been no release updates so far this week. However, a bug has been reported within the former “Sharestorm” viewer (the current release viewer, 3.6.9.282535), wherein fps rates are severely impacted when the CHUI conversation floater is open. If you’re using the current release viewer, and find frame rates are being impacted when conversing, try switching to CHUI’s Compact View.
If you find your FPS reates are being hit when you have the CHUI floater open in the current SL viewer release (or a viewer with the ShareStorm code), try switching CHUI to the Compact Viewer (above)
A further bug that has been reported sees FPS impacted if the Build floater is opened after having About Land open in a region with a long covenant.
Region Restart Sound
A new JIRA has been put forward (STORM-1980) to have a default region restart sound added to Second Life. This would be played automatically by the viewer on receipt of a region restart message, adding an additional warning of an approaching restart for those who may miss the pop-up notices, be working on another screen / window or who are otherwise distracted while logged-in to Second Life, allowing them to take appropriate action prior to the region starting and them being logged-out. Work on this is in progress, and is generally seen as a good idea.
Other Items
Scripted Sound Improvements?
Requests have been raised at several meetings recently about the possibility of improving scripted sound functions (such as being able to use a single sound loop for a vehicle’s engine and using LSL to change the pitch of the loops when the vehicle is accelerating or slowing down, for example) and to possibly make the prim collision sound being a property of the prim instead of the script.
Commenting on the former request at the simulator user group meeting on Tuesday November 5th, Simon Linden said, ” there have been some JIRA feature requests about llLink-something with sounds [“llLinkPlaySound”, “llLinkStopSound” and “llLinkLoopSound”]. We’ve discussed it internally and it seems like a good idea, but needs some work to see if we can cover as much functionality as possible with a reasonable API.” Expect more details as the work progresses.
The following summary is taken from the TPV Developer meeting held on Friday November 1st. A video, courtesy of North, can be found at the end of this report. The numbers in braces after each heading (where given) denote the time stamp at which the topic can be listened-to in the video.
General Viewer News
As noted in part 2 of this week’s report, there are currently two release candidates in the LL viewer release channel, the GPU Table RC, which contains updates to the viewer’s GPU table but no functional changes, and another Maintenance RC, which includes finer access control for estate/parcel owners; CHUI: toggle expanding Conversations by clicking on icon + more.
It is expected the Google Breakpad RC will be returning to the RC channel in week 45 (see below).
Several of the remaining anticipated viewer RCs / project viewers, again as previously reported, held-up as a result of issues uncovered in QA and / or bugs being re-introduced into them. These include:
The Group Ban List viewer: work here, which involves server and viewer changes, is held-up as a result of QA testing revealing some issues which Baker Linden is addressing (as per part 2 of this report)
The interest list viewer, which recently saw the issue of objects failing to render without a relog return to the code after having been fixed, and which still has one or two other issues to be fixed, although Oz Linden feels those working on it are homing in on solutions
The HTTP viewer updates, which were for a time awaiting QA resources (see below for a further update).
AIS v3
[02:29-07:07]
Nyx Linden, Tiny RobotTM, in the Halloween spirit
The Lab is keen to start progressing this work towards a release. As with Server-side Appearance, they’re looking to TPVs to help with various aspects of testing. To this end, a request has been passed to TPVs that they indicate to the Lab when they have merged the code into experimental versions of their viewers so that a pile-on test can be arranged in order to put the updates through their paces.
There is no specific date for when this will take place, and commenting on the project in general, Nyx Linden said:
Now is a good time to start your merges, I’ve just pushed an updated to Sunshine external, so you guys should have our latest and greatest … But again, this is not formally QA’d, we’ve been testing things as we’ve been going on, but it is not ready for release yet. But now is a good time to start doing test merges and getting side branches up-to-date with that.
The latest code includes a fix to viewer-side behaviour. On logging-in to Second Life, the server sends a list of the things it believed an avatar was wearing, although the message only had room for one wearable of each type (e.g. undershirt, shirt, jacket, etc.), and so it may or may not be up-to-date with the Current Outfit folder.
While the current release versions of the viewer ignore the contents of the message, they do still wait on the message for timing (thus slowing down avatar processing). With the new code, the timing pause is being done away with, so that the viewer should be able to start resolving the avatar from the Current Outfit Folder whether or not the message has been received. There is a slight side-issue with this change that may affect some avatars under limited circumstances, but a fix for this issue is due to be made available to TPVs before the code even reaches any experimental versions of their viewers.
Viewer Crash Reporting
[09:00-14:50 and 26:03-31:15]
There is an issue with the viewer crash reporting which means that a lot of crashes are being incorrectly reported as viewer “freezes”. This is something the Lab is aware of and is working to address. The problem lies with a number of the mechanisms used to determine various types of crashes are not working, with the result that the associated crashes are being misreported as the viewer freezing.
As well as addressing this issue, the Lab has also been working in other areas related to Google Breakpad and crash reporting, including:
Simplifying and cleaning-up the creation and interpretation of the marker files used to generate crash rate numbers
Re locating these files much earlier in the viewer initialisation and log-out processes so that crashes which occur during the viewer’s initialisation or termination can also be captured
Addressing those crash reports which are generated, but lack associated stack dumps or mini-dumps and ensure that in the future that do have the required information, thus allowing the Lab to fill-in more of the blanks and ensure even more meaningful data is gathered as a result of crashes.
TPV Developer meeting, Friday November 1st
It will be a while before this work is ready for inclusion in viewers; one reason for this is because the improvements to Google Breakpad require continual rounds of user testing as changes are made (hence why the Google Breakpad RC appearing and vanishing and reappearing in the viewer release channel). However, once the code is ready for release, it should provide for more accurate crash reporting across all viewers. As the work comes to fruition, it should allow for more accurate identification of a range of crash situation and assist with the work in trying to eliminate them.
As always, please refer to the week’s forum deployment thread for the latest news and updates.
Main channel: no update
Release Candidates: all three received the same new server maintenance package on Tuesday October 29th, which fixed some crash modes.
The RC release will likely be promoted to the Main channel during week 45.
Upcoming Work
At the Server Beta meeting on Thursday October 31st, Maestro Linden indicated that Simon Linden is working on a new package, but that it might not see the light of day for another week or so. “[It] has a bunch of miscellaneous fixes, including a potential fix for BUG-4152 (that ‘parcel full’ bug with vehicle region crossing which is rather common),” he told attendees.
There are apparently more “shinies” being worked on, but they are unlikely to be in this maintenance project, which Maestro describes as “solely bug fixes.”
SL Viewer Updates
The Maintenance RC viewer updated to release 3.6.10.283139 on Wednesday October 30th, otherwise no other changes to the viewer release channel.
There appears to be a closed viewer repository called “343-fittedmesh” with Oz Linden’s name attached to it. Quite what it might be is open to speculation, but the name might carry a possible hint. It has certainly prompted suggestions that the Lab might want to rethink their approach to code repository naming!
Baker Linden: Group Ban List
Baker and Caleb Linden (no, it’s probably best not to ask…!)
“So group ban stuff is progressing more,” Baker Linden informed the Server Beta meeting. He went on:
However with Caleb and Maestro’s magnificence in finding out things I did wrong, we’re still in internal QA. There are a couple issues that I’m currently working on, and one issue that came up today that I’m going to need some time to think about over the weekend. I’ve already fixed a few bugs however, so it’s still progressing, just much slower than I would have liked. I’m sorry that it’s taking a long time to get out. I’m touching a lot of systems and I want to make sure it’s done properly. I really do appreciate all the patience y’all have with me too :).
Other Items
Scripted Sound Improvements?
During the Simulator User Group meeting on Tuesday October 29th, a question was raised about improving scripted sound capabilities with additional functions and parameters (e.g. “llLinkPlaySound”, “llLinkStopSound” and “llLinkLoopSound”) which would allow for things like a single looped sound for a vehicle’s engine, with the ability to change the pitch of the sound to emulate the changing engine pitch when accelerating or slowing down without the need for multiple sound clips. This has been coupled with a request to make the prim collision sound being a property of the prim instead of the script.
Commenting on the request as the Server Beta meeting, Maestro indicated that Kelly Linden may be looking into things, although details of exactly what with be implemented, and what calls / parameters, etc., will be used is unclear. For the purposes of frequency modulation, viewer side changes will be required for making any adjustments to sound frequency.
Region Relocations
The subject of making it easier to move entire / large region builds from one region to another (so someone who owns two regions can move the contents of one to the other). currently there is no easy way to accomplish this. Apparently, the capability to ” restore to last position” (now only usable if you have rezzing rights at 0,0,0 within a region) was introduced for precisely this reason when the Linden were moving Adult regions to Zindra in 2010. Whether or not a capability to move region builds in this way would be re-introduced is open to debate; it is quite possible it is something that would not see that much use. Those wanting it, however, might want to file a Bug report (and label it “Feature Request”).
As always, please refer to the week’s forum deployment thread for the latest news and updates.
Main Channel
There have been no updates to the Main channel.
Release Candidate Channels
All three release candidate channels received the same new server maintenance package on Tuesday October 29th, which fixed some crash modes.
The reason for the RC channel updates being moved to Tuesday is because there was due to be a planned outage on Wednesday October 30th at the time the deployments usually take place to allow some database work to take place. This would have likely seen log-ins blocked for about an hour. However, Simon Linden believes the work has now been postponed for a week – although the recommendation is to keep a check on the Grid Status page – see the original notice for details.
SL Viewer Updates
A new release candidate appeared in the release channel on Monday October 28th. Version 3.6.10.282997 has no functional updates, but includes an update to the GPU table.
About the GPU Table
The GPU table is used to define your graphics card to the viewer and the default graphics settings which are applied as a result when you first start the viewer (or if you never adjust them).
Graphics cards are defined by classes (currently 0-5), which can be defined as:
0 – Defaults to low graphics settings. No shaders on by default
1 – Defaults to mid graphics settings. Basic shaders on by default
2 – Defaults to high graphics settings. Atmospherics on by default
3 – Same as 2, but with lighting and shadows(now referred to as Advanced Lighting Model in the viewer) enabled
4 – Same as 3, but with ambient occlusion enabled
5 – Same as 4, but with shadows set to “Sun/Moon+Projectors.”
The table is a .TXT file which is located in a viewer’s installation location on your computer. For Windows, this means it can be found either in C:\Program Files\[viewer name] or in C:\Program Files (x86)\[viewer name] (if you are running a 32-bit version of a viewer on a 64-bit system).
It is not recommended that you amend this file in any way, unless you know what you are doing. You can, however, open it and use it to determine which class your viewer falls under, and the default settings it is given.
To make it easier for those wanting to quickly reference common graphics cards, Garvie Garzo has produced a .PDF file of the table. However, do bear in mind that the table is subject to updates (as the release candidate mentioned above demonstrates), so the PDF may become outdated over time. Also, some TPVs have been working on updating the GPU table themselves.
When perusing the table, cards are listed alphabetically by maker, and the first digit following the card name refers to the class it has been assigned to, while the far right column defines the overall family of GPUs the card belongs to (you may find when viewing the table that the columns do not align well).
The settings within the GPU table are subject to some debate, as they are used to determine which graphics cards present a “reasonable” enough performance in order to have ALM enabled by default. Linden Lab consider anything qualifying as a class 3 or above is capable of adequately running with ALM enabled; some TPVs do not agree.
The problem here is how “reasonable” is defined; it’s a subjective term, and everyone will have their own opinions on the matter. As I reported back in week 39 and week 34, the Lab had statistics to show that class 5 cards GPUs (e.g. ATI Radeon HD 7800, 7900, 8900, 8950 + similar, nVidia GTX 460/460SE, 465, 550TI, 580, 660/660TI + similar) actually performed better with ALM enabled than with it off, while class 4 GPUs showed little difference between having ALM enabled and disabled. However, because measurements do tend to be subjective (again, frame rates, etc., can take on different levels of importance depending upon what you are doing in SL), Oz Linden had been hoping to establish a means by which more controlled testing could be undertaken within the Lab; it’s currently unclear how far this has progressed, if at all.
Interest List Viewer
Andrew Linden revealed that the interest list RC / project viewer (however it appears) is now unlikely to debut before November 12th. “There was a performance regression that we’re working on — lower FPS in project interesting,” he informed the Simulator User Group meeting on October 29th, “Probably because it is rendering more objects — more small objects in view get rendered (that’s my theory anyway).”
Andrew Linden: Anti-griefing Work
Andrew Linden
Andrew Linden is back working on various pieces of anti-griefing work.
For obvious reasons, he doesn’t want to go into specifics, but he did indicate that he’s looking to address new griefing modes that are aimed at estate managers. He’s also been thinking about ” raising the arms race against landbots”, although he admits he is “still in the planning/discovery phase on that.”
There are a number of other items in his list as well he may well be taking a look at.
Other Items
Slow loading Sculpts?
Some people are reporting they are seeing sculpts loading a lot more slowly since the last set of server-side interest list updates. It’s not clear how widespread this might be or if it is a possible placebo effect. For his part, Andrew Linden felt that sculpts potentially download faster with the interest list viewer code (which, as noted above, has yet to make a public debut), but again he caveated why this might appear to be the case. Andrew indicated he’ll look a little more into this.
Last Owner / Previous Owner
Many TPVs expose details of the “last owner” of an object through the build floater. A request has been passed to make this information, which is stored as a field in the object data, accessible through scripts. Both Simon and Andrew Linden didn’t see why this could not be done, with Andrew stating he’ll see what’s involved and will look to someone to nudge him about it next week.
Things are in something of a lull server-side in terms of deployments and projects at the moment, so the news from the Lab is a little light.
Server Deployment
With just the one deployment to the Main channel in week 43, the entire grid is currently running on the same server release.
Commenting on the released package at the Server Beta group meeting on Thursday 24th October, Maestro and Simon Linden provided further information on the performance issue fix which is aimed at the experimental interest list viewer (which has yet to formally appear, but can be self-compiled by those with access to the code repository).
“The bug was about avatars not loading for ~70 seconds when you visit an area with ten or so avatars nearby, Maestro explained. “And by ‘not loading’, you wouldn’t even see name tags.”
“I think the problem was when those viewers used new methods to download or check the cache state of some data … it would over-load the network and thus the avatar updates were really slow,” Simon added, before continuing, “Since the current viewer doesn’t do that, they don’t have the bug. Clubs and large crowds are always a problem because when you arrive you just get a ton of data to fetch and load.”
Week 44 should see what Maestro described as a “minor maintenance release” for the server appearing next week, which includes “a few miscellaneous crash fixes”. At the time of writing it is not clear if this will be the only RC deployment or whether anything else might also pop-up when the deployment thread is published.
SL Viewer Updates
The “Sharestorm” release candidate, version 3.6.9.282535, which combined the updates from the Snowstorm contributions viewer featuring the request teleport functionality with the SLShare release candidate, was promoted to the de facto release viewer on October 23rd. This leaves just the Maintenance release candidate viewer 3.6.9.282553 sitting in a release cohort, which will be updated in week 44, once it has been rebuilt using the release viewer code base.
Group Ban List
Baker Linden’s Group ban list work remains on internal testing within the Lab (with Maestro and Caleb Linden volunteering as Baker’s guinea pigs). The project has also apparently been awaiting internal QA resources. Baker hopes to have a detailed update on progress in week 44, but as he said at the Server Beta meeting, “I’d rather take the time to do it properly than rush it out the door and have it be worthless! :).”
Other Items
As reported in week 42, A problem had been noted following-on from the recent updates to prevent people from using recursive rezzing which means some engaging in combat have found combat vehicles in regions with short auto-return times can have their ordnance immediately returned when a weapon is fired, and any temp vehicles are unable to rez attachments, even when sat upon. Maestro confirmed that as a result of a feature request having been raised, Andrew Linden is now looking at introducing a special exception for temp-on-rez / auto-return timer inheritance when the rezzer is a vehicle.
As always, please refer to the week’s forum deployment thread for the latest news and updates.
Second Life Server (Main Channel) – Tuesday October 22nd
The Main channel was updated with the server maintenance project that was previously on all three RC channels. The package includes:
A fix for “Group member access to parcels fails when ‘Sell passes to’ is enabled”
Fixes for two region crossing issues:
“‘Ghost’ avatars and vehicles sometimes appear to an observer at the sim border”
“Vehicles which exit a region with a passenger are incorrectly auto-returned and become ‘ghost shapes’ in the physics engine”
Extremely high Avatar Render Weights reported to the server are now capped at 500,000
A performance issue fix for avatar loading speed in the experimental ‘viewer-interesting’ viewer.
Second Life RC BlueSteel, RC Magnum, and RC LeTigre – Wednesday October 23rd
There are no updates planned for the three RC channels, as a result, there was no rolling restart across the RCs.
SL Viewer Updates
The Google Breakpad RC was removed from the viewer release cohorts at the end of week 42.
Interest List Viewer
The interest list RC viewer is once again delayed. Commenting on it at the Simulator User Group meeting on Tuesday October 22nd, Andrew Linden indicated the hoped-for schedule for its appearance is before the end of the month, but there is something of a low confidence level in the estimate.
Apparently, there is still a performance issue to be dealt with (whether this is the same issue Richard linden mentioned in discussing the interest list viewer at the TPV developer meeting on Friday October 18th is unclear). Also, it seems that the recent issues of objects steadfastly refusing the render in the interest list viewer without a relog – thhought to have been resolved in week 42 – have also regressed into the viewer code with recent builds.
The issue of prims failing to render in the Interest List viewer, as demonstrated by Whirly Fizzle in the images above and once thought to have been solved, has apparently returned to haunt the code in recent builds, helping to further delay the appearance of the viewer as a release candidate.
Andrew also clarified that the definition of objects which are cacheable by the viewer has been revised such that it is now objects which have not changed outward appearance or transformed in the last two minutes, rather than the one minute Richard Linden indicated, so as to allow for temp-on-rez objects (otherwise additional logic would have been required to check on these). The changes to the definition also mean that some scripted objects which have certain script calls in them, but which do not change appearance as a result of the calls, can also now be cached by the viewer.
As an adjunct to the interest list viewer discussion, Andrew indicated his “before / after” video for scene loading has received the “Torley treatment”, and the results are “impressive”. This is for the changes already implemented server-side, and which should already be visible to people without the Interest List viewer. There’s no date as to when this video may make its public debut.
Other Items
LSL Control for Materials
There have been renewed enquiries for the introduction of scripted control for materials. This has been requested in the past, and was always considered “out-of-scope” for the initial release of materials. A (further?) JIRA has been raised on the topic (MATBUG-359), but is light on suggestion on what might be required, etc.
Those Lindens attending the meeting (Andrew, Kelly and Simon) could see the advantages of extending LSL to handle materials (and Brooke Linden has indicated she feels the JIRA is a valid request). However, how best to achieve this, and the time-frame in which it might be achieved (not just in terms of a technical approach, but also in terms of the Lab’s internal priorities and workload) are unclear at this point.
Both and Andrew and Kelly felt that requiring the normal / specular maps to be in the object contents might be a means by which to both enable and constrain the use of LSL manipulation of materials because of the lack of permissions associated with UUIDs and concerns of misuse. While no promises were made as to whether the work would proceed, Simon Linden suggested a further step would be to lay out a clearer proposed API and the exact behaviour required for manipulating materials via script. Andrew also indicated he has a “few” LSL calls to add, so he’ll try to take a look at the materials system o see how hard it would be to give script access to it.
llGetObjectDetails() and keyframe animation states
Simon Linden indicated that there has been some talk within the Lab of adding some new parameters to llGetObjectDetails() which would return an object’s keyframe animation states, so it would be possible to get the step number, state (paused, looping, ping-pong, etc.). Again, if / when this might appear is unclear; Simon appeared to be putting the idea out for feedback from the meeting attendees.
Inara Pey: Living in a Modemworld 