Second Life’s Third Party Dev’s News Week 28

Project Viewers

Second Life Project Notice Viewer version – July 8 – From the release notes: (paraphrasing) A new Notifications floater separates incoming notifications into; System, Transactions, Invitations, and Group notices. This provides a better way to view, interact with, prioritize, and manage incoming notices, especially for busy residents.

The Lindens are giving a special thank you to Aki Shichiroji for initial feature design on this feature.

This is a PROJECT Viewer, so now is the time to provide feedback. If you deal with a lot of notifications in your use of SL, this is the time for you to try this viewer and provide your input on how it works and what may need to change. Be sure you include your use case that supports your recommended change.

Whirly Fizzle and Jessica Lyon like this feature… both are sane users that I class in the power user group. So, I consider theirs a decent endorsement of the feature.


You may know that how avatar game damage is reported and when it is scored is incoherent. At this point the Lindens are working on fixing it. That means how it works now is not exactly what was intended.



People have noticed that in the recent Linden viewers damage is accumulated while in safe no damage areas. In some of those areas damage accruing is not being reported. An avatar just surprisingly is teleported home because of damage sustained with no clue what is happening.

Interest List

Third Party Dev’s think parts of the interest list are broken. The interest list tells the viewer what to download and render. It has a priority system so that the things nearest you and in your field of view download and render first. That has not been working so well in recent releases.

However, to fix the problem the Lab needs to see cases of the problem and to have the steps needed to reproduce the problem. That they are not seeing the problem tells us something about their use of Second Life.

We use SL more than they do, so we are more likely to run into the problem. Thus we need to provide the information. Getting the Lindens to spend more time in SL searching for a nebulous problem takes away from productive work time.

One of the big problems to solve in determining where to start looking for the problem is learning whether interest list messages are not being sent, failing to arrive, or being poorly handled by the viewer verses whether the asset downloads are failing and slowing the render process. On screen either would look about the same, I think. So, I think this moves the problem search into the geeks realm.


BUG-7084Prim properties visually revert to an earlier state since Interesting.

BUG-9487Avatar Shapes failing to load e.g. (Missing/corrupt shape in inventory). In this one it looks like the shape asset is being corrupted. But, it is unclear whether the asset is corrupted during editing in a laggy region (unlikely) or the local inventory pointer or cached copy of the item is being corrupted.

To fix the problem reliable steps to reproduce the problem are needed. When the steps are not reliably consistent it is almost always because some factor is being missed/omitted.


*If you contribute to the JIRA on this attachment issue make sure you can reproduce the problem in the RC Big Bird Viewer. Reproducing it in any other viewer is not really helpful. If you report the problem in the Firestorm JIRA THEN use Firestorm.

4 thoughts on “Second Life’s Third Party Dev’s News Week 28

  1. “Nor is it reasonable to have the Lab slow or delay a release for a third party viewer, even Firestorm.”

    I. Sure. Hope. So.

  2. ‘Third Party Dev’s think parts of the interest list are broken. The interest list tells the viewer what to download and render. It has a priority system so that the things nearest you and in your field of view download and render first. That has not been working so well in recent releases.’

    I’m afraid the said ‘third parties developers’ did not quite understand how the interest list works, then… In fact the server now sends the *full* list of objects present in a sim to the viewer regardless of the current avatar position and camera field of view (the server therefore doesn’t ‘tell’ anymore anything to the viewer about what should be rendered or not, even if it does prioritize the sent objects data based on the avatar position and draw distance), and it’s on the viewer side that the actual decision is made to display a specific object or not, with the ability (which is quite a change with what happened in former viewers) to dynamically load-into/unload-from memory each object (re-loading happening from the viewer objects cache) depending on the field of view and on the distance of each object from the camera. While the latter algorithm indeed seems to suffer from bugs, they are viewer-side bugs, not server-side ones…

    ‘ [the Lab is] not seeing the problem tells us something about their use of Second Life.’

    Indeed !… I can only *strongly* second that point, which is one of the major issues we got since LL exists (but perhaps in the very first months, when only Philip and a few Lindens were responsible for coding: I was not yet there in these blessed days, by lack of free accounts and a Linux viewer, so I can’t swear on it, but that’s a reasonable guess).

    Lindens shall be *forced* to use SL as a ‘lambda’ user at least 8 hours a week, for RPing, exploring, building, do whatever they fancy in SL, but *not* program (or only in LSL). THEN, and only THEN, would they be able to get the slightest grasp about how some changes they so far forced down our throat are totally, irremediably, broken for our use cases !
    Perhaps, then, would LL’s official viewer recover the first place in the SLers’ viewer choice that it long lost and, perhaps, the SL users base would grow again…

    • You forgot one thing.

      There is Firestorm. As long as there is a Viewer that has so many features that no featurelist of this world can count them all, as long as there is a Viewer that caters to everyone no matter how potato his hardware is, as long as there is a Viewer that will always promise you to be faster, better, more stable than all the others there will be no logical reason to use the default Viewer. I mean, logically they are right: Why taking the default Viewer if you can take a Viewer that has a lot more features, promises to run better and for everyone? Logically seen i would never use a Viewer that offers less. I’m guilty of this too, i would never play an unmodded Skyrim if i get the choice between one and a modded one with lots of additional content, changes, features and better graphics. In Second Life though, this has become a negative impact on Second Life itself. I’m pretty sure that Firestorm had an impact on LL’s decision several times already, most of them negative and for personal gains.

      I have a suspicion that as long as a Viewer like Firestorm exists, may it be the current version or any potential forks of it (if the original didn’t exist anymore) there will never be a reason for most users to use the official Viewer and this results in much less reason for LL to do anything regarding their Viewer.

      • I can’t fault your reasoning. But, as to the Lab having no reason to improve their viewer, the empirical evidence says you’re wrong.

Leave a Reply

Your email address will not be published. Required fields are marked *