SL projects update week 42 (1): Server, viewer updates, misc news

Server Deployments – Week 42

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

Second Life Server (Main Channel) – Tuesday October 15th

The main channel received the server maintenance project previously on all three RC channels in week 41. This project includes a fix for a group notice delivery issue, introduces a missing JSON operation to LSL, and includes preparatory work for an upcoming viewer with scene loading (interest list) improvements.

Second Life RC BlueSteel, RC Magnum, and RC LeTigre – Wednesday October 16th

All three RC channels should receive a new server maintenance project.  However, at the time of writing, it is unclear whether the RC deployment will occur due to a last-minute bug being identified. Speaking at the Simulator User Group meeting, Andrew Linden indicated that while it had been fixed, it has yet to pass internal QA.

Assuming it does go ahead, the deployment includes fixes for the following issues:

  • “Group member access to parcels fails when ‘Sell passes to’ is enabled” (BUG-3992)
  • “‘Ghost’ avatars and vehicles sometimes appear to an observer at the sim border” (BUG-3872)
  • “Vehicles which exit a region with a passenger are incorrectly auto returned and become ‘ghost shapes’ in the physics engine” (BUG-4024)
  • A performance issue with avatar loading speed in the experimental ‘viewer-interesting’ viewer.
Simulator User Group meeting, Tuesday October 15th 2013
Simulator User Group meeting, Tuesday October 15th 2013

In addition, extremely high Avatar Render Weights reported to the server are now capped at 500,000 (BUG-4010)  – so the server will take any report over 500k and treat it as 500k.  Simon explained that this cap had been arrived through a process of observation and data-gathering he undertook himself or resident supplied to him, all of which suggested the average for ARW among users is around 100K. In describing the cap in general, he went on:

You should consider anything close to 500k as just “way too high”. The system is a compromise that’s needed because some people will try to game it You should not trust the values too much. They are from viewers, which (don’t take this personally, anyone) cannot be trusted to be accurate 500k is at the very high-end of usage.

Really, anyone near that in a public place is hogging your viewer display power if you’re up by 500k – you’re using roughly 5x the viewer render resources as everyone else Also remember that SL is not doing anything with this data. It’s up to scripters and land owners to react.  So I can imagine a popular club maybe sending a warning IM to someone who’s really complex.

 I hope some people can find it useful within its limitations.   As it currently works, it should give scripts a good idea if some people are extra-costly.   It’s up to the scripter to handle that well or not.

SL Viewer Updates

Two new release candidate viewers were deployed to the release channel on October 14th and 15th. These are the Catalyst Viewer and a further Maintenance Viewer.

Maintenance Viewer

Release on October 14th, Maintenance RC 3.6.8.282335 includes:

  • finer access control for estate/parcel owners
  • CHUI: toggle expanding Conversations by clicking on icon
  • clean up messaging & notifications
  • fix crashes & hangs
  • GPU table update

Catalyst Viewer

Release on October 15th, the Catalyst RC, release 3.6.8.282367, is intended to address a start-up crash on latest AMD Catalyst drivers: 13.9, 13.10, 13.11.

Interest List

Not much to report here, the viewer-side code has yet to emerge as an RC, but Andrew Linden has been working on comparisons with scene loading in the hopes of producing a film to demonstrate the improvements. He’d recorded the “before” footage a while ago, and has been focusing on the “after” footage.

“I brought the regions up on some old simulator code from before any of the latest interest list work… from Dec 2012. Andrew Linden: and I was reminded as to how poorly the scene used to load;  everything arrived in mostly random order,” he said during the simulator User Group meeting, “I found a very small room in one of my test regions. So I logged out while standing in this closet, cleared my cache, and logged back in… On the old simulator code you could see the world streaming in and then BAM! the walls of the room would obscure everything. On the new code… the walls are there as soon as the login curtain raises. Not that the scene loading is perfect now, but some of you may remember… it used to be much worse.”

Hopefully we’ll be able to see the video soon, and Andrew will be able to avoid further plays on him coming out of the closet…

Group Ban List

Again, not a lot to report at the moment. Appearing at the Simulator User Group meeting, Baker Linden said:

I wanted to give an update on group bans:  I’m currently working through the bugs found by internal QA testing, trying to fix them as quickly as I can. Later today I’ll be doing another round of code reviews, and hopefully everything there will go smoothly.

SL Projects update week 41 (2): TPV developer meeting, group ban list, interest list

Server Deployments Summary – Week 41

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

  • There was no update to the Main channel
  • The three RCs remained on the same package as deployed in week 40, with one additional fix for objects using llGetCameraRot() as a result of an interest list related issue.

Potential Server Deployments  – Week 42

Speaking at the Server Beta meeting on Thursday October 11th, Maestro Linden indicated that allowing for QA testing and final decisions, it looks as if week 42 (commencing Monday October 14th) should see:

  • The Main channel receive the package currently deployed to the three RCs
  • At least one RC package which should contain fixes for the region crossing issues noted in my week 40 report, namely: vehicles being incorrectly autoreturned on crossing a region boundary under certain circumstances (and the collision body being left behind) and “ghost” avatars and vehicles sometimes appearing to an observer when the region crossing is at the limits of their draw distance.
In the guise of my "Crash Test Alt", I doogie with a top-hatted Simon Linden at the Server Beta meeting
In the guise of my “Crash Test Alt”, I boogie with a top-hatted Simon Linden at the Server Beta meeting

SL Viewer Updates

RC Updates

The Second Life Share (SLShare) RC viewer has been rebuilt using the current de facto viewer release code and a new version – 3.6.8.282036 – on October 9th. This should see all of the current RC builds now rebuilt using the release viewer code base.

Mac Viewer  / OS X 10.6

The Mac 3.6.4 viewer which was offered to Mac OS X 10.6 users as a result of issues with the recent Cocoa updates impacting them has been closed, as the Lab believes all the important bugs on this issue are fixed.  Those who had either been rolled back to this release, or opted to install it, have been updated to the current release.

Interest List Viewer

The interest list RC viewer has yet to appear, although the code is available for those able to access it for self-builds. Two issues have been identified by those compiling the viewer. The first of these appears to be a known bug, SH-4552, wherein objects and linksets previously cached by the viewer fail to load following a teleport, and will generally only render following a relog (right-clicking where the object should be, as with the “missing prims” issue earlier in the year, does not work). The second causes objects to vanish from the user’s field-of-view until after a relog  if draw distance is reduced and then returned to its prior settings.

Whether either of these issues is sufficient to stop the viewer emerging as either a project or RC viewer remains to be seen. The code had been sitting awaiting the button to be pushed to move it into one or the other. It had been hoped that members of the team who have been working on the viewer would be available to discuss the viewer during the TPV Developer meeting on Friday October 11th. Unfortunately, they didn’t manage to attend.

Upcoming Viewers

Other viewers on the horizon include:

  • A further maintenance release, which may include Baker Linden’s Group Ban List code
  • Monty Linden’s viewer-side HTTP updates, which have been “snarled up” as a result of some rebuild dependencies.

Continue reading “SL Projects update week 41 (2): TPV developer meeting, group ban list, interest list”

Cocoa updates impact OS X 10.6 users

Update October 5th: The downgrade to viewer 3.6.4.280048 for those on OS X 10.6 has been made optional rather than mandatory, as the latest de facto release viewer (3.6.7.281793) contains fixes which address some of the issues users on OS X 10.6 were encountering. Those still encountering issues may wish to revert back to 3,6,4,280048.

Recent Cocoa updates to the Mac version of the viewer have led to problems for those running Mac OS X 10.6. Because of this, the Lab has opted to roll users on that version of the operating system back to an earlier release of the viewer – specifically version 3.6.4.280048 (August 20).

Commenting on the problems at the Open-source Dev meeting on Monday September 30th, Oz Linden said:

We found some obnoxious problems with the newer releases for users still on OSX 10.6. We’re working on getting them fixed … but in the mean time we decided that 10.6 users would be better off on the older version. We’ll be watching how many users it would affect, I’m sure.  Newer versions of OSX have significantly better crash rates, so if a user can upgrade, they definitely should.

Affected users should be automatically “rolled back” (so to speak) to this viewer release via the viewer update system. However, if you’re running OS X 10.6, experiencing issues and are running a later version of the viewer, you can manually download it here.

SL projects update week 39 (3): viewer, interest list, HTTP, SSA and more

The following notes are taken from the TPV Developer meeting held on Friday September 27th. A video, courtesy of North, can be found at the end of this report. The numbers in braces after each head denote the time stamp at which the topic can be listened-to in the video.

A typical TPV dev meeting
A typical TPV dev meeting

SL Release Candidate Viewers

SLShare

[03:00]

Following my coverage of the release of SLShare, the opt-in capability for those wishing to link their Second Life accounts with their Facebook accounts, A question was asked as to whether the feature would be available to TPVs. Speaking at the TPV Development Meeting, Oz Linden provided comments which answered this question more fully, and and Merov Linden gave further information on the functionality in general.

“One of the design considerations is that this is a feature you [TPV developers] can all integrate without any problem,” Oz said. “All of the actual connections to Facebook, all of the handling of the requisite authentication tokens and permissions and [the] relationship with Facebook itself, is all handled server-side. So the code that’s in the release candidate viewer is something that you can integrate so that you can also make this feature available on whatever schedule you would like to.”

He went on to confirm that given this, no Facebook information for users of the service is exposed to TPVs.

As to how soon it might be before the SLShare RC is promoted to the release viewer, Oz again reiterated that it depends on how well the various candidates currently in the release channel perform. Currently, the metrics for the viewer look good, according to Merov, so it may still leapfrog its way to becoming the release viewer. However it is more likely that it will not become the de facto viewer for at least another two weeks.

Despite the negative reactions to the feature which have appeared in the comments following blog posts, etc., reporting on the functionality, the Lab believes SLShare is already “getting a lot of use”. This view is based on the numbers of people who have pro-actively gone and downloaded and installed the RC viewer manually.

While this may be a case of the Lab greasing the wheels a little bit (downloading and installing the viewer isn’t necessarily the same as running the feature),  Firestorm are reporting that they’ve had at least one request for the feature to be added to their next release.

During the meeting, a series of questions were raised on the feature:

  • Will the feature become opt-out in the future, rather than opt-in? Merov Linden:  “It’s opt-in. We’re not doing anything [behind] the back of the residents.”
  • Will the feature create a Facebook account on behalf of anyone using it? Merov Linden:  “There is no API to create an account on Facebook on behalf of someone.”
  • Will it lead to a merging of the current SL feeds with the Facebook feed?  Oz Linden: ” No, there is no connection between the Second Life profile feeds and the Facebook feed. They have no relationship at all … In theory one could probably build a viewer that did that, but we’re not planning on it.”

(Further questions passed unanswered due to the region in which the meeting was being held being subjected to a griefing attack which left it in a poor state and prompted a change of meeting venue.)

Viewer Statistics

[33:26]

The Lab has been putting together a new statistics reporting system, which is now starting to be used to generate a range of reports. Commenting on some of the information which is coming out of the system, primarily in response to questions asked at both Open-source dev and TPV dev meetings, Oz indicated that:

  • Almost one-third of regions within SL have at least one materials-enhanced object in them, which is described as “dramatically faster” than the adoption of mesh
  • The number of avatars wearing materials-enhanced mesh / prim clothing is “steadily climbing”
  • The number of people who have Advanced Lighting Model (ALM) enabled on a “class 3” (mid-range Graphics cards) or above is just under 20%

One of the problems here – from the Lab’s point of view at least – is that both Singularity and Firestorm have ALM turned off by default for almost all graphics settings, except perhaps High-Ultra, and Ultra. The flip side to this is the view that the Lab enables ALM by default on cards which are barely able to support it, with the result that people’s SL experience suffers through poor frame rates.

In the past the Lab has pointed to data which tends to show that viewers running on low-end graphics cards card do indeed suffer performance issues with ALM active; mid-range GPU show little difference in performance between running with ALM active or not and have “reasonable” fps rates; high-end (“class 5”, as they call them) cards  – e.g. ATI Radeon HD 7800, 7900, 8900, 8950 + similar, nVidia GTX 460/460SE, 465, 550TI, 580, 660/660TI + similar – perform significantly better with ALM active.

The problems here are how one defines “reasonable” frame rates and how one interprets ALM. For the Lab, it would appear that “reasonable” frame rates is anything in double figures – e.g. above 10; many users would disagree with this. At the same time, many users still appear to equate having ALM active with having Shadows enabled (which actually leads to a far larger performance hit), but the two are actually quite separate. As had been pointed out a number of times in these pages, ALM can be active without having to enable shadows.

Running with ALM active does not require shadows to be enabled
Running with ALM active does not require shadows to be enabled

Nevertheless, part of the new viewer statistics system should enable to Lab to gather and present performance numbers for cards with and with ALM enabled, filtered by viewer, so that TPVs can better judge matters for themselves.  In addition, Oz is going to be looking at ways and means of doing systematic testing with cards in order to generate more meaningful statistics, and which may allow for other factors which influcence performance (other avatars in the same region, the amount of movement going on, viewer settings, etc.).

Understanding Viewer Performance

[45:41]

A further problem with the viewer is that it is complicated, and while there are many tools to help monitor performance, people either focus on the wrong tools or cannot find those that would be helpful to them in diagnosing an issue when they do encounter unexpected performance drops.

To this end, Oz floated the idea at the TPV Developer meeting for TPV devs to give thought as to which tools and information feeds within the viewer would be useful to users to help them understand what is going on, and how best to present said tools, etc., in a way which would make sense to users and enable them to make use of the information they are seeing.

Continue reading “SL projects update week 39 (3): viewer, interest list, HTTP, SSA and more”

SL projects update week 39 (2): Server, viewer, region crossings

Server Deployments – Week 39

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

  • On Tuesday September 24th the main channel updated to the server project that was on Magnum last week, with the llXorbase64 (see my week 35 (2) update ), a number of JSON updates, the nerfing of recursive rezzing (outlined in my week 35 (1) report), a parcel access update (see below) and more – see the release notes for details
  • On Wednesday September 25th, all three RV channels (BlueSteel, LeTigre, Magnum) received the same update package as deployed to the Main channel.

Parcel Access Update Bug

At the Server Beta meeting on Thursday September 26th, Maestro revealed that the parcel access update, designed to enable users who are on a parcel’s “Allowed Access” list now correctly bypass other parcel restrictions (such as “Payment Info On File”) when entering the parcel, introduced an unexpected bug. He it as:

If you have a group-owned parcel, and the parcel access is restricted to group members, *and* “sell passes to..” is set, then group members can’t access the parcel, which isn’t good. My guess is that nobody noticed in RC because “sell passes to” isn’t widely used.

The classic behaviour was this one motorcycling sim had it set up; you could either join the group for L$300 and have permanent access to their roads, or alternatively pay L$100 for a one time pass to visit … With the bug, even the group members couldn’t access (though oddly they weren’t prompted to buy a pass either – entry just failed). It may have been that the viewer expected the classic behaviour, so didn’t prompt about a pass. Anyway, we do have a pending fix for the issue.

Maestro Linden's new meeting venue (complete with materials), which saw its debut at the Server Beta meeting on Thursday September 26th.
Maestro Linden’s new meeting venue (complete with materials), which saw its debut at the Server Beta meeting on Thursday September 26th.

Week 40 Deployments

While the final decisions on deployment packaged are not made until the start of the week in which they are due, Maestro Linden gave a hint of some of the items liable to see the light of day in week 40 (week commencing Monday September 30th)

  • A further LSL update for JSON support, which will see JSON_DELETE added as an option to llJsonSetValue() and allows you to delete an element directly
  • A fix for a group notice bug which causes a notice (possibly only in some groups, it’s not entirely clear) randomly failing to reach some group members

Commenting on the latter, Simon added, “That group one is kind of minor. There still seem to be issues with groups, even with this fix, but it may help … Group notices have gotten more reliable lately, thanks to Monty’s http work, I think, but I’m still hearing of notices getting lost sometimes, or the sender not getting one.”

Maestro also confirmed that there is a separate bug related to offline notices failing to reach people’s e-mails, with some at the meeting reporting they haven’t received any off-line notices for the past month.

SL Viewer Updates

On Wednesday September 25th, the Lab launched SLShare, and with it introduced a new RC viewer – version 3.6.7.281331 – with the new OPTIONAL share with Facebook capabilities.

The four tabs of the new SLShare floater, allowing people to share their SL times via their Facebook account if they so wish
The four tabs of the new SLShare floater, allowing people to share their SL times via their Facebook account if they so wish

Continue reading “SL projects update week 39 (2): Server, viewer, region crossings”

Linden Lab launches SL Share and a look at the viewer

As spotted by Daniel Voyager earlier in the month, and reported here as a result, the Lab has now officially launched SLShare, which they describe as, “an easy way to share to Facebook while In-world.”

Now, before people start getting all worked-up about Facebook, being “outed” and generally getting knickers knotted, there are a couple of points which need to be understood:

  • SLShare is opt-in. If you don’t want to use it, you don’t have to, you can ignore it
  • SLShare will only work if you actually have a Facebook account – so LL aren’t doing any “sneaky back-door outing” or “forcing” anyone into Facebook.

The blog post announcing the feature reads in part:

SLShare is a new, 100% opt-in Viewer feature that will allow you to easily update your Facebook status, share photos, and check-in from Second Life locations to your Facebook wall.

Whether you’re at a great in-world event and want to let your Facebook friends know where to join you, want to show off a photo of your avatar modeling your latest Marketplace purchase, or just share a thought inspired by your in-world explorations, SLShare makes it easy to share pieces of your Second Life experiences with your Facebook network.

The blog post also notes that the feature “isn’t yet available for everyone”, however, the release candidate viewer with the SLShare capability – version 3.6.7.281331 – can be downloaded via the SL wiki.

If you do opt to manually download the RC viewer, note that it will, by default, overwrite your current release version of the SL viewer (if installed), so please see my notes on manually installing RC viewer versions if you wish to avoid this.

As noted in my original report, the Facebook capabilities are contained in a new floater, accessed via Me > Post to Facebook …, which in turn comprises four tabs.

The four tabs of the SLShare floater
The four tabs of the SLShare floater

The tabs are:

  • Status tab:  allows someone to post a text comment via their Facebook account
  • Photo tab: allows someone to upload a snapshot to their FB account. As with the current Profile Feed option in the snapshot floater, the resolution of the image can be selected at upload (minimum 800×600), and an optional SLurl / comment can be included with the image
  • Check-in tab: allows someone to share the SLurl for their current in-world location via Facebook, together with a short comment on the location and a map image if they wish
  • Account Tab: will allow those with a Facebook account to connect their SL account to it for the purposes of posting from SL to Facebook.

The last option will open a browser window allowing a user to log-in to their Facebook account and link their Second Life account to it for posting purposes (this must be done for any of the other tabs to actually communicate with a Facebook account). In addition, to make accessing the floater easier, the viewer introduces a dedicated Facebook toolbar button.

To help explain the new functionality, Torley has produced another of his TuTORials, and there is also a Knowledge Base page explaining the capability and its options.

Again, please remember that this is an opt-in capability, and no-one is being forced to use it. Whether SLShare will evolve to include other social media sharing, or whether additional capabilities for sharing with other social media platforms will be added to the viewer remains to be seen.

In the meantime, SLShare is available via a release candidate viewer, as noted above, and will be progressing as the de facto release viewer in due course.

Related Links