Firestorm warns: “be careful what you wish for”!

firestorm-logoPssst! The next release just might have group bans after all!

Jessica Lyon, project manager for the Firestorm team has officially announced the upcoming release of the next version of SL’s most popular viewer, although no actual release date is given.

A new release has been hinted at several times over the last few weeks, and the team is working hard to keep to a 3-monthly release cycle. At the moment, the upcoming release is focus of the Firestorm QA team and is being poked at by beta testers.

Releasing a viewer isn’t necessarily straightforward as might be thought; new features and shiny have to be measured against current code status, stability, and so on, and bugs and their fixes must be weighed against the opportunity to add new shiny or not. All of this made for a balancing act for all concerned; one in which  – especially given the size of Firestorm’s user base – not everyone is going to come away happy when a release arrives.

There have been a lot of updates flowing out of the Lab during the past year, many of which have yet to find their way into Firestorm. But as Jessica notes, stability tends to win-out over trying to crowbar everything into a viewer release:

Firestorm is not, and has never been, a “bleeding-edge” viewer. We have always focused on quality over quantity, stability over shiny. Slow and steady wins the day. Despite complaints and objections, this strategy has helped make Firestorm the most widely used viewer in Second Life by a long shot. In code, almost anything new has bugs and kinks that need to be worked out regardless of who wrote it and how vigilant they were at it. That’s because despite how much testing you do, it isn’t until it lands in the hands of the many that the deepest rooted software glitches start to crop up. Knowing this is one of the reasons we do not merge in and release new features from Linden Lab right away.

While the updates coming out of the Lab have all be to the good, they’ve also not been without their own problems. The AIS v3 code updates, for example, resulted in some od bugs and issues of a non-trivial kind, some of which have only recently been fixed in the new Attachments RC viewer (version that appeared on Wednesday, November 5th. And while the CDN and the HTTP pipelining viewer have brought improvements to the majority of SL users, they also have generated some issues.

The SL Share 2 features for sharing photos with Flickr and Twitter, and adding post-process filters to images, will probably not be in the next release of Firestorm
The SL Share 2 features for sharing photos with Flickr and Twitter, and adding post-process filters to images will probably not be in the next release of Firestorm

The upshot of this is that while the upcoming release of Firestorm will have new features, bug fixes and improvements, in order to keep code merges, etc., as straightforward as possible and avoid issues which may arise from cherry-picking features and updates from different LL releases, Jessica warns that when released, the new version of Firestorm will be without AIS v3, HTTP (although obviously, it will work with the CDN, just as all viewers do already), SL Share 2, and may not have group bans.

But it’s not all bad news, as Jessica notes:

But we absolutely will have plenty of other features, bug fixes and improvements worth updating for to which I’m very excited about!

Testing is still underway, so it will be another few weeks, most likely, before the new Firestorm release appears. When it does, if you’re a Firestorm user, please do keep in mind that if the feature you were really looking forward to isn’t in the release, it doesn’t men they’ve forgotten it or are ignoring it; they’re just trying  to bring you the best, more reliable experience they can whilst trying to avoid showering you with unwanted bugs and issues.

I’ll of course have the usual review of the release when it appears.

18 thoughts on “Firestorm warns: “be careful what you wish for”!

    1. So where are your fixes for all of those major appearance related bugs? Oh, thats right, Alchemy has them too, as well as the rest of the mountain of LL bugs Alchemy inherited that you haven’t fixed yourself either except for a couple of piddly little Mac bugs.


        1. I have, and my point still stands. Very little in the way of fixing LL bugs. The vast majority of your work has been additional features/functionality and bugfixes for TPV added features/functionality, not fixing LL bugs.


            1. Hardly any, just like you as well as the FS team. However, you were the one being a hypocrite by bringing up this topic and trying to use it as a sleight of hand insult to the FS team on the very first post of a very nice and informative blog about their upcoming release.


  1. Thank you Jessica Lyon, for all your work.
    The only reason I am able to run “second life” on my computer, is because of Firestorm.

    Linden Lab’s technical support took remote control of my PC, updated several things, installed software, removed and clean installed all of the second life software, after three days, could not figure out how to get my Desktop PC to run “Second Life”.

    A year later, a Firestorm support woman (Katy), had me downloading “Phoenix Firestorm” and running SL in under fifteen minutes.

    Take your time Jessica, you clearly know what to do.


    1. Good to hear that the FS support team were able to help you – but you might want to leave the feedback on the Firstorm blog, as Jessica is more likely to read it there :).


  2. Performance wise and when I explore, I tend to use the LL Viewer now, but being used to Firestorm features since its early betas (and Phoenix before it), I miss some handy feature. It seems like not so many people use or even know about all those features or little tricks, but stability is appreciated. Besides QA, it sounds like its complex to merge the code with Firestorm. And Firestorm still has its own annoying bugs though, and for a long time now, such as these, that don’t happen on the LL viewer:
    I hope they will fix them as well.


    1. is a bug on the Linden viewer too, see
      The cause is having many chat logs or large chat logs stored on your computer. If you remove or reduce the number of stored chat logs, the problem will be gone. So it is very possible to only see the bug on one viewer because chat logs are stored in seperate locations by default on each viewer.
      This bug started with the CHUI code.
      This bug isn’t fixed yet on either Firestorm or the official viewer.
      Ansariel (Firestorm dev) made some changes which improve the problem but dont fix it totally. Her fix was contributed to Linden lab. is Firestorm specific yes. Its caused by the script dialog stacking changes. The first time a script dialog opens each session you may get a few seconds pause but subsequent dialogs opening that session should be okay.
      This bug isn’t fixed yet.

      Liked by 2 people

  3. For all the valid reasoning behind Jessica’s list of things that won’t be featured in Firestorm’s next release, it’s still a pity that they won’t be; I think I’ll especially miss all the download performance improvements (Pipelining, CDN and AIS v3). I try cheering myself that, in exchange, we’ll have all those new features she talks about, but I can’t help notice that she doesn’t even give as much as a hint what they are (yes, I know I could look at their JIRA), which in itself is strange… focusing plenty on the negatives and barely offering any positives. It’s almost as if they’re giving us now the “downer”, so that we all moan and complain and then set our minds to expect nothing, so that when they announce the actual release with whatever new features they did manage to include, people will have already gotten over the disappointment and will receive more cheerfully the new release and its improvements. Here’s thinking Jessica and her team have become quite skilled at PR tactics, lol 😀


  4. I just wish to know when it will come the time as kokua, firestorm will have a dif version for open sim. For now with the ll code not being put in place at least we will be able to keep using 1 viewer, all grids, but there will come the time when firestorm will have to release 2 diff versions.


  5. Recently I have been using LL’s viewers, instead of Firestorm. The reason? The tremendous performance increases, which are staggering. Sure, I know that there is a lot of work done ‘under the hood’, some of which is ‘invisible’, and some which will trickle down to Firestorm… eventually!

    But right now, LL beats FS quite easily.

    Alas, if it didn’t have such a clunky interface, compared to FS… once you get used to the more logical way that FS works, it’s hard to go back to LL…

    And, of course, for my OpenSimulator work, I have no choice but to stick to FS 😉


    1. Yup, I have to agree – I find the LL viewer tends to beat FS hands-down when I’m filming machinima. The perfromance differential is clear, particularly when using flycam movement, which can often se frame rates tumbling. And despite the amount of time I spend using the LL viewer and others that have retained more of its look and feel – it drives me bonkers as well.

      Liked by 1 person

  6. The HHTP pipelining omission may be problematic for the Firestorm team from what I’m reading in different forums.

    However as Jessica points out in the post, they can’t merge code out of order and to include HTTP pipelining they’d have to include other features which they aren’t happy with, it’s a very difficult situation to be in.


    1. HTTP is the icing on the cake; Firestorm can obviously still utilise the CDN support without issue (already is), so the hit shouldn’t be too critical at this point in time. Obviously, if the Lab make further tweaks directly to the viewer-side HTTP code as a result of continuing to dig into the problems on the CDN side of the equation, then it might impact FS, or they might be able to pick all of the HTTP changes “as one” when they get to them.

      Merging code is a problem; some viewer teams cherry-pick, others don’t. Firestorm prefers to take the approach of sequentially adding major updates in order to try to minimise problems down the road in taking code (or parts of code) out-of-order, unless the code has very little chance of messing with something else. Given their user base and the need to keep as many people happy as possible, it’s an understandable approach.


Comments are closed.