Server Deployments – Week 26
As always, please refer to the week’s forum deployment thread for news, updates and feedback.
Second Life Server (Main) Channel
On Tuesday 25th June, the SLS Main channel received the server maintenance package deployed to the three RC channel in week 25. This fixes a number of crash modes, addresses an issue with neighbouring region visibility, and adds new LSL capabilities:
- The new pathfinding property CHARACTER_STAY_WITHIN_PARCEL, which can be used with llCreateCharacter() and llUpdateCharacter(), and is intended to help with keeping characters within parcel boundaries – see my week 19 report for details
- The new object return functions I reported on in week 23, namely llReturnObjectsByOwner and llReturnObjectsByID, are intended to provide an automated means of returning objects to their owners – see my full update on these functions for details.
This package also includes the following:
- An update to llReturnObjectsByID() to prevent it from returning other objects which are owned by the parcel owner or estate owner/manager
- A fix for an issue in which LSL HTTP-in scripts would sometimes see the incorrect URL (BUG-2833)
- A fix for Bug 2850 (Cannot rez objects in Bluesteel and LeTigre parcels which disallow object entry) – which caused this deployment to be replaced by the Magnum RC package in week 24.
The neighbouring region visibility issue referred to in the package is for SVC-8019, which is related to issues with regions failing to communicate with their neighbours for up to an hour are a restart, causing communications issues (e.g. LSL chat) across region borders. It is not intended to address the issue of diagonally adjacent regions not being visible to one another (SVC-8130).
Release Candidate (RC) Channels
- A fix for ‘llApplyImpulse now works only in the root prim’ (SVC-8227)
- Crash mode fixes
- New LSL function: string llXorBase64(string str1, string str2)
- Added max_materials_per_transaction to /simulator/features cap
- This number returns the maximum number of materials that can be sent to the “RenderMaterials” capability in a single request.
With the release process yet to switch-over to the new system, the following viewer updates were made in week 25:
- The SL beta viewer saw an additional release – 220.127.116.117611 on June 21st. This primarily included some fixes for the version of the viewer which is offered via Amazon for download, and rendering fixes
- The Snowstorm Contributions Test Build viewer was updated to the 3.6.1 code base (version 3.6.1277577, June 20th, for details of the current contributions in the viewer, follow the link). This would appear to be the first step in merging-up a series of third-party viewer contributions which are liable to see a project / beta viewer release after the new viewer release process comes into use.
Viewer Release Process
Commenting on progress with the upcoming new viewer release process at the Open-source Dev meeting on Monday 24th June, Oz Linden said, “We’re in the final verification stages. Might even get it turned on this week.”
As a side note, and In preparation for the new process, I’ve revamped my Viewer round-up page to (hopefully) better reflect the fact that we should be seeing a broader spread of viewers being put out by LL. This is a work-in-progress, and the page may evolve further as the new viewer release mechanism comes into force. Similarly, the weekly summaries produced from this page are also being revised ready for the new release process.
Despite issue with the materials viewer, there are a number of content creators already working on products which leverage the new capabilities. At the Open-source Dev meeting on Monday 24th June, Whirly Fizzle pointed people towards the work of Chip Midnight, who has been working on a mesh avatar using materials properties.
Whilry also supplied a link to a thread on the SL Universe forums where Chip discusses the avatar. For those interested, it’s worth following the discussion for the next couple of pages – particularly Drongle McMahon’s reply to Chip on the subject of specular and gloss maps.
Group Ban List – Baker Linden
Baker Linden has at last started on the group ban list work in relation to JIRA VWR-29337. As he was the only Linden able to attend the Simulator User Group meeting on Tuesday 25th June (Andrew Linden being on holiday and Simon and Kelly being at a lunch hosted by the Lab’s VP of Technology), he came in for a lot of questions on the capability.
The following is a concatenation of his opening comment and initial responses to questions:
So the group ban stuff is coming along slowly — I’m currently refactoring existing code so that I can better implement group related functionality … A group ban list will be capped at 500 ban entries per group — this is the standard for parcel bans, etc. Some groups will pass that limit, [so] I’ll be including dates of when you banned residents, so you can always delete oldest ones first if need be. The entries in the list will be agent UUIDs. If the agent tries to join again, it’ll check that list and see if they are on that list — if so, they can’t rejoin.
Baker also clarified that the new capability will not initially support time-based banning of people from groups, although he added:
I have toyed with the idea of time-based bans — I’m designing the system so that could be added if necessary, but I think the group ban lists would be filled much faster if it were used for a “bad resident — time out for you!” list — The idea of the group ban system would be for suppressing really obnoxious griefers.
As the ban list will be capped at around 500, Baker is currently looking at what will happen when the limit is reached, “I have a couple [of] options — return an error saying the list is full (which will probably be in v1), or remove the oldest entry from the list (which I admit is dangerous — I don’t like the idea of manipulating your ban list).”
With regards to the latter point, a suggestion was made that a prompt could be added so that the group moderator is informed that the ban list is full, and then has the option to allow the system to remove the oldest entry from the list.
A number of other suggestions were also made about the capability, all of which Baker responded to positively. However, whether any / some of them appear in the initial release of the group ban function remains to be seen – a lot will depend on how well suggestions fit with the work Baker already has in hand, and how practicable they are.
Server-side Baking / Appearance
As noted in week 25, the preliminary date for the start of SSB/A deployment has been set at the 9th July 2013. The announcement came via a note card circulated in-world on Nyx Linden’s behalf to various groups such a viewer support groups, in-world builder’s groups, etc., which read in part:
We have a number of QA passes and tests to run through before we can get the final greenlight to do so, so we are currently targeting July 9th as the earliest date at which we will enable SSA for a significant portion of the grid (a server RC channel). Please note that if we find additional bugs in the meantime, or run into other scheduling difficulties this date could be pushed back. We will not be going to RC before this date however.
Please consider this an official warning that this is imminent – We’ve been saying for a while that we’re getting ready for release. We hope with a solid date in mind, all viewers can start messaging to their users that they will need to update or they will start to see issues. There are a few methods by which we will be messaging to the SL community as a whole about this, but we highly encourage you to use your judgement in the best way to reach out to your users and transition them to SSA-compatible viewers.
There will likely be a further SSB/A pile-on test on the main grid at some point this week, although it will be more restricted in numbers than the last test in order to try to avoid some of the asset / inventory issues which occurred in the last test (and which are unrelated to SSB/A). When I asked Nyx about the pile-on test held in week 25, he replied, “[We’re] still digging through logs, but does not appear to be anything critical/release-blocking.”
Those wishing to participate in the upcoming pile-on test should contact Nyx via e-mail. However, numbers will be limited, as noted above.