SL projects update week 12 (1): server releases, SSB and more

Sever Deployments for Week 12

Second Life Server (SLS)

On Tuesday March 19th, the Main channel received the server maintenance package which had been re-deployed to Magnum in week 11. As with the Magnum re-deploy, it excludes the fix for VWR-786 while LL go “back to the drawing board” to try to correct issues. However, it does include the following two fixes:

• BUG-1612: region Owners and estate managers finding they are unable to teleport back to their region after disabling direct teleports to the region
• SVC-8019: region visibility delays following region restarts.

The release notes for the deployment are available on the SL wiki, as usual.

Release Candidate Channels

On Wednesday March 20th, the Release Candidate channels should receive the following updates:

• BlueSteel and LeTigre: should receive the same updates as deployed to the SLS channel on Tuesday March 19th, but otherwise retain the same updates received in week 11 – release notes (BlueSteel)
• Magnum: should receive further updates to Andrew Linden’s interest list work, as per the release notes.  Specific interest list bug fixes included with this update comprise:
  • Updates for objects that are out of view are delayed for a maximum of 5 seconds, at which point they will be sent (mitigates BUG-1779)
  • Fix for “No object updates from vehicles after some region crossings” (BUG-1814)
  • Fix for “Agent appears in incorrect position to other agents after being moved by a sim teleporter” (BUG-1795).

Server-side Baking

As reported in week 11, the second official Server-side Baking pile-on / load test appeared to go well on Thursday March 14th. Speaking at the Content Creator’s User Group meeting, SSB project lead Nyx Linden reported:

Looks like things are going well overall – the back-end services are performing well. There are still some inventory and attachment rezzing issues, but these are believed to not be regressions from current limits.

A few reports of issues, some of which we have fixes for, others we’re investigating, and we’re looking at what it would take to fix up the systems that were falling over … there were a couple of new bug reports we’re investigating.

A further SSB pile-on / load test conducted in Friday 15th March, but exclusively with the Firestorm viewer pre-release with SSB support. Numbers at the Firestorm test were roughly the same as those for the “official” test, and overall, the outcome was the same – much lower reported SSB issues, but similar problems with outfit attachments rezzing from inventory (or rather, failing to), which was common to both parts of the test.

The inventory issues have themselves become more of a focus of investigation outside of SSB itself (attachments aren’t affected by the SSB code changes, which  relate directly to the likes of skin, shape and clothing layer changes. While the inventory issues were thought to relate solely to Aditi, Nyx indicated that the problem is likely common to Agni as well. commenting:

We were seeing similar failures in inventory, etc on both the old pipeline and the new pipeline, and in areas that we didn’t change. So if we repeated the test on Agni we think we’d see similar failures. We’re looking at the root causes, but attachment rezzing failures won’t necessarily block our first release … We’re looking at the inventory & attachment issues and where their root causes are.

Expect further updates on the latter issue as they become known.

HTTP Testing

All of the test regions for Monty Linden’s upcoming HTTP updates are now up-and-running on Aditi, and available for public access (allowing for the caps on avatars in the primary test regions). The regions are:

• DRTSIM-203 (Agni default settings): TextureTest2, MeshTest2, and Sandbox HTTP
• DRTSIM-203H (the “Happy” channel): TextureTest2H, MeshTest2H, Sandbox HTTP H
• DRTSIM-203A (the “Angry”) channel): TextureTest2A, MeshTest2A, Sandbox HTTP A.

As noted in previous project reports, Monty is keep to have TPVs and scripters test the capabilities in order to gather more comprehensive data on his work.

Other Items

Group Ban Lists

Baker Linden reports that he has started work on Group Ban Lists. This subject recently came up for discussion at a TPV Developer meeting (February 22nd), specifically in reference to groups with open membership and JIRA (VWR-29337).

At the time, Widely Linden did respond to enquiries from TPV developers about the capability by saying, “This is something we are very interested in. I’m not saying anything more about this issue, but it is one I’ve been fascinated with for some time, and I am beside myself with joy in hearing it coming from you guys.”

Speaking at the Simulator User Group meeting on the 19th March, Baker said in reference to the work, “This will provide group owners and managers the ability to block unwanted residents from joining the group. It’s still in the planning stage, but it’s being worked on!”

Obviously, with the work still in the planning stages, details are not clear, however, it looks likely that in terms of numbers, group ban lists will at least equal estate ban lists in size (300), and may go as high as 500, or as Baker jokingly put it, “I’m either doing 500, or eleventy billion. I  haven’t decided yet, but since one isn’t technically even a number, I’ll probably go with 500 until someone reaches that limit and then I’ll cry and figure out another solution after my cold, sorrowful tears have dried.”

The work will extend to all groups, rather than just those with free membership, but there is a considerable about of work to be done, particularly as Baker would like to include the means for group moderators to provide a description of why someone was banned from a group (e.g. “spamming”, “abuse”, “scammer”, etc.) – even if only by means of check boxes, in order to enable moderators to optionally remove those guilty of minor infractions should a ban list fill up, making way for more “serious” offenders.

Baker is also considering the option of including a timed ban capability as well (so that a moderator could stated someone is banned from a group for X days, for example) – although this will most likely not be in the first release of the code, when it eventually appears.  LSL management of such a ban list would also likely be a future addition to the capability as well.  He may also include a capability to clean-down large group lists via some form of criteria (all users who have not logged in to SL for X months, for example), and a button. This is something he’d looked at adding to the group list management capabilities when he was looking at improving the management of large groups, but never actually had time to implement.

Particles and Griefing

A common form of griefing in SL is to use particle spammers. These can be used in a variety of ways. Responding to a question at the Simulator User Group on Tuesday March 18th, Simon Linden revealed that the Lab are working on some means to mitigate particle griefing / spamming. However, there are issues in addressing the problem, as particles are largely a viewer-side capability, and so responding to them tends to need to be done on a per-viewer basis.

One of the solutions Simon has indicated is being developed is the ability to right-click on a particle effect itself and to be able to select an option something like, “Mute Particle Source”. Of course, for a permanent solution to the problem, one can also disable all particles from rendering in the viewer by unchecking Advanced->Rendering Types-> Particles, but this is hardly an ideal solution, as there may well be times when someone wants to have particles visible, and turning options off/ on in the viewer can get annoying.

A feature request has been filed (non-public BUG-2012 / BUG-1940) requesting that particles should be prevented from entering a parcel in the same way as object entry / build can be disabled. Such a capability would be useful in the case of events and venues, where particle griefing could be effectively dealt with by the parcel / region owner, rather than attendees have to deal with the problem individually. However, and again given that particles are largely a viewer-side effect, getting such a capability to work is problematic.

One possible solution – suggested during the meeting by both Qie Niangao and Simon Linden – might be to get parcels to send a “hint” to all viewers within the parcel telling them not to render particles. How / if this could be achieved is unclear, but Simon agreed to pass on thoughts to the LL developer currently working on particle griefing issues.

New Havok Release

In week 11, Havok, the makers of the physics engine used by Second Life issued a major new update, billed as the “next generation” physics engine. This has fuelled questions as to whether Linden Lab will be considering an update to their Havok engine in the near future. At the time, I commented that the only feedback on the matter had come via Oz Linden, who said, “I have not heard. Most likely depends on whether or not it claims to solve a problem we’re worried about.”

I caught up with Oz on Monday, 17th March, and he clarified his comment as intending to be a  generic observation on whether the Lab might / will be adopting the new release, rather than referring to any specific issue  / concern LL had with Havok at this point in time.  I had hoped to be able to follow-up on the Havok release at the Simulator User Group meeting on the 18th March, but RL took me AFK before I could do so, and so I’ll be attempting to raise the question at the Server Beta meeting on Thursday 21st March.