Server Deployments week 50
As always, please refer to the week’s forum deployment thread for the latest news and updates.
Second Life Server (main channel) – Tuesday December 10th, 2013
The main channel was updates with the server maintenance project that was on the RC channels in week 49. This project includes a few miscellaneous bug fixes. These include a fix for BUG-4431, which Maestro Linden, speaking at the Server Beta meeting on Thursday December 5th, described as:
A fix for avatars with crouch / crouchwalk animation overrides. Previously, the llGetAgentInfo() LSL function would only return AGENT_CROUCHING if the avatar was playing the default crouch or crouchwalk animations, so if your avatar had an AO which replaced those animations, (either with llSetAnimationOverride() or possibly with classic AOs too), scripts couldn’t tell when you’re crouching. But with the fix, the function is looking at whether you’re actually crouching, regardless of which animations are playing.
This should be the only “visible” fix within the package.
Second Life Release Candidate Channels – Wednesday December 11th, 2013
All three RC channels should receive a new server maintenance project containing a single bug fix related to vehicles becoming stuck in the ‘sat upon’ state (which prevents parcel auto return).
This issue is related to vehicles getting into a “bad” state if they lose the passenger right at region crossing. The vehicle is left with what is effectively a “ghost rider” sitting in it, which defeats parcel auto return, leaving the vehicle in-world.
The SL release viewer was updated on Tuesday December 10th to version 18.104.22.1684506, formerly the NameUpdater release candidate. This release does not contain any updates to the viewer’s functionality, but does change installer naming and fixes an updater issue.
Code Freeze / No Change Window
Week 50 marks the last week for deployments to release, main and RC channels by the Lab for both the viewer and the servers prior to the Christmas / New Year code freeze / no change window commencing on Monday December 16th. The no change window extends through until the start of January, and will see no significant releases (other than possible emergency updates, if they are required), although there may still be updates to project viewers.
The main reason for the no change window is to allow Linden staff, notably support personnel, have a decent break over the holiday period without the risk of having to deal with significant issues as a result of a change or update immediately prior to the actual holiday period. To ensure this is the case, the code freeze starts ahead of the actual holiday period so that the Lab can ensure those final releases for the year which are made are robust and stable and unlikely to give a major cause for concern while still having staff available to deal with matters should things get a little higgledy-piggledy*.
“Uniform Scaling” LSL Functions
Andrew Linden has been working on a set of “uniform scaling” LSL options which would allow an object / linsket to be rescaled via a single LSL call – such as uniformly increasing or decreasing its size by a factor of 2. The work is still experimental and won’t be deployed until 2014. However, commenting on the work at the Simulator User Group meeting on Tuesday December 10th, he said:
One problem with scaling by multiplicative factor is that the scale operation might fail for a number of reasons; there are four categories of failures: hit the “prim is too small” limit. (2) hit the “prim is too big” limit (3) violation of linkability rules for linked set (when making bigger) (4) misc failures because of navmesh or other things.
The current API includes three calls: (A) llGetMinScaleFactor(), (B) llGetMaxScaleFactor() ; (C) llScaleByFactor(float). I currently handle failures (1) through (3), and the llScaleByFactor() will return FALSE if it fails, but it won’t tell you why it failed. You can use llGetMaxScaleFactor() and friend to ask what the max/min multiplicative factors are possible for reasons (1) through (3). Needs some work, but it is in progress.
A further concern / failure point was raised at the meeting: rescaling an object containing mesh and hitting the land capacity for a region as a result of the LI value increasing. One suggestion for avoiding this would be to have a function which could determine how far an object can be scaled prior to hitting the capacity limit for a parcel (e.g. returns the potential LI for a given scale value before an object is rescaled; however how this might be accurately achieved is unclear, particularly as LI scaling with mesh objects can be subject to a range of factors.
It will be interesting to see how this progresses.
*For those unfamiliar with the term “higgledy-piggledy”, I offer the following explanation: