SL project updates: week 35 (1): server releases, group ban list, anti-griefing

Server Deployments Week 35

As always, please refer to the week’s forum deployment thread for news, updates and feedback.

Second Life Server (SLS Main) Channel – Tuesday August 27th

The Main channel received the update package which includes the “grey box” attachment fix, and which had seen previous deployment to some of the RCs. In all, the package comprises:

  • A fix for the “grey box attachment  issue” (non-public BUG-3547, see the details here)
  • An update to for “llListen in linked objects is listening at root instead of linked object local position *after re-rezzing the linkset*”,  (non-public JIRA BUG-3291)
  • Code to block avatars entering a region / objects being rezzed in a region during the last 60 seconds before a restart. In addition, restart warning pop-ups will include the region name
  • Fixes for further simulator crash modes.

Release Candidate Channels – Wednesday August 28th

All three RC channel should receive the same maintenance package comprising:

  • An update to region restarts initiated by region owners or estate managers which will see the region restart after the last avatar leaves, rather than waiting for the full countdown period to complete
  • Preparatory work to support new estate and parcel access controls – these will require a upcoming viewer-side update in order to be visible to users
  • A fix for a physics-related griefing mode
  • A crash mode fix.

The release notes are here: Magnum, LeTigre, BlueSteel.

Commenting on the upcoming estate and parcel access controls at the Simulator User Group meeting on Tuesday 27th August, Simon Linden said, “I can’t get into details on the access change but it’s not a huge one, so don’t get too excited about it. We hope to have a project viewer out in a few weeks or so that will have the new code and we can discuss it then.”

SL Viewer Updates

Release Viewer Updated

Following the Monday review meeting, CHUIStorm Release Candidate viewer was promoted to the de facto release viewer, dated August 20th) on the 26/27th August. This viewer includes the latest CHUI updates from the Lab and a number of Snowstorm code contributions from third-party developers, including:

  • STORM-1892 – Add Apply button to the edit content permission floater
  • STORM-1910 – Count of the number of groups a person has joined, and number of remaining group slots
  • STORM-1911 – Go-to line function for the internal LSL script editor
  • STORM-1918 – Part of the group notice attachment box does not allow dropping of assets
  • STORM-1952 – Clicking “Eject” needs a confirmation before execution when ejecting members from a group

The full list of updates are available in the release notes.

The move currently leaves two RC viewers in the release channel: the Cocoa updates for Mac builds, and the next round of updates for Materials Processing, which include goodies such as correct ALM rendering underwater.

Commenting on the removal of the Google Breakpad RC viewer from the list, Oz Linden confirmed that it had been removed as it had done its job, allowing the new reporting mechanism to be tested. As the viewer contains no user-facing changes or anything outside of the Breakpad updates, it has been withdrawn, and the new stats reporting code will be integrated into the viewer code base without requiring a dedicated release.

The mesh deformer project viewer has also been removed from the viewer test builds wiki page. There is not anything untoward about this; prior to the SSA deployment the viewer was already significantly behind the times in terms of merges. As SSA has now been deployed, and the view lacks SSA support, it is currently pointless having it as a publicly available download option.

Group Ban List

Baker Linden supplied a brief update to his work on creating a function to allow group owners to ban people (e.g. known troublemakers) from joining their open-enrollment groups. Speaking at the Simulator User Group meeting, he said:

I’ve still been hooking up the viewer to the server, and can now add people to the ban list. I’m currently working on getting the ban list, which will allow me to get deleting from the ban list working. After that, it’s code cleanup, reviews, and adding server-side verification checks!

To which Andrew Linden added, possibly wryly, “Baker banned me from some groups on the beta grid. I can attest that there is progress there”!

The question was again asked if the capability will allow for banning someone for a set period of time – such as for a week. Baker confirmed that while the ability to do so won’t be in the first release, there is a code stub included which will allow him to add the ability in the future. This is likely to be the case with the ability for a group moderator to add a reason for banning someone from the group if they so wish.


As he has now moved away from Interest List work for the time being, Andrew Linden is looking into griefing vectors and ways and means of circumventing them, particularly on mainland. Some of the areas he’s looking at and mulling over in terms of possible actions are:

Andrew Linden - now looking into anti-griefing options
Andrew Linden – now looking into anti-griefing options
  • Allowing estate owners to admin parcel properties (ban lists, object options, etc), without having to take ownership of the parcel
  • Altering the “allow public to build on this land” flag to default to FALSE rather than TRUE when a parcel transitions to a new owner – this is seen as a means of preventing griefers from buildings and hiding hide malicious objects in unattended parcels which can then be used to grief the region / people in the region.
  • Nerf the use of recursive rezzing to prevent griefers getting around autoreturn by creating an object which rezzes a copy of itself, then gives a copy to the rezzed object. The original is then autoreturned, but the copy carries on before creating a copy of itself, and so on.

Andrew is particularly concerned that the third proposal might be damaging to content which may legitimately self-replicate itself (such as items placed by the parcel owner or members of the group the land has been deeded to). In order to prevent this, he plans to apply the nerfing only to objects to which the auto return would otherwise apply.

At the moment these ideas are still musings – although Andrew admitted the code for nerfing recursive rezzing has already been written – and he’ll be having further discussions at the Lab as well as looking at various alternatives / additions (one he mentioned himself was to perhaps have two auto return functions – one for objects whose owners in the region, and one for those lacking owners).

One of the problems here is that in planning to create any additional restrictions on land use, etc., is that people can always raise apparently legitimate reasons why things shouldn’t be done, or offer up ways and means of how changes can be circumvented. However, the fact remains that griefing – particularly on mainland – is once again a growing issue (as those of us have experienced only too well at recent in-world LL meetings). Therefore, change is needed. The skill in the work will be how that change is managed.

4 thoughts on “SL project updates: week 35 (1): server releases, group ban list, anti-griefing

  1. In any change, there is always a legitimate use-case that can be harmed by the change. The question is whether or not the legitimate use-cases which benefit are both greater in number and degree of benefit, as well as the ‘fairness’ of harming the cases which are harmed (ie: majority wins is a good default position but can be a tool of oppression).

    Recursive self rezzing comes down to what? I had written a few paragraphs below about temp rezzers, but its not that. Those have object A, rezzing object B every “decay cycle – X” seconds so that a user never see the object gone.

    Ammo from weapons on a roleplay sim – not that either.

    This comes down to object A, rezzing itself. I’m sure legitimate use cases exist for this… But I’m not yet aware of any. Almost all of them are better handled by having object A, such as a breedable’s home stump, rezzing object B: a new nest or an updated breedable… or ab object A, a crate on a dock, rezzing object B: a public access boat. Or a bike rack rezzing a bicycle…

    – I’m sure almost every recursive rezzing case that is legit could be folded into a two stage rezz system instead with an object A rezzing B… thereby forcing the resident wishing to rez to have permission to set up object A and permission to rez at the target location of object B (such as when I recently set up a bike rack on my land and had to move it back a few meters because my guess on where the bikes would show up was wrong, and I lacked permission to start spamming bikes on the public road over the parcel line).

    I’d say its safe to just knock out recursive rezzing…

    And I think they need to adopt this philosophy going forward: don’t hold back when what you are holding back is too much of a gain and what is causing the hold back is too limited a valid case, or can be better done by other means.


    1. Yup.

      There was a fare degree of brainstorming on why recursive rezzing would have a genuine “legit” (as Andrew put it) use, and the opinion was pretty much “knock it on the head”. As indicated, Andrew has written the code, and has included a failsafe to disable it just in case there is an “oopsie” moment when his new safeguards start reaching the RCs.

      I think most people would be more in favour of the Lab taking firmer action with exploits which cannot be quietly closed (as a lot are with the server deployments), but it’s also good that Andrew is testing the water and putting ideas before those who often do face the sharp end of such issues.


  2. well, that three points might help some.
    Even if the 3rd (‘Nerf the use of recursive …’) will give some ppl directly headaches.
    The 1st(‘Allowing estate owners …’) looks to me like a straight ‘go for it’.

    But the 2nd (‘Altering the “allow public …’) really worries me.
    It is a massive culture change and i expect only a low impact on griefing.
    The 2nd one can be discussed endless and i would recommend doing anything else instead of starting this kind of drama.


Comments are closed.