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

Published by Inara Pey

Eclectic virtual world blogger with a focus on Second Life, VR, virtual environments and technology.

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

    1. And Easter/Passover at the weekend. I’ve no idea what that means for roll-outs next week.
      The reported problems are also consistent with network issues, and I have seen other signs of a poor connection.

      Like

      1. While we will know more on Thursday, it is possible deployments will be pushed back a day as they were for President’s Day – although we obviously have Good Friday to contend with this week as well, which shortens the time period in which to double-check things and prep a package for wider deployment in week 14.

        Like

  3. Am I the only one feeling a bit wearied by the apparent Linden-driven new shiny, and so little apparent action on bugs? Or even things that paying customers have been waiting for since way back?

    Like

    1. In fairness, LL are working on bugs and issues. The entire Shining Project is geared towards trying to fix long-standing issues (bake fail), improving stability and reliability (HTTP) and trying to refactor server (and eventually viewer?) code to further enhance the user experience (Interest List work). Granted, not all of this work is proceeding smoothly, but it is digging deeply into the server-side code and LL are responding to issues as and when they can repro them (as with BUG-1814). The last few server-side deployments have been about trying to stabilise that side of the platform and fix a range of bugs and issues. Now Baker Linden is taking on some long-standing JIRA requests and trying to sort them out…

      In the viewer, there’s been a lot of under-the-bonnet work carried out on the rendering system, more third-party contributions (in terms of both code and in terms of TPV devs providing direct assistance to LL) in order to improve the viewer (although admittedly, LL made things somewhat harder for TPVs to integrate code when they combined CHUI with a lot of additional viewer code refactoring).

      Where some of the problem comes from, I think, is that oftentimes, we don’t necessarily see the issues we want fixed appear to be receiving enough attention; BUG-1814 being a case in point. It took a while for LL to sucessfully repro the problem themselves, but as soon as they did, they pushed through a fix for the problem – but have now pushed that fix to one side for at least another week. That’s frustrating for a lot of us – me included.

      The other frustration, of course is that even when LL are working to fix X and / or Y, one or other seems to always have an unexpected impact on the other, or on Z. So whatever they do, it seems to be two steps forward, one step back (and occasionally two forward, two back). Whether this comes down to the natural churn of experience at LL as people join, work, leave, or whether it’s down to too few hands to juggle all the balls, I’ve no idea.

      Like

  4. If……LL is taking the road of creating a new, clean, reliable product, that will be accepted by the moral majority, or if Steam condition is to get ride off all signs of sexual activities that SL allows, then it makes perfect sense.
    Using SL users as testers until the new product is ready to go on the big market, abide by releases of products directed to pg areas, that would open the road for that “New” metaverse!
    If…
    I do believe that LL knows that adult activities are not only what SLis all about, but it helps a lot!
    Sex sells and was always the biggest pusher for improvements over the Years on internet!
    A clean, new SL, will be my choice if i was Ceo and had the budget to cover its development, even at the costs of what is giving the profits!

    Like

  5. Pingback: Cajsa Fast Five: March 27th | Its Only Fashion
  6. Pingback: Cajsa Fast Five: March 27th

    1. Baker is definitely the Most Loved Linden (TM) right now, with Monty Linden not far behind :).

      Like

  8. fells so frustrated to constate this evening 3/4 PM slt she can’t use her EG DH88 due to not deploy(i thinks partial) of the 1814 bug fix 😦 no problem with her Prefabrica slow aircraft snif;)

    Like

Comments are closed.