SL projects report week 31 (2): server and viewer

Server Deployments Week 31 (Week Commencing Monday July 29th)

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

Second Life Server (SLS Main) Channel

On Tuesday July 30th, the SLS Main channel received the server maintenance package previously deployed to BlueSteel in week 30 and LeTigre in week 29. This project includes:

  • A further fix for the issue of pathfinding characters using CHARACTER_STAY_WITHIN_PARCEL getting stuck if they somehow exited their home parcel
  • Fixes for objects failing to detect collisions after teleporting (BUG-969) and run time permissions failing to function correctly on attachments (BUG-2931)
  • New capabilities added to the materials system to control how quickly the viewer can set or query normal and specular maps on objects. The current maximum is once a second and the new capability will be 4 a second. However there will need to be a viewer-side update to make use of the new capability, which should be available soon.  Commenting on the capability, Maestro Linden said, “the difference will probably be most noticeable if you’re doing something like rotating the normal map on an object with the spinner control (holding down the button) it should update more quickly to observers in that case.”

Release Candidate Channels – Wednesday July 31st

  • Magnum and LeTigre will remain SSA enabled and both received the updates deployed to the Main channel.
  • BlueSteel should have received a new server maintenance project. However, as noted in the update to part 1 of this report, a last-minute bug was found in the code which meant the deployment didn’t go ahead with the result that it is currently running the same release as the Main channel.

Viewer Updates

There have been a number of viewer release candidate updates for the end of the week:

  • The Google Breakpad RC was updated on Tuesday, July 30th (2.6.2.279026 – download and release notes)
  • The Snowstorm  contributions appeared in a release candidate on Wednesday, July 31st (3.6.2.279119 – download and release notes)
  •  The Vivox RC was updated on Wednesday, July 31st (3.6.2.279258 – download and release notes)
  • The CHUI updates became the latest viewer release candidate on Thursday, August 1st  (3.6.2.279321– download and release notes)

The appearance of the CHUI and Snowstorm RCs brings the total number of cohorts in the release channel up to five.

Animation Syncing Issues

Speaking at the Server Beta meeting on Thursday August 1st, Maestro Linden said that he and Alexa has been looking into the animation syncing issue I noted in part 1 of this report. Their findings pointed to an issue going back to 2012, whereby someone who is dancing in sync with others can cams such that all of the group is out of the field-of-view and then cams back, their own avatar will be out of sync with the rest. As such, Maestro felt the issue might be related to JIRA VWR-10578.

Some saw people go out-of-sync almost as soon as dance sequences started, and without moving their camera position (image courtesy of Whirly Fizzle)
Some saw people go out-of-sync almost as soon as dance sequences started, and without moving their camera position (image courtesy of Whirly Fizzle)

Following the meeting, a number of us participated in a “group dance test” to see what would happen, and the experiences varied somewhat, with some reporting issues consistent with the long-standing problem, others seeing avatars slip out of sync without and camera movement, and some reporting the avatars on the very edge of their field of view appearing to be dancing slower than the rest, and starting to slide out of sync. This lead to a lot of speculation as to the possible causes, and also as to how much settings such as avatar imposters or message throttling might be influencing the viewers play-through of animations.  Maestro did suggest some of the issues may be down to some sort of message sorting behaviour based on where the avatars are, relative to camera view. As it was, no definitive outcome was reached, so it is liable that investigations may continue.

Related Links

8 thoughts on “SL projects report week 31 (2): server and viewer

  1. I could not read the BUG-2931 JIRA entry (run time permissions on attachments). I was told I didn’t have permission to read it. I’m still getting permission problems reported from scripts, though I think it’s a different probem. centred on vehicles.

    JIRA sucks minor planetary bodies.

    Like

    1. The attitude with the JIRA seems to be, “Go ahead and file. Doesn’t matter if it is a duplicate, there are enough eyes on things to weed them out”. Which is fine as far as it goes – but misses the point. Simply being able to peruse the JIRA, as you wanted to to do and check on current reports, reports listed in release notes, etc., and to look to see if issues you’re experiencing have been encountered elsewhere was an invaluable aid for all of us in trying to better understand what’s going on and being able to help identify possible causes / eliminate extraneous issues & thus help the Lab with initial triage.

      In this respect, I still fail to understand why the Lab simply didn’t disable comments for the entire JIRA, but leave items publicly-viewable, as they choose to doe so with certain categories of report, such as STORM. SUN, MATBUG, ad the old VWR.

      Like

      1. Yep I hate filing knowing I’m mostlikely filing duplicates, but gotta say the Lindens have done a good job in my experiences with personally following up on the few things I’ve had to submit. The resolution has usually been, when there’s a resolution to be had, 1. We know this bug, fix incoming. 2. Here’s a beta region a fix is patched, please try it. 3. It’s fixed next server release.

        I still think non-public JIRAs are a bad system but Maestro and company are making the best of it from what I can tell.

        Like

        1. Agreed, It’s easy to point to the negative side of the system and overlook the fact that things do move through it – some with considerable more speed than might have previously been the case. The UG meetings are certainly a good way of tracking what is happening on issues people are specifically aware of, and where fixes are listed in release notes. As you say, Maestro, Andrew, Simon et al do try to cover tems as and when they can, with Maestro also providing feedback through the forum.

          Like

      2. Yes, you’re quoting the forum thread which announces what they’re doing. and all those JIRA numbers look as though the Lindens are telling us what they’re doing, but the actuality is that they don’t communicate. The use of the JIRA number amounts to institutional deception when we’re not allowed to read what it refers to.

        Like

        1. I wouldn’t go so far as to label it “deception”. As noted in other comments here, the JIRA do often get discussed in various meetings (and there are those users who still have access to BUGS who can provide additional information). Where this happens, I and other bloggers who make a point of attending the weekly meetings try to provide the additional information. BUGS do also get discussed in the forums. So it’s not like there is a deliberate or systematic attempt to mislead at any point – it is just annoying that the doors have ben closed on general perusal and the ability for users to look into matters themselves, as used to be the case.

          Like

    1. I’m sure it is. Doesn’t stop the viewer being open for people to view and reference properly, however. Escpailly if the comments / vote/watch options are disabled.

      Like

Comments are closed.