Firestorm 4.4.1: It’s time to update

firestorm-logoUpdate July 2nd: version 4.4.2 has been released by the Firestorm team, and Firestorm 4.4.1 has been blocked from accessing Second Life. If you have previously installed Firestorm 4.4.1, you can install 4.4.2 without needing a clean install. If you are updating from Firestorm 4.4.0 or earlier, a clean install is strongly recommended. The downloads can be found on the Firstorm website.

Firestorm 4.4.1(.34164) arrived as a release on Thursday June 27th. This is another major update to SL’s most widely used TPV, and one which all Firestorm users should update to sooner rather than later.

The reason for this latter comment is one which should be familiar to anyone who regularly reads this blog – Server-side Baking / Appearance (SSB/A) is a-coming.

Subject to final confirmation, the Lab plans to start deployment of the server-end of the capability on July 9th, and while it might take a while to encompass the entire grid, it will mean that anyone using a pre-4.4.0 version of Firestorm is going to start seeing increasing numbers of grey avatars around them as they travel the grid and (quite likely) finding themselves being told they are a cloud when seen by others.

Updating sooner rather than later will also greatly assist those volunteers who give up copious amounts of time to help with the in-world Firestorm Support groups. Right now, the Firestorm team estimate more than 77,000 users are still running versions of Firestorm older than 4.4.0, and thus have no SSB/A capabilities. It’s going to be impossible to supply all of these users with support and advice if they all leave updating their viewer until the 9th July or later – so please, if you are reading this review and you are using a version of Firestorm older than 4.4.0, consider updating now.

Doing so means that should you need to contact the Firestorm support team directly, because you are encountering problems and cannot find help through the Firestorm wiki or the troubleshooting index, you’ll be far more likely to receive a timely response to your request for assistance.

Even those who have updated to 4.4.0 should make the move to 4.4.1, as it includes the very latest updates and fixes for the SSB/A code from LL. Outside of SSB/A, release offers a number of important fixes for 4.4.0, and so it’s again important for 4.4.0 users to step up to 4.4.1 to gain these benefits.

As always, there is a lot to cover in a Firestorm release, so I’m not going to plough through everything here – the official change log provides a breakdown of all updates and fixes. Instead, this review focuses on what I regard as the key updates / changes. As always, credits for the various updates and contributions to Firestorm which are mentioned here can be found in the release change log – again, please check them there.

What is NOT in this Release

I’m actually going to start with what is not in the 4.4.1 release. It does not include the following major updates from the Lab:

  • The Communications Hub User Interface
  • Materials Processing

The reasons for this are simple. For one thing, the Firestorm team have been largely focused on fixing issues and problems with Firestorm and on getting the viewer ready for the SSB/A release. This  left them with little time to get changes resulting from the CHUI release by LL integrated into the viewer, although considerable work has been carried out in refactoring the code.

Similarly, there is no Materials Processing capability included with this release. This is in part because the Lab themselves have only recently moved the materials code to a release status (and it still has a number of very visible bugs associated with it), but mostly because changes made to the viewer as a result of the introduction of CHUI affect files which are also changed by the materials project. It is therefore important that the Firestorm team implement the changes in the same order – changes as a result of CHUI first, then the materials changes.

So those wanting to use materials in Firestorm are, unfortunately, going to have to wait a while longer.

New Features and Improvements from the Lab

Note these also include work by the Firestorm team arising from LL-development viewer updates.

  • “Missing prims fix” – MAINT-2647 / BUG-2116 / FIRE-8950 – this should hopefully resolve the majority of issues around prims / linksets failing to render in the viewer until an action such as right-clicking on them or toggling atmospheric shaders off / on is taken
  • Merge up to 3.4.5 codebase plus cherry picked fixes plus server-side appearance support improvements
  • Major under the hood refactoring in preparation for the CHUI merge
  • Added RegionHandshakeReply flags for Server-side Appearance – a fix for the SUN-74 issue.

Snapshots Fixes

Firestorm 4.1.1 includes an interim fix for the issue of black rectangles appearing in snapshots taken at very high resolutions. Note that this fix is not the recently released additional fixes arising from MAINT-628 made by Linden Lab. These fixes will be included in an upcoming release of Firestorm, and so the current fix should be considered interim.

Communications Updates

Radar can now be accessed via its own button / menu option / floater for those who prefer not to access it via the People floater. The new button can be selected from the Toolbar Buttons floater, which will open the new Radar floater. Additionally, Radar can be accessed via World > Radar from the menus.

The new Radar floater (left) and optional Toolbar button, compared to Radar as it appears in the Nearby tab of the People floater
The new Radar floater (left) and optional Toolbar button, compared to Radar as it appears in the Nearby tab of the People floater

The Radar retains all functions found when displaying it in the Nearby People floater, including the ability to display the mini-map within it.

The Payment icons on the Radar / Nearby People floaters have also been updated: $ indicates the user has Payment Information on File; $$ indicates Payment Information Used.

For those who use the Friends list (Comm > Friends or CTRL-SHIFT-F), highlighting a person’s name in the list and then tapping ENTER will start an IM conversation with that person (no need to click the IM button).

For those who use Growl, dialogue messages and inventory received from object messages are now displayed with Growl. In addition, all Growl preferences check boxes will only be enabled if Growl is installed on the user’s system.

Navigation Updates

Beacon distances are now shown for the
Map beacon ranges now show the distance from the avatar, not the camera

Firestorm 4.4.1 removes the 2-second delay when using the click-to-teleport functions or teleport chat shortcuts (gtp, etc.) or the Teleport To function in Radar.

A new option allows region grid coordinates to be displayed on the World Map (Preferences > Move & View > Firestorm > Show grid coordinates on the world map), which OpenSim users might perhaps find more beneficial than most SL users.

Also, map beacon ranges now show the distance from the avatar, not the camera.

Building  and Scripting Updates

Firestorm 4.4.1 brings a good number of updates for builders and scripters, including:

  • Copy Keys button on the Build floater has been revised so that:
    • By default, clicking the Copy Keys button on the build tool will now only copy the object’s root key
    • Hold SHIFT to copy all keys when clicking the Copy Keys button
    • If an individual prim is selected in a linkset, Copy Keys will copy only that prim’s key
  • If the user hasn’t set an external script editor, the operating system will open whatever it thinks is the editor for LSL files
  • LSL editor support for new and already missing content type constants has been added, together with missing LSL editor constants for llGetObjectDetails and missing strings for avatar script info (neck and avatar center attachment spots)
  • LSL script editor support for the new json functions and constants has been added

Backup Updates

Firestorm 4.4.0 saw the introduction of the Backup Settings function (Preferences > Backup) which allows users to back-up many of their global and account settings to a local hard drive. Firestorm 4.4.1 adds two additional features to this capability:

  • Restoration of Cache Path from a settings backup
  • Restoration of Custom port setting from a settings backup

Full details of the Backup Settings functions can be found in the Firestorm documentation.

Phoenix-derived Updates

Firestorm 4.4.1 gains the Avatar Textures floater from Phoenix. This can be accessed by right-clicking on an avatar and selecting Show Textures from the Context Menu, or for those using the Pie Menu, either right-clicking on their own avatar and selecting Textures or right-clicking on another avatar and selecting, More > More > Textures.

Avatar Textures floater
Avatar Textures floater

In addition, the following options are also ported from Phoenix:

  • The “Nick auto complete” feature (Preferences > Chat > General > Enable automatic name prediction in nearby chat bar) so the viewer will attempt to auto-complete a name based on the names of those near you
  • Region script count change notification feature (Preferences > Notifications > Notifications > When the region’s total script count changes & set threshold) displays a message if the total number of scripts in a region suddenly jumps (up or down), according to the threshold set
  • New option to minimise floaters to bottom-left instead of top-left (Advanced > Debug Settings > FSLegacyMinimize > Set to TRUE for bottom left behaviour)

Some of the Rest

As noted earlier, the best place to get full details of the 4.4.1 updates is from the release change log. However, here are some of the other updates people might want to check-out

  • Need help? before you contact the in-world support teams, try going to the Firestorm troubleshooting index by clicking om Help > Troubleshooting in the menu bar?
  • Hearing an annoying sound? Add them to your Asset Blacklist (World > Sound Explorer > Blacklist or World > Blacklist)
  • Like the music stream being played and would like it?  World > Parcel details > Sound >Copy music stream URL to clipboard
  • Search updates:
    • Searching in inventory search box now expands folders
    • Searching from the navigation bar search option now always opens the Web search tab and a lot of code refactoring and improved layout for less screen wastage
  • There’s a new Black Glass skin theme for Meta Harper Modern (Preferences > Skins > MetaHarper Modern > BlackGlass) and various custom skin improvements
  • Inventory context menu Touch option: If you are wearing any scripted items which respond to touch, right clicking on the item in any inventory tab (Inventory, Recent, Worn), will display a Touch option in the context menu (allowing you to open the item’s menu, for example)
  • New switch to automatically remove the temporary upload option when on a SSB/A region: SSB/a will not support temporary texture uploads (which relay on a viewer-side hack). To prevent error messages resulting from attempts to upload temporary textures when on an SSB/A region, this function will hide the temporary upload options from the relevant floaters.


  • Metropolis Metaversum and UFS Grid to the default grid list
  • Register hop: links with Firestorm on windows
  • Pathfinding disabled icons are now hidden on OpenSim grids
  • The snapshot to profile panel hidden when connected to non-SL grids
  • Minimum listing fee for classifieds and parcel directory fee are no longer hardcoded on non-SL platforms.


While containing a lot of updates, including many fixes and stability improvements, Firestorm 4.4.1 is more an evolutionary update release than has perhaps been the case with previous releases of the viewer. This doesn’t lessen its importance for Firestorm users, however, because it does contain much of value and importance – particularly around the matter of SSB/A, as has been mentioned.

For Phoenix users, there’s again more added functionality to give more of a Phoenix flavour and familiarity to the viewer – especially when running it in the Phoenix mode. Given there are no plans to implement SSB/A support for Phoenix, it is even more imperative that users on that viewer look towards updating their viewer choice before July 9th. Firestorm’s Phoenix mode  offers an experience which is now largely on a par with Phoenix (items such as menu names and options allowing), and this release takes that a step further. For who are interested in giving it a go, there is even a video available to help Phoenix users make the switch.

However, if Firestorm / v3-style viewers aren’t to people’s liking, it is important to remember that both Cool VL viewer and Singularity provide SSB/A support and offer a v1-style UI.

For Firestorm users, there really isn’t any excuse not to update to 4.4.1, and hopefully many of those 77,000 using versions older than 4.4.0 will heed requests that they do so sooner rather than leaving it to the last-minute on the 8th or 9th of July.

Certainly, coming on top of the huge number of additions and updates made to Firestorm with the 4.4.0 release in April, 4.4.1 is a more than worthwhile update which offers a lot of goodies and treats.

Related Links

11 thoughts on “Firestorm 4.4.1: It’s time to update

  1. Excellent post. The one thing I would add, and it is not specifically Firestorm related is a warning: If you are using old/marginal hardware it is time to upgrade! Once LL implements SSB the minimum hardware requirements *will* change.


    1. I don’t see any reason whatsoever why SSB/A itself would force any change to minimum hardware specs. Your computer isn’t having to do anything more than is currently the case with local baking. There are many very good and pertinent reasons for people who want to use SL and who are on marginal hardware to update, but I’m really not convinced that SSB/A shoudl be flagged as “the” reason.

      One could perhaps better argue that things like materials processing, etc., will actually put far more of a load on the local computer in that respect (new maps to handle and render, the need to run deferred rendering – aka Advanced Lighting Model – in order to see materials in action, etc), which would require some to consider hardware upgrades in order to take advantage of such capabilities.


      1. Some people are still using CPUs that do not support SSE2.
        A graphics card that supports OpenGL 3.3 is necessary to see mesh, so that might also be considered a minimum requirement.


        1. Yup. There are plenty of very valid reasons for updating old hardware – I just don’t agree that SSB/A is one of them.

          Most of the established reasons pre-date it by a long shot, and as mentioned, in terms of emerging capabilities, materials might be said to be more of a strain for old hardware to manage than SSB/A.


        2. I would even say that SSB/A is to reduce the CPU load associated to baking the textures locally. Materials are going to add load to the general hardware, though.
          I really pity non-SSE2 users.


  2. It surprises me a bit that the Firestorm team hasn’t started up some official forums. When their only form of interactive support consists of live people in-world, it’s no wonder they’re worrying about being inundated.

    Forums allow one to many support in a searchable way, allowing people to see if anyone else has had a similar experience. It also introduces a viable way for people using OpenSimulator based worlds to get help or give feedback (or help the team out; there some smart cookies out there!), as it’s clearly unreasonable to expect the Firestorm team to create groups on every grid, even the more popular ones.


    1. Forums have their pluses and minuses. On the plus side, they provide a means of searching of support issues – but so does am open JIRA and maintained troubleshooting index, both of which Firestorm have.

      Forums allow for more interaction and for users to help one another, but they also require moderation and management, which can become a handful and time-consuming. They can also become places where frustrations are vent and cliques form (take a look at the SL forums!).

      A JIRA provides a good, centralised means of logging issues which can be indexed and searched and which allow user feedback / input. The downside is that it requires account creation, which many users may find off-putting, and so they avoid using it even as a means of simply looking-up information.

      The good thing about in-world group support is that it provides immediacy which a forum cannot match (unless you have the resources to monitor all posts as they arrive). Most questions are readily dealt with, and the format does allow other users to provide assistance with common problems as well as the group support staff. The downside is that there will be periods when the group is awash with demands and requests for help, and people will be stretched.

      So, it’s probably six-of-one / half-a-dozen of the other. As it is, the current set-up seems to work for Firestorm and their SL users. I suspect they’ll adapt their strategy should major failings / holes ever appear :).


      1. I think the in-world support groups are fantastic, for all the reasons you’ve given. It’s really super that FS has them, and they should pat themselves on the back for this.

        JIRA really is not a replacement for forums. A bug tracker is really supposed to be confined to actual bugs or development. It’s a horrible venue for technical support, and 99% of developers hate it when users attempt to use it in this fashion.

        The actual truth is, I’m not a fan of forums. I don’t tend to use them if something else is available. I’ve also experienced how thankless and frustrating it can be to moderate large forums first hand. But they do have some very real virtues. They’re more topical and responsive than a wiki. They allow support personnel to avoid having to address the same questions again and again. A live support group needs to be staffed by volunteers 24/7 where forums allow those volunteers to chime in on a more casual basis. They often highlight the most common issues, and provide quick fodder for the enhancement of wiki documentation.

        Speaking very selfishly as an avid OpenSimulator user, there is no non-SL support avenue available that allows users to interact with the FS team. The FS JIRA is not an appropriate place for most user discussion, and the #phoenixviewer IRC channel is an empty wasteland. They do not hold regular meetings on any non-SL grid. That’s discouraging. 😦 Forums strike me as possible method to assist all of FS’s users, not just the ones in SL.


        1. I’m not saying the JIRA is a replacement for a forum – I’m saying it’s there, and it works – not only for reporting bugs but as a reference as to what has been reported and what is being done about it. That’s why there was such an outcry over the SL public JIRA being largely closed to general access – people used it precisely because it was such a useful reference piece.

          But as a discussion place, no, a JIRA is not the right environment, and I apologise if I gave that impression, as it is not what I was meaning. I was talking purely in terms of it being a resource for finding out information, used alongside things like the FS Troubleshooting page (and, indeed, the wiki). Hence why I confined comments on interaction to speaking about the in-world groups.

          As to Firestorm not having non-SL support – that’s a harder nut to crack. The majority of people involved in FS development and support are, I believe, primarily (if not fully) engaged in SL and are not deeply rooted in OpenSimulator (and so poissinly themselves not best placed to address OpenSim issues coming from what would be a wide variety of grids, some possibly running their own flavours of OpenSim, others having their own quirks impacting the viewer, and so on and so forth. Hence why Jessica was so clear about Firestorm’s OpenSim work when they opted to try and provide viewer for both sides of the divide. However, this is only my view as an outsider – Jess or someone from FS may drop by and tell us both otherwise :).


Comments are closed.