SL project updates week 35 (2): parcel access controls & particle system

Server Deployments Week 35

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

• On Tuesday August 27th, the Main channel received the update package which includes the “grey box” attachment fix (issue details here), together with an update to for “llListen in linked objects is listening at root instead of linked object local position”; the new code to stop avatars entering a region / objects being rezzed in a region during the last 60 seconds before a restart, and additional fixes for simulator crash modes  (release notes)
• On Wednesday August 28th, all three RCs received the same update package, which has a fix for a simulator crash mode, a fix for a physics-related griefing mode, and which has a new capability so that region restarts initiated by region owners occur as soon as the last avatar has left the region. This package also includes server-side support for new parcel access controls (see below) – release notes: Magnum, LeTigre, BlueSteel.

Region Shutdown / Restart

In reference to the new capability rolled to the RC channels whereby region restarts initiated by a region owner occur as soon as the last avatar leaves the region (rather than waiting for the time delay to expire), Maestro Linden indicated that the capability will eventually be extended to automated rolling restarts as well.

New Parcel Access Controls

Maestro Linden likes to work-out during meetings

The original post for the RC server package made reference to “estate and parcel access controls”. However, this was an error on Maestro’s part, and he sought to clarify things in a couple of follow-up posts, in which he first made it clear the new controls only apply to parcels, not regions (hence the emphasis above), and then went on to say:

The new feature is to allow a parcel to be configured to allow users to enter a parcel if they are members of the parcel’s group *or* have payment info on file.  This is meant to be a big help toward keeping griefers out, as they often will not add Payment information to their account and group limitations are often managed by the land manager.

This access configuration, which is already available at the estate level, involves enabling 3 options in ‘About Land’->’Access’:

• Allow public access
• Allow access only to Residents who: Have payment information on file
• Allow Group Access: <group>

With the current release viewer (3.6.4 (280048)), this combination of settings is not possible to set in ‘About Land’; enabling ‘Allow public access’ causes ‘Allow group access’ to become disabled.  The upcoming viewer change will make these two settings independent in the UI.

He further explained:

The change is to allow group-based white listing which can parcel restriction based on payment info.  Here’s how the logic plays out:

1. “Allow public access” means that avatars/groups do not need to be explicitly white listed to visit your parcel.
2. The “Allow access only to Residents who: Have payment info on file” option is only available when (1) is set (this is also the classic behaviour). 
3. The “Allow group access: <group name>” setting additionally allows group members to access your parcel, except for those on the ban list.

With only (1) and (2) set, only those with payment info on file can visit your parcel; there is no way to allow your friend/alt who doesn’t have payment info on file to access the parcel.

With (1), (2), and (3) set, you allow two sets of people in:

• ‘trusted’ accounts, who belong to the parcel’s group
• any account with ‘payment info on file’ (these users probably aren’t zero-day griefer accounts)

The viewer-side updates required to use these options are currently a work-in-progress. There is an internal viewer available within the Lab which is being used for testing purposes, and it is hoped that the necessary updates will be appearing in a beta or release candidate viewer in the near future.

Particle System

The viewer-side updates required to support the “new” LSL particle system capabilities (accessed via llParticleSystem()) are apparently contained within the same viewer as the UI updates for parcel access controls mentioned above, which means that these should also be appearing in the not-too-distant future.

The viewer supporting the LSL particle capabilities deployed server-side earlier in the year is making progress

HTTP Updates

Monty’s work on HTTP updates is apparently due to see server-side changes in week 36. These will pave the way for smarter asset fetching, as previously reported in these pages. He’s scheduled to give an update at the week 36 meetings, so there will be more details then.

Other Items

llXorBase64

This LSL function was deployed in week 28 to deal with issues related to llXorBase64StringsCorrect returning incorrect  results when the second string contains nulls (see SCR-35). Unfortunately, it has an off-by-one-character error when the 2nd string is repeated more than once, which may come into play in certain situations. A fix for this problem has already been developed, and is currently available for testing on the Aditi region of Chooqu. If all goes well, the fix should hopefully start to be deployed to the main grid in around two weeks.

Teleport Rather than Log-off

A question was asked at the Server Beta meeting on Thursday August 29th as to whether it would be possible to teleport avatars whose users are AFK to other regions, rather than logging them off.  Responding to the question, Maestro linden replied, “If we added a special LSL event for pending server shutdowns, you could potentially have a script that moves your avatar with llTeleportAgent.”

Obviously, in order to work, there would need to be some means of avoiding sending an avatar to another region already in the process of restarting, or one that is about to restart (during a rolling restart) – such as avoiding teleporting the avatar to another region on the same channel, etc.  Whether or not such a capability is developed in the future is open to question – as is whether or not the idea is thought through sufficiently well enough for a detailed feature request to be put forward.

Aditi Mesh Upload / IP Test Issue

There has been a report that issues are being encountered trying to access the Mesh IP test on Aditi. As most people know, this has to be completed if you wish to upload mesh content there, even if you’ve taken the test on Agni. The issue itself is the that test page is failing to open in browsers. If the above link fails to open the page (you may need to log-in first), file a WEB JIRA referencing BUG-1640.