Tag: Group Ban List

SL projects report week 17 (3): server, group bans and Oculus Rift

Posted on by Inara Pey

Server Deployments – Week 17

The scheduled server channel deployments took place as planned this week.

The SLS Main channel

As previously reported, this received the update package deployed to the three Release Candidate channels in week 16, primarily comprising the new server-side LSL Animation Override capabilities, complete with a fix for BUG 2164 – release notes

BlueSteel and LeTigre

Both of these channels received the first part of a new experience tools project – referred to as the “Experience Keys project” in the release notes.

Interestingly, the release notes refer to BlueSteel and LeTigre receiving server release 13.04.19.274370; however, the viewer reports both of the channels running 13.04.05.273550. I contacted Maestro on this, who replied, “There was an error during the roll, so a slightly older version (which doesn’t include the changes from this week’s main channel update) was deployed.”

Not too much is known about the new Experience Keys project, although the emphasis on “new” indicates this is more than just a deployment of the outstanding permissions system for the current advanced creation / experience tools, and speculation has been running high. At the Simulator User Group meeting on Tuesday 23rd April, Simon Linden indicated he was unsure as to what he could / could not say on the matter (particularly as it appeared the documentation was still being written-up).

Commenting on the Bluesteel / LeTigre deployment at the Server Beta meeting on Thursday 25th April, Maestro Linden was also somewhat circumspect on the matter, commenting, “The team doesn’t want to announce the features yet, so I can’t give many details … some other parts need to be released for the new features to be usable. So ideally, nothing visible should change there.”

The reference to “some other parts” which need to be released for these new features may include a viewer update. Whether such an update will appear ahead of or behind the materials capabilities (still currently in a project viewer) is unclear at this point in time.

Magnum

Magnum received additional LSL support for new HTTP contents types, as document in the release notes. It also received a change to how certain message types are handled by the server, which Maestro described thus:

There’s a change to make the server smarter about how it throttles certain messaging types to prevent certain types of ‘DoS’ attacks, where a ‘bad’ object could prevent your avatar from getting llDialog notifications from other objects. All objects owned by UserA share the same throttle for sending llDialog() messages to UserB, but objects owned by anybody else would have a separate throttle pool.

This should hopefully reduce the incidences of iiDialog being used in spamming attacks which can result in the viewer either being severely slowed down or crashing altogether.

SL Viewer

The beta viewer gained a further release (3.5.1.274558) which reached public availability on April 24th, containing further CHUI and SSB/A dixes and updates, as detailed in the release notes. The development viewer also received a further release (3.5.2.27469) which also gained public availability on April 24th.

Group Bans

Baker Linden: Group Ban work coming, just not quite yet
Baker Linden: Group Ban work coming, just not quite yet

Baker Linden has started working on an update to the code for managing groups which will allow group owners / moderators to ban users who create problems (e.g. those who spam groups, people who are persistently abusive in group chat, etc.). This work is in response to JIRA VWR-29337. In my last report on this, Baker has written-up the documentation for the work and was having some other Lindens cast an eye over it.

Attending the Server Beta meeting on Thursday April 25th, Baker provided an update on his activities. “I’m still working on group bans, but I decided to fix a couple small bugs first. They both relate to searching people using the choose resident floater. They’re in the system where I’ll be adding group ban stuff, and now that I can test the changes, I can get them pushed to an RC. However, he did go on to say, “It’s going to be a while before Group ban stuff is ready.”

Second Life and Oculus Rift

There has been considerable interest in the Oculus Rift headset and its potential for use within Second Life, as reported back in week 14 and more recently. Jon Brouchoud in particular blogged on why SL would be a “killer app” for the headset, and a video I featured back in week 16 has also appeared on numerous SL blogs (hardly surprising, given it has pretty much gone viral where the Oculus Rift is concerned 🙂 ).

On Wednesday April 24th, Hamlet Au covered the fact that the Lab is already looking to integrate the headset into Second Life, and have given official confirmation, with company spokesman Peter Gray (Pete Linden) quoted as saying, “We plan to strongly support Oculus Rift. That means code, client, and server-side, to make the Oculus Rift experience excellent in Second Life.”

Continue reading “SL projects report week 17 (3): server, group bans and Oculus Rift” →

SL project updates week 15 (2): Materials, AO capabilities and group bans

Posted on by Inara Pey

Server Deployments Week 15

  • As reported in the first part of this week’s update, there was no Main channel deployment on Tuesday April 9th, the result of issues arising with the previous week’s RC deployments, which LL wanted to fix rather than having them propagate across the grid
  • Magnum retained the same package as week 14 (Monty Linden’s next batch of HTTP updates) and a fix for a crash mode
  • Continuing issues in getting the anticipated updates for the BlueSteel and LeTigre deployment packages ready meant that on Wednesdays April 10th meant that these two channels received the same package as the Magnum RC channel.

The switch-out with the Magnum code being deployed to BlueSteel and LeTigre meant that those regions “lost” the new LSL Animation Override capabilities – existing scripts using the capabilities will still run, but new scripts using the functions cannot be compiled.

Materials Processing

Viewer Update and Documentation

Discussing the materials project at the Open-source Development meeting on Wednesday, April 10th, Oz Linden indicated that an updated version of the project viewer should be available shortly – possibly by the end of the week, as  “lots of fixes are accumulating”. In the meantime, a mixture of Linden Moles and volunteer users are working on materials-focused updates to go into the Good Building Practices guide to help other users get to grips with materials processing and optimising things for SL use. In the meantime, the Materials Data information on the SL wiki continues to be updated.

As pointed out by Mona Eberhardt in the comments relating to materials in this blog, Laverne Donat has produced a very tidy and short demonstration of materials in SL, which I’m including here.

Alphas, Transparency and Costs

Laverne also asked, via Plurk, if and how a specular map can have transparency with the materials processing, before going on to comment (via my blog) that, “After some testing, it seems that you can get specularity with diffuse maps with alpha masking, but not with diffuse maps with alpha blending. I don’t know what the intended behaviour is, but that’s how it works at present.”

This prompted Geenz Spad to reply, “The intended behavior (eventually) is that alpha blended objects will be able to support both normal mapping and specular mapping. Currently this is a work in progress, and due to its current state, it hasn’t been added to the viewer just yet.”

As Alpha Blending is currently the Alpha Mode which is unaffected by the materials / LI accounting situation which has been reported by Qie Niangao, I asked Geenz if Alpha Blending was liable to “trip over” into the LI accounting system, rather than being “grandfathered” (as currently appears to be the case). He further clarified the situation by replying, “Only if you use other material parameters (such as specular mapping, normal mapping, etc.). The only reason why we didn’t add support for shiny on all semi-transparent surfaces, is because it would break content.”

Future Development

In terms of future development, it is unlikely that anything will be happening soon, other than enhancements / fixes for what is currently in the project viewer. While there is a roadmap for future features and additions to the materials system, the Lab is wisely not commenting on plans and direction at this time. Rather, they prefer to see what the overall take-up with the new system is over time and how people start using it (which may in turn affect how and what the Lab decides to do with regards to a “materials round 2”). However, one thing which does appear to be clear is that there are no plans within the current roadmap to extend materials processing to include avatar skins and clothing layers.

AO Capabilities Update

New server-side AO capabilities: udpates delayed until week 16
New server-side AO capabilities: updates delayed until week 16

Although it did not get deployed in week 15 (but should see the light of day in week 16, commencing Monday, April 15th), the update to the new AO capabilities which should have reached BlueSteel and LeTigre is intended improve compatibility between the new animation override system and other scripted objects that animate avatars (such as poseballs). The update was developed as a result of Code Violet raising a JIRA (BUG-2164) pointing out that the new capabilities did not “play nicely” with things like sit animations in poseballs / furniture.

Maestro Linden, speaking at the Best Server meeting on Thursday, April 11th, described the situation thus:

If a user had a custom ‘sit’ animation set, the seat wouldn’t be able to stop the animation properly because if the seat called llGetAnimationOverride(“Sitting”), it would get an empty string unless the exact animation also happened to be in the seat’s inventory. Kelly has a nice solution to this problem, which is to make ‘llStopAnimation(“sit”)’ stop your custom animation, if you had overridden your sit animation. Conveniently, this change means that existing poseballs won’t need any updates to play nicely with the new AO system.

The Beta Server meeting saw some discussion on the new AO capabilities, which enabled Maestro and Kelly Linden to offer further clarifications.

Continue reading “SL project updates week 15 (2): Materials, AO capabilities and group bans” →

SL projects update week 13 (1): server, AO capabilities, HTTP, group ban list

Posted on by Inara Pey

Server Deployments – week 13

On Tuesday March 26th, the SLS (Main) channel received the maintenance package previously deployed to BlueSteel and LeTigre in week 12, which includes a fix for a crash mode  – release notes.

Some issues have been reported on following the Main channel deployment. Regions have been slow to come back up, and several which have had issues with groups and display names failing to show, teleport errors, etc. However, at the current moment in time, these issues do not appear to be widespread.

On Wednesday March 27th, the RC channels should receive the following deployment packages:

  • BlueSteel and LeTigre: a new maintenance package, which includes:
  • Magnum: should receive the same update as the Main channel (i.e. the package deployed in week 12 to BlueSteeel and LeTigre), otherwise retaining the updates and fixes deployed to it in week 12 – release notes.

As usual, there is a forum discussion thread for comments / feedback on the deployments.

That the region crossing fix for BUG-1814 is not been deployed to the rest of the grid in week 13 is liable to cause some consternation.

New AO Capabilities

The new AO capabilities, due for deployment on BlueSteel and Magnum. I provided an overview for the new capabilities in week 12, and the Lab have now provided a set of wiki pages on the calls and permissions:

Ban List – and More

As recently reported, Baker Linden has started working on an update to the code for managing groups which will allow group owners / moderators to ban users who create problems (e.g. those who spam groups, people who are persistently abusive in group chat, etc.).

The work is being undertaken in response to JIRA VWR-29337, and is likely to prove very popular once available.Currently, Baker is working on the development documentation and plan for the work, and has been giving further thought on what the capability will be able to do. Speaking at the TPV Developer meeting on March 22nd, he gave a little more insight into how the capability might progress:

  • A possible format for how the Group Ban option might appear in the viewer, as visualised by Alyssalillian McMinnar
    A possible format for how the Group Ban option might appear in the viewer, as visualised by Alyssalillian McMinnar. LL have an internal design for the UI elements, but this is not something Baker is currently focused on

    The initial release will at least allow group owners and moderators to ban people, a will display the names of banned individuals and the date on which they were banned (presumably to owners / moderators only)

  • It may include a capability to specify why a person has been banned, even if this is initially a case of selecting from a pre-defined list of reasons
  • A future option may be to include a time ban option (although this is potentially more useful in banning people from accessing a region / parcel)
  • An initial design for the viewer-side Group floater has been developed internally by LL, but Baker isn’t so concerned with how the options will be presented through the viewer until after he had defined how the code will work
  • Baker is not planning on adding any on the ban capabilities for group to the existing ban capabilities for regions / parcels, nor will any of the new group ban capabilities be shared with region / parcel ban capabilities, due to the complexities involved.

At the same time as working on the group ban list, Baker has also opted to correct other long-standing issues:

  • The ability to search for people using their user name properly (i.e. no period in between first and last names)
  • A fix for the disallowing of leading spaces on display names.

These fixes will also likely roll-out the same time as the first phase of the group ban list function, once Baker is able to start coding and testing the latter.

HTTP Project

On Friday March 22nd, Monty reported that the Aditi testing had been subject to a couple of non-related hiccups (due to inventory issues), but otherwise the regions were stable and whole one significant bug within the code had been found – severe enough to take down some Apache web servers when HTTP-In was being tested, and which has now hopefully been fixed.

Load testing on Aditi has been a little light, but obviously, more practical load testing will occur when the capabilities reach a Release Candidate channel and things start to get fine-tuned.

Mainland Griefing

The subject of Mainland griefing was discussed at the Simulator User Group meeting on the 26th March. There has been a noticeable rise in object griefing and spamming recently, particularly by the so-called “goonsquad”. Several options for better means of combating the problem were raised, including JIRA SCR-19 (“Script function to return objects”) for the return of griefer objects where users do not have access to estate / region tools for return objects, and possible throttling of llDialog (SVC-8080) to try to overcome the use of dialogue spamming prims.

The Lab will obviously not be drawn into discussions on their own plans for combating griefing, but Andrew Linden took a series of notes on problems which are being encountered, while Simon indicated that the Lab is looking at some options which may help with issues.

Related Links

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

Posted on by Inara Pey

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 Firestorm SSB pile-on / load test, March 15th
Peoiple gather for the Firestorm SSB pile-on / load test, March 15th

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:

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.

Continue reading “SL projects update week 12 (1): server releases, SSB and more” →

SL projects week 8 (3): Viewer, materials and SSB load test

Posted on by Inara Pey

SL Viewer Updates

Release and Beta Viewers

The release and beta version of the viewer are effectively on a par with one another at this point in time, following the roll-out of SL viewer 3.4.5.270263 on February 14th. There is currently nothing “in” beta at the moment in terms of specific SL projects.

Development Viewer and CHUI

The development viewer and the development version of the CHUI (Communications Hub User Interface) project viewer are also pretty much on a par, and it is anticipated that the CHUI code will be merged-up to viewer development “any minute now”, to use LL’s parlance, although a date has not been indicated. The viewer development code branch is pretty much waiting for this to happen, and CHUI remains in pole position as far as LL’s code merge plans are concerned, so potentially there could be more news on this in week 9.

Project Cocoa

Work is progressing on Project Cocoa within LL. This is a rarely talked-about project to update LL’s Mac support to the Mac OSX Cocoa API specifically for OSX 10.8 support, and remove dependencies on old Mac APIs which are not well-supported any more. The overall goal of this project, as commented on by Widely Linden is to, “Get people building cleanly with 10.8,” although OSX 10.6 will continue to be supported, although it will no longer be possible to build a Mac viewer using 10.6 once this project has been deployed. Widely also commented that there is a project viewer and source code for this work, which interested parties “should snag.”.

Vivox Update

Work is underway to update the SLvoice plugin to use the latest release of Vivox. This should bring with it a number of benefits including: security updates, stability improvements (although perhaps not improved connection reliability), better echo cancellation and – anecdotally, at least – better voice quality. There is no ETA on when this project will be deployed.

FMODex

Linden Lab continue to work on utilising FMODex as a replacement for FMOD.

Materials Project

There has been significant progress in fixing the known outstanding issues on the project which are standing in the way of a public project viewer and viewer code appearing. Speaking at the TPV Developer meeting on Friday 22nd February, Oz Linden said, “Our list of things which must be fixed before we can hand it out to people is now down to one.” However, there is still no estimated date as to when a project viewer and source code will actually appear Real Soon NowTM, which appears to put them both closer than Pretty SoonTM and Real SoonTM on the LL scale of things :).

Materials processing: with one remaining issue to fix, a project viewer now really should not be that far away. In the meantime the server code is fully deployed to the main grid
Materials processing: with one remaining issue to fix, a project viewer now really should not be that far away. In the meantime the server code is fully deployed to the main grid

As has been reported in my server-side news for the week, the server code for materials is deployed to the whole of the main grid, and so the system will be usable as soon as project viewer surfaces.

Server-side Baking

What is likely to be the first in a number of Server-side Baking load / pile-on tests took place on Thursday February 21st. Results were, at best, mixed, for a variety of reasons.

The test was held in the Sunshine project test regions on Aditi, immediately following the Server Beta User Group meeting. Those participating were asked to use the latest iteration of the official project viewer, which had been set-up for LL to do a certain amount of data logging. Anyone encountering issues was asked to raise a JIRA under the SUN project, listing issues encountered, with the viewer session log attached.

the test was in two parts:

  • Part one: performed on a region still running on a region using the current baking system, this saw people change between three of four outfits so that some baseline data could be obtained at the LL end of things. As this was using the current baking system, the usual baking issues were apparent
  • Part two: performed on a region running the new baking service, this again saw people changing between a number of outfits, this time monitoring and reporting on their own experiences.

Results were, it is fair to say, mixed. They were also not helped by the fact that Aditi itself has significant issues with inventory, etc., which made the test considerably more complicated than perhaps needed to be the case (for example, people were getting “object failed to rez”-style messages and other errors as items could not be fetched from inventory, etc.).

SSB load test: mixed results (image courtesy of Latif K
SSB load test: mixed results (image courtesy of Latif Khalifa

As an overall load test on the service itself, this should have generated some interesting numbers for LL with at least 40 people participating in the test at its peak. Commenting on the test on Friday 22nd February, Nyx Linden said, “A big thank you to everyone who participated in the pile-on yesterday. We got a lot of data out of it, [and] it looks like the majority of the issues were inventory-related, and we’re going to be digging into those. Anecdotal evidence suggests that when the system worked, it worked pretty darn well; but there were some people who had more trouble than others … We are looking into the remaining issues; we’re going to be fixing them as quickly as possible.”

While Nyx indicated that the majority of problems were inventory-related, he also stated that he and his team were still digging into the data to see if the problems were purely related to the known issues with Aditi’s inventory handling, or whether some of the issues are apparent in the inventory system itself, either on the server-side of things or within the viewer itself.

Continue reading “SL projects week 8 (3): Viewer, materials and SSB load test” →