Server Deployments week 44 – Recap
As always, please refer to the week’s forum deployment thread for the latest news and updates.
- The Main channel was updated on Tuesday November 5th with the same maintenance package previously deployed to the three release candidate channels, and which comprised bug fixes and crash mode fixes
- On Wednesday November 6th, all three release candidate channels were all due to receive a new maintenance package, comprising further infrastructure changes for the yet-to-be-announced Experience Keys (experience tools) project. However, an undisclosed test failure meant the deployment was cancelled.
Week 46 should see a new maintenance package in RC, which will include:
- A fix for BUG-4152 Sim crossing on vehicle fails when parcel at opposite sim border is full
- A number of crash fixes, including some which combat a physics griefer object
- The fix to allow objects rezzed by sat-upon objects should have a fresh auto-return and temp-on-rez timer, This will allow them to last the full ~60 seconds (for temporary) or parcel auto return time. This should help is situations where combat vehicles in regions with short auto-return times can have their ordnance immediately returned when a weapon is fired, and any temp vehicles are unable to rez attachments, even when sat upon.
- An interest list fix for issues where you don’t connect to regions far enough away when draw distance is set to 512m
A further update is a change to try to deal with a griefing situation wherein estate managers/owners can be added to a region’s the ban list or teleported them home with llTeleportAgentHome(). This is apparently achieved through the use of what Maestro Linden refers to as “Trojan” objects, in that the object appears perfectly innocuous until passed to the an estate manager / owner but which, when rezzed, will the manipulate the ban list via llManageEstateAccess().
Maestro described these scenarios thus:”I could give you ‘cute kitty’ which you then rez on your parcel. But the script with the ‘purr’ function also has a ‘manipulate ban list’ function. Since you (the parcel owner) own the kitty, the script there can do the operation.”
It has also been noted that the use of such “Trojan” objects isn’t restricted to manipulating llManageEstateAccess(); they are also used to clear-down ban lists using llResetBandList(). In the case of llManageEstateAccess(), the function is being changed so that the owner is notified, and is given the option to allow the function to run in “stealth” mode.
The problem here is that by the time the notification is received, the Trojan script has done its job, so the solution is not ideal; the same would be true in the case of altering llResetBandList(). However, as Maestro put it, “But you’ll know exactly what it did in case you need to undo it.” A further concern in the case of llResetBandList() is that some estate owners use the function remotely to legitimately manage their ban lists, so if anything is done to alter its functionality, it might break existing content. This led to extensive debate within the Server Beta meeting as to how such matters could best be addressed – or even if they needed to be addressed beyond people taking the proper precautions when receiving scripted objects from untrusted sources.
Default Region Restart Sound
In part 1 of this report, I noted that a JIRA has been put forward (STORM-1980) to have a default region restart sound added to Second Life. This would be played automatically by the viewer on receipt of a region restart message, adding an additional warning of an approaching restart for those who may miss the pop-up notices, giving them time to take the appropriate action prior to logging-out.
The work is progressing on this idea, although a suitable sound has yet to be found, and precisely how the region restart messages will be redefined has yet to be entirely settled. Sound-wise, something is required that would universally recognised and which is preferably not language-dependent. One of the more popular ideas at the moment is to have a submarine dive / air-horn like sound (the “A-wooo-GAH!” beloved of films), although there have been some muted concerns about people possibly being offended by the use of “military” sounds. Torley Linden also joined the discussion and, in fun, offered up his own idea – just make sure you don’t have the volume up too loud before playing the clip!
Torley’s region restart warning
Sadly, it doesn’t meet that criteria of being language-independent, but it’s still fun to listen to.
Script Syntax Updates and Increasing Source Text Allowance
In week 39, I reported that Ima Mechanic and Oz Linden are working to improve syntax highlighting in the viewer’s LSL editor by allowing the viewer to obtain the information required for syntax highlighting directly from the simulator the viewer is connected to. This should eliminate issues of the current, manually updated, files used to manage syntax highlighting falling out-of-synch with new LSL syntax as new functions and parameters, etc., are added.
This work is progressing well, and may now additionally see the source code text allowance in the viewer’s LSL editor increased. Currently, the source code limit in the editor is some 65,000 characters, however a number of scripters having been finding that they frequently are coming up against that limit when writing the source code for their scripts, so it has been suggested the limit be raised to 256,000 characters.
Originally, the idea was for this work to be perhaps carried out as its own code contribution to the SL viewer, but Oz Linden has suggested that it is folded-into the work Ima is currently doing, given he is already modifying the editor’s code. If this happens, it will remove the need for two separate updates to the LSL editor and also save on QA effort, as both could be reviewed / tested at the same time.
Baker Linden is continuing to work on the new capability to ban people from groups with open enrolment.
Commenting on progress at the Server Beta meeting on Thursday November 7th, Baker said, “I fixed a few big issues on server-side code, but other than that, We’re still going through and I’m getting the last of the server side fixes done so we can deploy to Aditi.”
One of the fixes he’s implemented is to prevent anyone in the group owner role from being accidentally banned from the group.
There have again been calls to add LSL support, but Baker is sticking to his development plan and not providing such support in the initial release. As he explained at the Server Beta meeting, ” I know script support would be greatly appreciated, but I’m not going to add it in now. I have to figure out the logistics first.”
Due to the way in which the group eject function works, there is an issue around banning and ejecting a troublemaker from a group. Essentially, only group owners can automatically eject anyone (other than anyone owner) from a group at any time. Other roles assigned the eject ability can only do so automatically if the person they are trying to eject is a member of the everyone role; if they are not, they must be manually removed from any other roles assigned to them first. This two-step approach has always been intentional to prevent any misuse of the eject capability (e.g. a non-group owner “rage ejecting” all other members of a group).
Unfortunately, it also means that banning group members by roles other than the group owner role could be limited in effectiveness in that it might result in a banned individual being added to the ban list but not actually being ejected from the group. Just how likely this is to be the case is open to question and subject to the way people organise their groups (do they allow roles outside of owner to eject others, for example). However, as it is a possibility, Baker is considering adding a notification which would indicate someone has been added to the ban list but not actually ejected from the group.