Server Deployments Week 32
As always, please refer to the week’s forum deployment thread for news, updates and feedback.
Second Life Server (SLS Main) Channel
There was no update to the Main channel on Tuesday August 6th. This is primarily because the SSA project is not being further deployed during week 32, and BlueSteel was not updated in week 31 (other than to be brought up to a par with the Main channel), so there is nothing from the RC channels to promote to the Main channel.
Release Candidate Channels – Wednesday August 7th
Bluesteel should receive a new server maintenance package comprising:
- A new feature which will see regions block rezzing and entering during the final 60-seconds before a shutdown / restart (see notes below)
- Code to help fix an exploit whereby a scripted object can surreptitiously obtain permissions from an unsuspecting avatar, allowing the object owner to later use the object against the avatar in s griefing attack (e.g. by tracking camera movements in a deform attack, and so on – see publicly viewable JIRA VWR-13228 and the notes below)
- A fix 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)
- Fixes for further simulator crash modes.
Region Restart Blocks
Referring to the new feature allowing regions to block rezzing and entering during the last 60 seconds before a restart at the Simulator User Group meeting on Tuesday August 6th, Simon Linden said, “this is just trying to stop adding stuff to the region’s workload when it shuts down. Let’s say you TP into a region in the last second before it shuts down … you’re still going to be loading when it boots you out [and changes made to attachments could be lost after the resultant relog]. [It’s] the same possibly with rezzing an expensive no-copy item … it’s just not a good idea to start a complicated process right before shutdown. So those last 60 seconds are going to block entering and rezzing.”
In addition to the new blocks, Simon has also added the region name to the pop-up warnings which are displayed during the 5-minute countdown to a restart shutdown / restart.
The fix for scripted objects surreptitiously obtaining permissions from an unsuspecting avatar (per JIRA VWR-13228) will require a viewer-side update as well to be effective, which will utilise the Stop Animating Me function in the viewer.
Currently, Stop Animating Me is purely viewer-side. When activated, it will stop all animations running on your avatar within your view, with an update (ANIM_REQUEST_STOP) sent to the simulator which gets relayed to everyone in the same sim to tell their viewers to also stop animating you. The system isn’t perfect, but generally works. However, it is important to note that no actual permissions are revoked by the process, allowing griefing objects such as Soul Seize to retain control over an avatar.
Under the new system, and once the viewer-side update is available in viewers, Stop Animating Me will send a message to the simulator so it revokes all animation permissions for all objects in the region (other than those worn by the avatar issuing the command, such as AO HUDs, etc.), with the result that they are no longer animating the avatar (legitimate objects can re-animate via an explicit request, as per normal). While there were concerns expressed at the Simulator User Group meeting that a griefer may be able to work around the approach (although most workarounds appear to be somewhat labour-intensive), the new capability should be enough to stop griefing objects such as Soul Seize within a region from retaining control of an avatar.
Commenting on the viewer side of the fix, Simon Linden indicated that the viewer with the change is undergoing QA testing, but because of the number of updates it contains, it is unclear as to when it will make a public appearance.
SL Viewer Updates
The Vivox release candidate viewer was promoted to the de facto release viewer (version number 22.214.171.1249258) on Monday August 5th, which can be obtained via the main viewer download page or will be offered as an automatic update to those using the previous release and who have updates enabled. The release notes summarise changes.
As a result of this, the Google Breakpad release candidate updated to version 126.96.36.1999364, on August 5th (download / release notes) and the Maintenance Viewer RC updated to 188.8.131.529427 on August 6 (download & release notes).
In the meantime, the Cocoa viewer updates (Mac only) moved from a project viewer to a release candidate (184.108.40.2068960, download & release notes) on August 6th, bringing the number of active RCs back up to five.
The latest CHUI updates (now in release candidate 220.127.116.119321, released on August 1st) still contain the issue of highlighted text in scripts / notecards being deleted if somewhere else in the script editor / notecard is clicked, requiring a CTRL-Z to undo (see publicly viewable CHUIBUG-210 and the associated forum thread).
As a small aside, apparently the (or perhaps only one of the) meeting(s) to decide on the status of the current viewers and determine which (if any) is ready to go to release status is held around late morning SLT on Mondays.
Group Ban List
There has been some confusion over the group ban function, which lead Baker Linden to clarify that anyone banned from a group under the new capability will be automatically ejected as well (hence the ban), and will not be able to re-join the group until such time as the ban is lifted. Group owners will automatically be blocked from the ban function, to prevent them being accidentally banned by other group officers.
Baker has been considering who can actually be banned by a group member granted the ability to ban others.
His initial idea is to allow anyone given the authority to ban group members to be able to ban anyone else (other than the group owners), so one officer with the ability to ban people could ban another officer, for example. “My reasoning is that if you can’t trust an officer with banning, don’t let that person be an officer,” he explained.
Descibing the other option he was considering, he said, “The other route I can go is anyone with the ban ability can [only] ban anyone that doesn’t have that ability.”
This second option appeared to gain more support than the first, although Baker himself sees it as somewhat limiting, “But I don’t see the point in that,” he said, “Since we already have a problem with eject not being able to eject anyone belonging to any role other than ‘Everyone’ which seems pointless to me.”
Unfortunately, the meeting drew to a close before both options could be further explored, and so they may be a topic for further discussions at the next meeting. However, the idea of those with the ban ability only being able to ban those who don’t have the ability doesn’t actually seem to be as limiting as Baker suggests when citing the issue with group ejections (only those in the “Everyone” group can be ejected), so it will be interesting to see how much more discussion there is on this subject.
Andrew Linden: Interest List Work and Anti-Griefing Measures
Andrew Linden reports he has now all but finished his current work on interest list updates. While there is still no indication when the viewer-side changes might surface, he’s nevertheless freeing himself up to take a look at anti-Griefing measures. He’s already compiling a list of items he wants to look into, although his initial focus will be on general maintenance work to get him, as he puts it, “back in the groove”. One item in particular he’ll be looking at prior to delving more into anti-griefing measures is that of motion stops on region restarts.