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.
- 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.
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.”
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.
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
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.