Yesterday, I reported on the SUN-74 issue (Apparent avatar skin and eye texture asset corruption with Server Side Appearance), which can impact users with avatars wearing modifiable skin and/or eyes and/or hairbase who enter (via teleport or crossing a region boundary) an SSB/A-enabled region while using a non-SSB/A enabled viewer (e.g. such as Phoenix or the v1.23.5 viewer) and leave them with a corrupted copy of the worn skin / hairbase or eyes. At the time I noted that the matter was under investigation by Linden Lab, and no decision had been made on how to handle it.
Whirly Fizzle demonstrates one aspect of the SUN-74 issue – on a non-SSB/A viewer, her MOD skin has turned black / invisible and her MOD eyes have turned white as a result of entering an SSB/A-enabled region and responding with YES to the given prompt.
Speaking at the TPV Developer meeting on Friday May 31st, Oz Linden provided an update on the issue and spoke more generally on the issue of the use of olfder (non-SSB/A capable viewers) going forward:
We don’t actually know what’s ultimately going to be done about that; that’s a subject of vigorous discussion that’s going on even as we speak, so we’ll see how that plays out. I think it’s fair to say that regardless of what happens with that particular issue … I will just make the observation that there are still people really, really old viewers [and] there is no way, no way at all, that we could even begin to test for compatibility back with all of those viewers.
As it is, as recently as this last week there were 1,665 different viewer version strings reported as connecting to the main grid (these include 151 versions of Singularity, 50 versions of Phoenix, 262 labelled as Firestorm, and so on). Some of these may be “one offs” self-compiled builds (which may or may not have the most recent updates to support something like SSB/A), but even so, given the overall number of viewer strings, it is understandable why the Lab view attempt to ensure so many different viewer versions were fully compatible with anything on the grid is a next to impossible task.
This does not mean that the Lab is going to ignore SUN-74, right now they are still investigating the problem and trying to reproduce it in a consistent manner (which is apparently proving difficult for a number of reasons, not the least of which is that some older viewers simply crash when attempting to repro the corruption). However, what it does underline is the need for people to upgrade to an SSB/A-enabled version of their preferred viewer sooner rather than later.
The reason for this is that very soon the Lab will start undertaking more widespread testing of the new service by enabling it across a number of regions across the grid. These regions may not necessarily be constrained to any of the usual RC channels, but could well be a mix of regions from all of the various simulator channels, making them harder to identify and avoid. This testing will be to gain greater insight into how the service stands up under “real avatar loads” – something which is impossible to carry out to any great depth on Aditi, as there simply isn’t the volume of users active there.
Once this more widespread testing starts, then it is entirely possible that users who remain on non-SSB/A capable viewers are going to encounter issues and problems beyond seeing grey avatars which the Lab are not going to address, simply because the issues can be resolved by a viewer update.
The server channel deployments are delayed 24 hours this week due to Monday May 27th being Memorial Day in the USA. As usual, the latest updates, feedback and comments can be found on the deployment discussion thread. Anyone encountering a specific bug is asked to file a JIRA.
Second Life Server (Main) Channel
On Wednesday 29th May, the Main channel should receive the server maintenance project previously on Magnum. This includes bug fixes, comprising two for crash modes and one for BUG-2424 (Overriding “Sitting on Ground” animation while sitting on the ground makes “stand up” button disappear). This deployment also includes the LSL support to create and parse JSON-formatted strings, which also includes the bug fixes for this capability deployed to Magnum in week 21 (see my SL projects update report from week 21). Release notes.
Release Candidate Channels
On Thursday 30th May, the three Release Candidate (RC) channels should receive the interest list improvement project deployed to LeTigre in week 21. The core change in this update should reduce scene loading time when entering a new region (again, please refer to my week 21 report for background information). Release notes (BlueSteel, but applicable to all three RCs).
SL Viewer
The SL release viewer updated to 3.5.3.276452 on May 28th (release notes), leapfrogging it ahead of the last of the beta channel viewers. This release may include updates which may lessen the issue of “missing prims” which people have been encountering over the last couple of months.
The anticipated move of the Materials Processing project viewer to a beta release status in week 21 did not happen. The current project status is unclear, but hopefully the move to beta should occur sooner rather than later.
Other Projects
As a result of the long weekend in the USA (Memorial Day) it is currently a light week for news on the projects LL are working on for SL. Expect this to be rectified as the week progresses!
As noted in part 2 of this report, due to issues with the JSON deployment made to all three Release Candidate channels in week 20, there was no Main channel deployment in week 21.
Maestro Linden likes to keep fit while chairing the Server Beta meeting
On Wednesday May 22nd, the three Release Candidate (RC channels should each receive the following updates:
Magnum received an update to the server maintenance project deployed to all three RC channels in week 20 which includes fixes for bugs within the LSL support to create and parse JSON-formatted strings. Release notes.
BlueSteel received a further update to the experience tools project, and there should be no visible changes with this update. Release notes
LeTigre received an update related to the simulator’s interest list subsystem which reduces scene loading time when entering a new region. Release notes.
As mentioned above, the Magnum updates included a fix for an issue within the LSL JSON capabilities deployed to the three RC channels in week 20. Currently, the fix appears to have resolved the issues, so it is possible the JSON capabilities will reach more of the grid once more in week 22.
“json is a javascript way to describe data and pass data between scripts or services. In that regard one of the biggest benefits of json in LSL is for improving the ability of LSL to interact with 3rd party APIs,” Kelly Linden explained at the Server Beta meeting on Thursday May 23rd after questions were asked as to the purpose of the capabilities. “Because it is simple and relatively ‘complete’ even non-javascript services use it on the internet to exchange data … I’ve been interested in services like parse.com for example which let you store and retrieve data very easily … in json … https://parse.com/docs/rest this is what would work with LSL.”
Kelly also noted the new capability might be used within LSL, but with a small caveat, saying, “If you are only working within LSL there may be some specific cases where it is beneficial, but other string to list functionality will probably be fine.”
The package deployed to Magnum also included a fix for the bug introduced into the RC channels in week 20 which affects control event triggering in attachment’s child prims after changing regions. However, the fix as deployed is described as “interim”, and corrects the problem (which is described in full here) by reverting the fix for SVC-8227 (ApplyImpulse now works only in the root prim). Referring to the situation at the Server Beta meeting on Thursday May 23rd, Maestro Linden said, “we hope to get a ‘real’ fix in for that sometime in the future.”
SL Viewer
Further to part one of this report, Oz Linden has clarified the function of the new “Willing to update to release candidate” option in project / beta viewers. As I’ve previously mentioned, when a viewer is believed to be of release quality, it will be put into a release candidate, which will be released to a chosen number of users (the number determined by Linden Lab). By leaving this new option checked, users are indicating that they are willing to receive any such release candidate updates if they are selected by LL to receive them. Unchecking the option means that a user will not be included in the count for any release candidate update, and so will not receive any updates until such time as the viewer reaches release status.
The new “Willing to Update” option
Even so, leaving the box checked does not mean a user will automatically receive release candidate updates – as noted above, LL will determine the total number of users who will receive any given release candidate updates. These will be chosen at random from those who are using the project / beta viewer, and once this number has been reached, no further users will receive the update regardless as to whether the option is enabled or not. If necessary, the selection process can be additionally targeted at specific operating systems, but the Lab currently don’t have plans to use this capability.
While the new release process is not dependent upon Materials Processing project viewer reaching a beta release status, it still appears unlikely that the new processed will be deployed until after Materials has done so. Once the new release process has been deployed, Oz indicates that it is likely that a number of viewer candidates will appear – such as a bug fix candidate a Snowstorm candidate and possibly others as well, although the exact timing and spacing of the releases is unclear.
Interest List News
Andrew Linden
Also attending the Server Beta meeting, Andrew Linden provided a further update on the interest list updates deployed to LeTigre. These amount to a number of fixes and updates to the code.
“The main thing in that RC is some minor tweaks to help the scene load a little faster on login and teleport. The effects are small, especially in the case where you have a full cache for that region so I’m guessing that no one has really noticed the scene loading any faster.” Andrew explained, “There was [also] one minor bug I fixed for people with really low-bandwidth settings… the updates were not properly getting re-sorted when the camera moved around, so the scene would continue to stream in based on where you were standing when you arrived but most people with >500kbps bandwidth shouldn’t notice that problem — the scene usually loads fast enough now. ”
He went on to reiterate that the LeTigre deployment also includes a partial fix for the “Meeroo update” problem of objects not updating correctly after being outside of the camera’s field-of-view. Again, as mentioned in part 2 of this report, the fix works with affected objects which are up to 10 metres away. However, he believes he now has a more complete fix for the problem, but has yet to test it. He also believes that the issue causing the “Meeroo update” problem may also be responsible for BUG-2644 (pathfinding characters not updating behind the camera) is the same problem as the Meeroo animation, and is hopeful his intended fix will correct that as well.
Finally, the update fixes a minor bug where the green avatar dots on the mini map would not update correctly for avatars behind the camera.
The downside to the LeTigre update is that it did introduce a crash mode, which Andrew described as “rare… only about 6 per day,” and which is currently being investigated.
Server-side Baking / Appearance
As noted in week 20, it has been hoped that the server-side of the SSB/A code would be enabled on two test regions on the Main grid. These regions are Intended specifically for TPVs to carry out functional tests on the viewer code away from the distractions of broader issues which interfered with testing on Aditi. As such, they should not be considered a sign that deployment of the server-side code had commenced. It had been hoped that the two regions would be enabled this week, but at the time of writing, this is not yet the case. This doesn’t necessarily mean the project is delayed, however.
In terms of overall deployment, matters are unlikely to have changed since week 20, and the Lab will still in part be looking at this initial “TPV test” period as an opportunity to gain further additional metrics on the system and to look for anything untoward occurring prior to committing to possible dates.
Work continues on implementing the new viewer release process, although it is unlikely to debut this week (week 21). Commenting on the state-of-play at the Open-source Development meeting on Monday May 20th, Oz Linden said, “There are some new services to stand up, and I don’t have enough experience with that to be able to estimate it well.” He also indicated that the necessary changes to the log-in process I reported on in week 20 are still being progressed with care.
However, as of May 20th, 2013, the viewer beta repository has been discontinued by the Lab. This means that the next beta viewer to appear – which is due to be the Materials Processing viewer due out possibly later this week – will be built directly from the Materials project repository and not a merge with the existing beta viewer, although it will go through the existing beta channel for release and made available via viewer download page.
Viewer Naming
Under the new system, viewer names will be broadly streamlined, with beta and release candidate versions of viewer being broadly identified by the viewer type and project name (e.g “Second Life Beta Materials” or “Second Life Release Candidate Materials”), prior to being updated as the release viewer.
“Willing to Update”
As previously noted in this blog, when a user downloads a specific viewer, they will only receive updates specific to that viewer until such time as it reaches a release status (although user can theoretically run several viewer side-by-side, and receive the required updates to each of them as they become available). However, the beta viewers will in future a new Preferences option, “Willing to update to release candidates” (Preferences > Setup).
The new beta viewer option for updating to RC status
Precisely how this option works is unclear (I have contacted Oz Linden on the matter but have yet to hear back), but it appears to suggest that if unchecked, then notification of any RC updates to the viewer will not be forwarded to the user / automatically downloaded and installed, and will thus leave the user running with the viewer in a beta state until such time as a mandatory update is forced as the viewer becomes the de facto release viewer.
How Many?
The new release process means that there will be more viewer options to download via the Alternate Viewers wiki page. How many depends on the number of projects and general work is going on with the viewer. However, it also means that once operational, there should be fewer incidences when a specific project or issue interrupts the flow of viewer through to release status, as occurred towards the end of the 2012, when the viewer releases became “stuck” in the beta release channel as a result of a single crash issue.
As always, please refer to the release forum thread on the weekly deployments for the latest updates and discussions.
Second Life Server (Main channel)
On Tuesday May 14th, the Main channel received the Experience Keys project. This means the project is now available across the grid, although there are no visible changes to be seen at this point. Release notes.
On Wednesday May 15th, all three RC channels received a new server maintenance project (release notes (Bluesteel)). The project is designed to fix two crash modes and two bugs, and introduce new LSL support creating and parsing of JSON-formatted strings – see part 1 of this week 20 report.
Commenting on the JSON capabilities at the Server Beta meeting on Thursday May 16th, Maestro Linden said, “There are some issues with this week’s Json functions… the keys in key-value pairs are not quoted, but should be and right now you’ll run into problems when you add stings which contain escaped quotes.”
In addition, a further confirmed bug has been found in the code on the three RC channels (BUG-2601), described by Lucia Nightfire as:
Seems that the release on the RC channels has brought about an annoying bug that affects control event triggering in attachment’s child prims after changing regions.
There are two different effects depending how you enter a version 13.05.14.275813 RC region.
After going into an RC region while using any controls, those controls will lock under execution and remain locked until you reset the script or the control perms or detach the object.
After going into an RC region without using controls like with a teleport, the control event will not trigger when attempting to use any controls until you re-request/re-grant control perms or go back to a main channel region.
Should this problem be encountered, returning to any Main channel region should restore the broken functionality.
Because of both of these issues, it is believed the code currently on the three RC channels will remain on them for a further week while fixes are developed and implemented.
SL Viewer Updates
Beta Viewer
The current SL beta viewer code, which contains the FMOD Ex updates is expected to be merged with viewer release shortly, prior to going to testing. Depending on the results of the testing, an updated SL release viewer should appear early in week 21.
Viewer Release Process
Because the version upgrading changes will move to the viewer release channel with the move of the current beta viewer, the viewer beta repository will stop being used, and viewer releases will start switching over to the new release process. As a part of this, two new wiki pages will be appearing in the next future (probably in week 22).
The first of these will be a revamped Alternate Viewers page on the wiki, which will list all the available LL project viewers and beta viewers and release candidates which are available, as well as the current viewer release, all of which will have download links and links to their respective release notes.
The second wiki page will have the same information together with pointers to which repository used to build the viewer, which changesets were used to build a viewer, and whether or not the repository is public.
The plan remains that under the new release process, all beta and release candidates will have public repositories, while project viewers many not initially have public repositories, but will have as they reach the later stages of their development.
Cocoa Project
The Cocoa project for Mac versions of the viewer has been largely stalled as a result of redeploying TPV assistance from that project to the materials project. It is anticipated that once materials moves to a beta viewer status, the emphasis will shift back on to the Cocoa viewer work
Materials Processing
Providing all goes according to plan, the Materials Processing code should move to a beta status within its own repository and hopefully also make an appearance in week 21. Commenting on this, Oz Linden said at the TPV Developer meeting o Friday May 17th, “It’s still not 100% there; there’s still a few known bugs, but we think we’ve got all the serious ones and so we’re going to put it out where people can play with it.”
Once the materials viewer does reach beta, the anticipation is that it will remain there for “a little while” and the it will not be a one-spin beta release prior to moving on.
Materials used to create details on the hilt of a Katana created by June Dion – soon to be visible in the Materials Processing beta viewer
As always, please refer to the release forum thread on the weekly deployments for the latest updates and discussions.
Second Life Server (Main channel)
On Tuesday May 14th, the Main channel received the Experience Keys project which is widely regarded (and referred to by LL staff) as the “experience permissions”. This means the project is now available across the grid, although there are no visible changes to be seen at this point.Release notes.
Speculation is still running high on exactly what the new project is – and whether it is “just” the experience permissions to partner the existing advanced creation tools ot something more – as well as whether the capabilities will be available for use across the grid (i.e. on Mainland as well as private estates). Details will be forthcoming from the Lab in time; for the moment, they’re holding their cards close to their collective chest.
On Wednesday May 15th, all three RC channels should receive a new server maintenance project (release notes (Bluesteel)). The project is designed to fix two crash modes and two bugs, namely:
A fix for ‘Overriding “Sitting on Ground” animation while sitting on the ground makes “stand up” button disappear’ (BUG-2424)
A fix for ‘ApplyImpulse now works only in the root prim’ (SVC-8227)
In addition, this project introduces new LSL support creating and parsing forJSON-formatted strings. The new LSL functions comprise:
list llJson2List(string json) – converts the top level of the json string to a list.
string llList2Json(string type, list values) –
Type is JSON_ARRAY or JSON_OBJECT
Converts either a strided list of key:value pairs to a JSON_OBJECT or a list of values to a JSON_ARRAY
string llJsonGetValue(string json, list specifiers) – gets the value indicated by spcifiers from the json string.
string llJsonSetValue(string json, list specifiers, string value) – returns a new json string that is the json given with the value indicated by specifiers set to value
string llJsonValueType(string json, list specifiers) – returns the type constant for the value in json indicated by specifiers.
At the time of writing, the RC deployments still had a question mark over them as testing was, according to Simon Linden when speaking at the Simulator User Group, “down to the wire, although it all looks good.”
Further information on the new LSL support for JSON can be found on the LSL JSON wiki page.
The project is being lead by Kelly Linden who described the reason for implementing them as being because he’s “keen on improving the ability to interface LSL with the larger web. The previous maintenance version expanded the content-type support of http-in and http-out which ties in with this.”
It is likely that further LSL support for JSON will be added in the future.
SL Viewer
Beta Viewer and the Viewer Release Process
A further beta viewer release was made on May 11th (3.5.2.275565) – see the release notes for details – in preparation for the deployment of the new viewer release process. The beta 3.5.2 viewer incorporates changes required by the new service.
While at the Open-source Dev meeting on Monday May 13th, I asked Oz Linden on the status of the new process. “Internally, we’re essentially already using it in that all projects are based on viewer-release,” he replied. “We’re starting system test of the server-side infrastructure changes this week… once those are tested, it’s just a matter of deploying them and we can fully switch over to the new process. ‘just deploying’ on our scale is always an understatement, incidentally.”
This does not mean the release process is about to be deployed, however. The server-side infrastructure testing is liable to be on-going for a while. One aspect which the Lab will be checking carefully is the changes made to the log-in process.
When a user logs-in to Second Life using an official viewer, a check is carried out to see if a mandatory upgrade is required. To prepare for the new release process, is check has been updated. “that’s not something one deploys without having taken every step one can think of to quadruple-check just a bit,” Oz explained.
How long the tests will take to complete is unclear, but it is unlikely the new release process will be deployed in week 20.
Materials Processing
May 8th saw the The materials project viewer updated with the release of version 3.5.2.275470, with the release notes available here.
Detail on the hilt of a Katana created entirely using the new materials capability. The sword is made by June Dion and has an LI of 7
Work is continuing with the viewer, focusing on the UI issues which need to be resolved in order for the code to progress towards mainstream release.
Inara Pey: Living in a Modemworld 