SL projects Update week 51 (1): Group bans, viewer, misc news

As a reminder, there are no scheduled server-side deployments or restarts due to take place prior to Tuesday, January 7th, 2014.

Upcoming Server Deployments

Andrew Linden - departing LL
Andrew Linden – departing LL

Andrew Linden, in his last appearance at a User Group meeting – indeed, in possibly his last public appearance prior to his departure from Linden Lab – gave further information on the uniform scaling functions for objects and linksets he’s been working on.

In particular, he described a third function  – llScaleByFactor(float) – which sits alongside the two previously reported upon in part 3 of my week 50 report. So taken together, all three functions are:

  • integer llScaleByFactor(float factor):  uniformly scale a linkset by the specified factor (e.g. 2.0 to double the scale).  Returns TRUE if successful, FALSE otherwise
  • float llGetMaxScaleFactor(),   float llGetMinScaleFactor(): return the maximum / minimum scale factors that will work in llScaleByFactor due to limits in place by prim scale and linkability distance restrictions
  • llScaleByFactor(float) returns TRUE if the scale change succeeded.

The new functions do not require any viewer-side update, and have already been added to the server-side LSL syntax file, although they will not actually be deployed to the main grid in an RC release until 2014. In the meantime, those wishing to test the functions can do so on Aditi in the following regions: Balance, Boardman, Borrowdale, Hawkshead and Mayfair.

SL Viewer Updates

The Google Breakpad release candidate viewer won an exception to the code freeze which came into force on Monday December 16th, reappearing in the release candidate viewer channel as version 3.6.13.284710.

The build, dated December 13th, 2013, was allowed a free pass and added to the Alternate Viewer wiki page on Monday 16th December as it contains no actual functional changes to the viewer. Rather, it contains an update to Google Breakpad and restructures the crash reporting mechanism to support out of process crash reporting. The  changes are intended to give LL’s development team more call stacks from crashes more frequently in order to improve the triaging and debugging of crash-related issues.

Group Bans List

Obligatory Baker Linden shot :)
Obligatory Baker Linden shot 🙂

Baker Linden provided an update on his group ban list work. As per my week 46 report, he is going with the approach whereby granting a role within a group the ability to ban people from the group will automatically give that role both the “Eject Ban Members” AND “Remove Roles from Members” abilities as well.  However, it will not be possible to remove either the “eject” and “remove” capabilities from a role using the “ban” ability without first disabling the “ban” ability.

He’s also added server code  that will automatically eject a member, as long as the ejector has both the “eject” and “remove roles” abilities.

This means someone with both abilities no longer has to manually remove all the roles assigned to a group member prior to ejecting them, making the ejection process a lot more streamlined.Or at least, that’s the idea once implemented; right now the code has a small “oopsie” in it, as Baker explained, “Of course, in its current state, it will eject regardless of the two roles… which I’m working on fixing now 🙂  Somewhere down the line I did something wrong…”

There’s no timescale as to when the group ban work will appear. From Baker’s comments, it would seem as though the initial QA testing has now finished, allowing him to focus more on the viewer-side updates. Expect to see the results in a project or release candidate viewer before we’re too far into 2014.

Other Items

Disappearing Dwarfins and More

Judy Chestnut and Dante Spectre of Dwarfins fame attended the Simulator User Group meeting on Tuesday December 17th to report a worrying issue which has been affecting Dwarfins, as well as other breedable creations, which sees them suddenly vanishing from regions. Of those that vanish, some of which turn-out in the user’s Lost and Found folder, others reappear elsewhere in the region and others vanish completely.

Reporting the issue, Spectre indicated that his observed tests revealed that of those breedables which vanish, around 10% turn up in his Lost and Found folder, around 10% turn up somewhere else on the region, and the rest simply disappear, never to be seen again. Interestingly, those that are returned to Lost and Found do not appear to generate the notification normally seen following an object return.

Dwarfins (and apparently other breedables) have recently been inexplicably vanishing from regions
Dwarfins (and apparently other breedables) have recently been inexplicably vanishing from regions

The problems seem to have started around two weeks ago, immediately following the server deployments, although whether the issue is linked to a specific update is unclear, and neither Simon nor Andrew could see anything within the deployments which could explain the issue.

In terms of Dwarfins, the problem has been witnessed on regions running on both the Main (SLS) channel and on the Magnum RC. Regions affected include Dwarfins Rock, Rossavik, Hidden Sanctuary, Hawthorn Estate, and Bull Island, among others.

Andrew Linden has suggested that Dwarfins Rock is cloned on Aditi, where the behaviour of the region can be monitored closely. Should Dwarfins vanish from it, the Lab will then be in a better position to dig-in to data gathered from the region and hopefully determine what may be going on.

In the meantime, if you have noticed similar behaviour with any breedables of your own, consider raising a bug report.

LSL Materials Functions

There have recently been renewed calls for materials processing to gain additional scripted support so, as an example, normal and specular maps could be animated independently to one another / the diffuse (texture) map on an object. In fact, requests for such capabilities have been raised periodically since materials was first announced.

While the capability has not been officially ruled out, it is not at all clear when it might appear – if indeed it will. Commenting on the subject at the Content Creation User Group meeting on Monday December 15th, Nyx Linden said, “Scripted materials would be more difficult than you would think.” To which Oz Linden added, “There are some non-obvious complexities with scripted materials properties. We don’t have that in a plan yet, but we know that people would like it.”

So, for those hoping for scripted control of materials, it would appear to be some way off at the very least.

Advertisements

SL projects update week 50 (3): miscellaneous items

Server Deployments week 50 – Recap

As always, please refer to the week’s forum deployment thread for the latest news and updates.

  • Tuesday December 10th, 2013 saw the main channel updated with the server maintenance project that was on the RC channels in week 49.  This project includes a few miscellaneous bug fixes
  • Wednesday December 11th, 2013 saw the three RC channels updated with a new server maintenance project containing a single bug fix.

The RC channel bug fix is related to vehicles getting into a “bad” state where they appear sat upon / selected even if they have lost their passengers as a result of a region crossing. When in this state, they defeat the parcel / region auto return.

As the fix for this issue is currently only on the three RC channels and will not be promoted to the main channel until 2014 due to the code freeze / no change window, and because this issue may lead to vehicles accumulating in regions where there is a lot of traffic, Maestro Linden has requested that support move any main channel regions which are affected to an RC channel.

2014

These deployments were the last scheduled deployments for 2013. They also mark the last scheduled rolling restarts for the year as well, as there are no plans to restart any channels in either week 51 or week 52. The only exception to this will be if any major issue / fault occurs within the grid which necessitates a restart.

The next scheduled server-side deployments will take place in week 2 of 2014, the week commencing Monday January 6th, 2014.

Some information on updates which will be forthcoming in 2014 were given during the final Server Beta meeting of 2013. These include:

  • Andrew Linden’s work on “Uniform Scaling” LSL Functions for linksets (see part 1 of this week’s report). There are a couple of basic rules with the new functions: no prim in the linsket can be smaller than 1 cm or larger than 64m, and all prim centres must be within 54m of one another in order to be linkable. There will be two new functions as a part of this work:
    • integer llScaleByFactor(float factor):  uniformly scale a linkset by the specified factor (e.g. 2.0 to double the scale).  Returns TRUE if successful, FALSE otherwise
    • float llGetMaxScaleFactor(),   float llGetMinScaleFactor(): return the maximum / minimum scale factors that will work in llScaleByFactor due to limits in place by prim scale and linkability distance restrictions
  • An update to llLoadURL, so it will have a 0.1s delay instead of 10s (although there is still a throttle in place to prevent someone from spamming somebody else in order to crash their viewer)
  • llGetObjectDetails() & OBJECT_STREAMING_COST will be amended to return data when targeting an agent. Currently, OBJECT_STREAMING_COST doesn’t give you much of anything when targeting an agent; once this change is in place, it will return the sum of the streaming costs of all worn attachments (excluding HUDs)

SL Viewer

The “Project Interesting” (viewer-interesting) RC viewer updated on Thursday December 12th to version 3.6.13.284757, which includes a number of fixes from the initial release:

  • BUG-4675 Viewer crashes while reading chat history
  • SH-4606 Interesting: Small objects do not load until they are very close.
  • SH-4627 [INTERESTING RC] “Object out of range” is not detected on teleport.
  • SH-4631 [INTERESTING RC] Parts of linked objects are not shown in new release Second Life 3.6.11
  • SH-4641 Interesting: Incorrect amount of system memory detected on Mac

This may be the last RC update for 2013, unless something like the Google Breakpad RC is slipped out for another round of testing on Friday December 13th.

STORM-68

As noted in part 2 of this week’s report, STORM-68 is a third-party contribution which will allow a builder / creator to specify the default permissions applied to a new prim object (cube, cylinder, torus, etc.) on creation. Further testing has been taking place since my last update, and a number of issues and bugs have been resolved as a result. The test plan for the changes is complete and the viewer-side changes now look ready to go to LL’s internal QA. Again, this change requires server-side updates, so it is unlikely to appear in an RC viewer until the server updates are reasonably available on the grid, although this will hopefully happen in the early part of 2014.

SL projects update week 50 (2): Fitted mesh, deformer, viewer code contributions

Mesh Deformer and Fitted Mesh

The future of mesh garments / wearables created using the now SL-defunct mesh deformer was the subject of some discussion at the Open-source Contributions meeting on Wednesday 11th December. While the deformer was never officially adopted by the Lab for use within Second Life, it was available in various test and experimental viewers, and the code could also be included in self-compiled viewers if people knew how.

Fitted mesh is coming....what of the future for garments made for the deformer?
Fitted mesh is coming….what of the future for garments made for / via the deformer?

This means that there are garments within Second Life that were created and uploaded for / with the deformer code, and which can resize with viewers using that code. However, as is the case with Fitted Mesh, the clothing would not deform when using a viewer without the requisite code. The same will be true once the Fitted Mesh updates reach a release candidate status and start to be more widely adopted: while Fitted Mesh (and Liquid Mesh) garments, etc. will deform to an avatar’s shape, items created using the mesh deformer will not; they will continue to behave like any other rigged mesh item.

This likely means that as the Fitted Mesh code does become more widely adopted, people will stop using any garments / attachables created using the deformer code, and the availability of such items in SL and on the SL marketplace will decline over time.

Whether or not this means deformer-based items will vanish from people’s inventories is something only time will tell. From the Lab’s perspective, the work involved in trying to pro-actively determine a method of identifying assets using the deformer code and removing them from the asset servers / inventories isn’t likely to be worth the end result. Therefore anyone with “old” mesh deformer garments and attachables will probably retain them until they opt to delete them from their inventory.

It appears unlikely that viewers using the deformer code will be pro-actively blocked from SL. What is likely to happen is that the code simply will not be formally adopted by those variants of TPVs which do not connect to any other grid than Second Life. However, this does leave a further interesting question as to the future of the mesh deformer, which has potentially seen far wider use in OpenSim communities than Second Life. While it would seem likely OpenSim will adopt the viewer-side changes required to enable Fitted Mesh (at least in the majority of cases), at this point in time, it is not clear whether the mesh deformer will be entirely abandoned. Whether there will be sufficient pressure within OpenSim for the deformer code to remain in use, and whether TPVs will feel obliged to incorporate the deformer into their viewers / OpenSim variants of their viewers as a result, remains to be seen. Currently, the only grid which has any kind of significant investment in the deformer is InWorldz, which provided funds for the code to be further enhanced and adopted it into their dedicated viewer in July 2013.

Materials and Numbers

Statistics are always a hard thing to determine. Back in the day, there was much controversy over figures released as to the adoption of mesh within SL following its deployment. The figures offered-up by the Lab at the time were vague enough that they could be taken to mean that mesh was either being rapidly adopted, or was seeing very slow growth (with the reality lying somewhere in between). This was not an attempt by the Lab to fudge issues at the time; it simply underlined the fact that numbers aren’t always the best means of trying to quantify something, so it’s perhaps better to allow the passage of time to speak for itself.

The most recent figures for materials suggest that over half of the regions in SL now have at least one materials-enabled item within them, and around 10% of avatars apparently utilise at least one materials-enabled item.  Again, these are figures that are likely to be interpreted either way, depending on how people look upon materials as a whole. Certainly, the term “object” is sufficiently vague so as to be pretty worthless as am objective yardstick, as it likely covers everything from an individual prim through to entire linksets, which leads to a huge variance in the visibility of objects using materials. On a personal note, I can only say I’ve made extensive use of materials in my house, and am more than pleased with the results.

I've used materials on my house; particularly on the stonework and stucco textures to prevoide added depth. Materials on the whole appears to be slowly gainly momentum
I’ve used materials on my house; particularly on the stonework and stucco textures to provide added depth. Materials on the whole appears to be slowly gaining momentum

Upcoming Code Contributions

There are a number of third-party code contributions in development for the SL viewer, some of which I’ve previously reported upon, and which are now progressing towards a point where they may well have public visibility through the likes of a release candidate in the new year.

STORM-1981 and STORM-1831

STORM-1981, contributed by Jonathan Yap, is intended to change the behaviour of tracking beacons to help make locating items in a region somewhat easier (e.g. locating lost items or scripted objects which are causing issues, etc.).  Under these changes:

  • Beacons would begin at a height of 0 metres and extend up to the maximum unassisted flight ceiling (5,020 metres)
  • The beacon colour will be blue from 0 metres to the base height of the object being tracked, and red from 5,020 metres down to the height of the object being tracked
  • Users can optionally set the beacon to pulse towards the target object using the CheesyBeacon debug setting (Advanced->Highlighting). The blue beacon will pulse up towards the object, the red beacon will pulse down towards the object.
Tracking beacons will be changing under STORM-1981, making it easier to locate objects, etc.
Tracking beacons will be changing under STORM-1981, making it easier to locate objects, etc.

STORM-1831 covers the work being undertaken by Ima Mechanic, with assistance from Oz Linden, 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 with 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. Folded-in to this work should also be a change to the source code text allowance in the viewer’s LSL editor, increasing it from the current 65,000 characters to around 256,000.

The server-side cap updates required for both STORM-68 and STORM-1831 have been combined and passed into the simulator release stream, and while it is unclear as to when the cap updates will reach a server-side release candidate package, their progress is being tracked. Obviously, both STORM-1981 and STORM-1831 require viewer-side updates as well, and these will hopefully appear in viewer release candidate form once the server-side updates are sufficiently deployed.

STORM-68

A number of TPVs include the ability to specify the default permissions applied to a new prim object (cube, cylinder, torus, etc.) on creation. STORM-68 aims to add a similar capability to the LL viewer (and which will quite possibly supersede the capability in TPVs once implemented). This work is again coming from Jonathan Yap, although it requires server-side updates, which Andrew Linden has been taking care of. However,  this work has hit some problems in viewer / server interactions, which may be down to timing issues between requests and acknowledgements being sent between the viewer and  the simulator and vice-versa. As such, further testing is required, so it’s possible this work might take a little longer to appear in the new year.

SL projects update week 50 (1): server and viewer updates

A typical Simulator UG meeting (stock)
A typical Simulator UG meeting (stock)

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.

SL Viewer

The SL release viewer was updated on Tuesday December 10th to version 3.6.12.284506, 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*.

Other Items

“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:

Higgledy-piggledy explained courtesy of Mr. Berke Breathed
Higgledy-piggledy explained courtesy of Mr. Berke Breathed