Server Deployments, Week 23
- There was no SLS Main channel roll out this week
- On Wednesday June 5th, the Release Candidate channel received the following packages:
- BlueSteel and LeTigre were updated with a new server maintenance project. This project addresses a disconnection issue and also fixes a crash mode – see my notes from week 22, and a fix for a crash mode
- Magnum remained on the same interest list improvement project as originally deployed to LeTigre in week 21, and to Magnum and BlueSteel in week 22, with some updates. Two of these fix what Andrew Linden describes as “two rare crash modes”. The package should also include the same disconnection issue fix.
Interestingly, the “large” scripts issue I reported on in part 1 of this update was given as the reason why there was not Main channel deployment this week. As previously reported, the fix for this issue, which prevents the text of previously saved scripts from being displayed in the script editor for users on slow connections, failed to make the cut for the week 23 deployments.
There are continuing reports of “invisible avatars” on Magnum regions. This issues was first reported following the week 22 deployments, and described as “on an in-region teleport when landing all surrounding avatars de-rezz and cannot be seen until the person re-logs. Everything else appears normally.” The problem appears to be random in nature, and was also noticed at one club which enjoys a high level of attendance. and which still appears to be encountering the same issue. During the Beta Server meeting on Thursday June 6th, this issue was discussed, and appeared to be most strongly linked to v1-based viewers.
SL Viewer News
The next release of the materials beta viewer arrived on Wednesday June 5th (126.96.36.1996961 with the release notes here), and as I indicated in part one of this report, sees the beta once more installed into the “correct” folder (SecondLifeBetaViewer). This means the initial beta release needs to be uninstalled separately, as the updated version obviously won’t over-write it.
In terms of beta releases in the future, it’s worthwhile again pointing-out that once the new viewer release process comes into effect, beta viewers will be installed into folders identified by their project name (e.g. something akin to “SecondLifeBetaMaterials”). Viewers should be fairly well self-contained (although they may still share the same default settings location, as that remains to be seen once things start rolling), so the uninstalling of individual beta versions (or RC versions) shouldn’t be a problem once they reach release status.
Work continues in preparing the new viewer release process for … release (or implementation). It’s still unclear whether it will arrive before or after materials moves to the release viewer. As reported in week 22, the current pipeline of releases we should be seeing as the new release process rolls forward includes:
- A collection of open-source contributions to the viewer which is hoped will appear as a release candidate viewer pretty quickly
- A “pretty substantial batch” of maintenance fixes for the viewer
- Vivox updates, which Oz described as, “Finally getting attention again, and will probably be in a release candidate version ‘real soon’ now”
- An Experience Tools viewer which is also expected to appear “real soon”
- An interest list update viewer, which is believed to be getting closer to being stable
Server-side Baking / Appearance
Investigations have been continuing into the SUN-74 issue which affects non-SSB/A updated viewers (notably Phoenix), with Nyx Linden commenting at the Server Beta meeting that, “Thanks to the support from the phoenix/firestorm team, we’ve been able to identify the cause of that issue. We’re looking into what options are available to us. [It] took some backflips to get it in a debugging environment, but managed to hunt it down – a combination of factors from not having the last 4 years of appearance fixes :)”
When asked about further public deployment of the SSB/A code server-side, given the status of work on SUN-74, Nyx replied, “We’re still evaluating what impact it will have and what options there are to mitigate that. We haven’t announced a timeframe for taking SSA to a release channel.”
Kelly Linden announced he’s working on two new LSL functions which are liable to please a lot of people. Speaking at the Server Beta meeting on June 6th, he said, “I have a couple of LSL functions coming in an upcoming maintenance release: llReturnObjectsByOwner and llReturnObjectsByID.”
The functions will only work on objects in the same region/parcel as the object containing the script using them.
When asked about the restrictions the new functions are liable to have, he responded:
A great many. I’m making sure I get correct data. They are restricted to operating on objects within the same region; they require a runtime permission (PERMISSION_RETURN_OBJECTS). This permission is *special* and the permission can be asked of and granted by group owners to operate on group owned land. They will return the number of objects returned OR an error code [and] there is a throttle at the number of objects allowed in your parcel pool per hour. If your parcel has a limit of 2000 [prim count / capacity] you can return 2000 objects per hour.
llReturnObjectsByOwner can not return objects owned by the parcel owner or estate managers [but] will return all objects owned by the ID specified – for example maestro could return all objects that I owned on his parcels with 1 call. [So] ByOwner specifies an owner to return ALL their objects in the region and ByID takes a list of object IDs to return.
- The functions work if and only if the user would have permission to return the object via the viewer, and it does not handle encroachment
- In order to work on group-owned land the object containing the script using the functions must be deeded to the group by the group owner
- The functions are restricted in the number of objects they can return because the Lab is concerned about accidental (or intentional) rez/return wars across parcel boundaries.
It is important to note that this capabilities are not seen by the Lab as a tool for dealing with persistent / repeated griefing, but rather as a means for estate / parcel holders with a convenient means of returning “forgotten” or unwanted objects quickly and easily (e.g. in the case where a tenant moves out, but managed to leave behind a number of objects scattered across a parcel’s volume.
Commenting on the functions and griefing, Kelly added,
It is not the best solution for griefing and is not intended to be. These throttles and limits are not final and are subject to being even more strict. I’m not concerned for the griefer’s inventory, I’m concerned about the health of the asset system and YOUR ability to continue to rez things. Without good limits the new grief mode is “oh hey! I can bring down the entire asset server with a couple of scripts.
Currently, there is no time-frame as to when the new capabilities will be released, other than “some time in the future”. However, testing on Aditi is apparently nearing completion, and a functional specification will be made available when the capabilities move to a Release Candidate on Agni.