Update
April 29th: Don’t forget my additional piece on the new cloud options in Firestorm 4.4.0.
Firestorm 4.4.0.33720 made its formal debut on Monday 22nd April, although it has been well and truly put through its paces by both the Firestorm beta testers and the preview group for some time now, in order to ensure it is as ready for mainstream release as possible. It includes a huge number of updates and revisions, both from the Firestorm team and their contributors and from Linden Lab.
Given the size of the release, this is not intended to be a review of absolutely everything within Firestorm 4.4.0 – please refer to the release change log for that. 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 re mentioned here can be found in the release change log – again, please check them there.
Server-side Baking /Appearance Support
Note that this item is Second Life-specific.
This isn’t actually a visible change to the viewer in term of UI, etc., – but it is an important one.
Server-side Baking / Appearance is a major change within Second Life which is primarily aimed at reducing or eliminating issues of “bake fail” (when the avatar skin & clothing layers fail to render correctly and with remain blurred or show the avatar wearing the “wrong” outfit). This capability is being introduced in two parts: viewer-side support and server-side support.
Viewers which do not have the viewer-side support will not work with the Server-side Baking / Appearance service once it starts being deployed on the grid – people using them will increasingly see grey avatars around them. Therefore, it is essential that Firestorm users update to Firestorm 4.4.0.
For further information on Server-side Baking / Appearance, see the following blog posts:
Preferences Updates
This release sees a large number of Preferences updates, all of which are reported in the change log, and which include:
- Chat:
- General: new option to select display name format for IM tabs – a drop-down list of: Display Name, Username, Display Name (Username) and Username (Display name)
- Notifications: a new option to Show group chat in chat console (useful if you opt to hide chiclets – see below); new drop-down option for IM receipt sounds: Play sound only if not in focus
- Graphics:
- General: the Quality and Speed slider incorporates additional settings (Low-Med, Med-High and High-Ultra); Lighting and Shadows is renamed Advance Lighting Model (as per the LL viewer); the Depth of Field check box is moved to the Depth of Field tab; the Windlight Sky Detail slider and the Avatar Physics slider swap positions
- Rendering: Max number of concurrent HTTP GET requests slider removed; check box to Enable rendering of screen space reflections added
- Sound and Media > General: uses radio buttons to show stream title notifications in chat, toasts or to be turned off
- Move & View:
- View: new check boxes to: disable the mouse wheel from controlling camera zoom; Show user interface in Mouselook; Enable context menus in Mouselook and Leave Mouselook after regaining focus
- Firestorm: new check boxes to Reset camera position on avatar movement and Show the default camera controls mini-floater always as opaque
- User Interface > General: new check boxes to open group profiles, teleport history, landmarks, place details, block / mute list in their own floaters; adds an option to show / hide the media control in the menu bar (useful when using a skin which includes the media controls elsewhere) and an option to hide IM and group chat chiclets completely (the notifications envelope and the number of IM’s will remain on the screen all the time whether or not chiclets are disabled)
- Skins: new colour option (Ectoplasma) for AnsaStorm
- Firestorm:
- Windlight: new capability to define cloud texture
- Build: options to default prim settings, texture and permissions on creation – see the Firestorm Custom Prim Parameters video tutorial and the Firestorm wiki
- Backup tab – see below.
Custom Quick Preferences
A popular feature with Firestorm is the Quick Preference floater which, as the name suggests, provides fast and easy access to some of the most frequently used options in the viewer without having to open the “full” Preferences floater.
With release 4.4.0, the Quick Preferences floater has been made somewhat customisable – essentially allowing almost anything which is a debug setting to be added to the floater. However – be warned that this capability is considered to be for advanced users, and does require a willingness to delve deeper into the viewer than some users may be used to. Further, not every debug setting can be added to the floater.
For those wishing to find out more, Firestorm have produced a tutorial video on using the Customise Quick Preferences option, and a Firestorm wiki page.
Settings Back-up
Often, when installing a new version of a viewer, the recommendation is that one performs a “clean install” – removing all cached and settings files. This can make any viewer installation labour-intensive, as settings all need to be restored after the installation is complete, and this can take time and effort.
Firestorm 4.4.0 attempts to ease some of the pain by presenting users with a Preferences option which allows them to back-up many of their global and account settings to a local hard drive. Once done, the back-up can then be restored to an updated version of Firestorm following installation; so providing the back-up is kept up-to-date, restoring the majority of preferred settings is no longer a chore.
The back-up option can be found in Preferences > Backup. To use it, simply select a folder on a local hard-drive as the back-up location, then select those options which are to be saved; you can then delete all files associated with Firestorm prior to performing a clean install.
A very useful part of the option is that it includes the ability to save relevant settings on a per account basis. So if you have several accounts, each with different settings, you can back-up each of them separately – just make sure each back-up has a unique location.
Restoring previously backed-up files requires the viewer is restarted after the restore – and again, this is conveniently taken care of by the viewer allowing you to quickly log-out following a successful restore – although you’ll have to manually re-start the viewer once you’ve been logged out.
For those wishing to find out more, Firestorm have produced a tutorial video on using the Backup option, and there is also a Firestorm wiki page.
Search Updates
The last release of Firestorm re-introduced elements of the legacy “V1 search” into the viewer, using their own floater and toolbar button. With 4.4.0, the full set of legacy search options are once more available (People, Groups, Places, Land Sales, Events and Classifieds), and the options have been integrated with the v3 “web search” floater and toolbar button to present all search options in a single place.
Also, when teleporting when using search, you can choose to close, minimise or leave the search window open via a debug option: Advanced > Debug Settings > FSLegacySearchActionOnTeleport. There is also a Firestorm wiki page for search.
Temp De-render
Firestorm now includes a temporary de-render option. If there is an object you wish to temporarily remove from your view, right-click on it and select Derender. Teleporting away, loging out / in or changing your acitve tag will cause it to re-render. Permanent de-rendering with the Asset Blacklist is still available.
You can also select several objects at once and temporarily or permanently de-render them using SHIFT-right-click multi-select.
For those wishing to find out more, Firestorm have produced a tutorial video on using de-render and the asset blacklist, and a Firestorm wiki page.
Snapshots and Vignetting
There are couple of handy new options when taking snapshots. The first of these is a new toolbar button – symbolised by a camera with a flash blub – which allows snapshots to be quickly captured to disk. There are a few things to note about this:
- All options – file format (PNG, JPG, BMP), image size, etc., are automatically inherited from the snapshot floater
- If you have already used the snapshot floater to save snaps during a session logged-in to SL, any pictures subsequently captured using this button will be automatically saved to the same folder and use the same default file name as the last snap saved unless the snapshot floater is used to change either
-
Vignette options on Phototools If you use this button directly after logging-in to SL, it will display the Save As option for selecting a folder and entering a default file name for snaps the first time you use it. Thereafter, all snaps will be saved to the same folder, until changed using the snapshot floater or you log-out of SL
- As with the snapshot floater, all images will increment numerically when using the same file name (“photo_001”, “photo_002”, “photo_003”, etc.).
Vignetting is a photographic / optical technique which reduces an image’s brightness or saturation at the periphery compared to the image centre. In photographs, it usually takes the form of a picture or portrait which is clear in the centre, and fades off at the edges.
Firestorm 4.4.0 introduces vigetting, courtesy of Exodus, through the General tab on the Phototools floater. The controls comprise three sliders:
- Vig Amount: this controls how much vignette effect to apply. The default is zero, for no effect.
- Vig Power: this controls how intense / dark the vignette effect should be. The higher the number – the darker the circular shadow
- Vig Multiply: increases / reduces the size of the shadow effect – higher number = smaller surrounding shadow.
The Firestorm wiki has some examples of how vignetting can be used in snapshots.
Pose Stand
Note that this option is Second Life-specific.
Firestorm now includes a “pose stand” capability which enables you to fit and adjust attachments, etc., wherever you are. As with other TPVs which incorporate this functionality, Firestorm does not require a physical pose stand to be rezzed – so the option can be used anywhere, regardless as to whether object entry / rezzing is disabled.
The option is accessed via Avatar > Pose Stand, or via a now toolbar button, and includes a range of pose options accessed from a drop-down list (right).
For those wishing to find out more, Firestorm have produced a tutorial video on using the pose stand, and a Firestorm wiki entry on it.
OpenSim Updates
For OpenSim users, Firestorm 4.4.0 includes a number of additional options as well, including:
- Saved user names from any grid always show in the Username selection list
- Separate user settings and chat logs by grid
- Support for OpenSim Lightshare messages
- OSSL/AA syntax highlighting to OpenSim builds
- Better hypergrid jumping support
- Greatly improved grid manager
- SL-specific things like Merchant Outbox, pathfinding, etc., hidden while on OpenSim grids
- Aurora-sim support:
- Support for Aurora ToS
- Support for giant-sized var region and megaregion teleports
- Support for aurora-sim regions with non power of two sizes.
Other Items of Note
- Create Landmark and Teleport history each get their own toolbar buttons
- The World menu gains a series of new options – Resync Animation, plus a number of options to access Firestorm’s Twitter and Plurk feeds, You Tube channel, etc.
- Code merged with LL 3.4.5 codebase
- RLVa improvements and fixes – merge up to RLVa v1.4.8a
- Blocking an avatar now derenders their worn lights
- Phoenix mode now has better default settings
- No more crashing when editing attachments or rezzed objects while wearing mesh
- You can now use estate banning tools directly from Comm > People > nearby tab
- Fix for seams in high res snapshots when lighting and shadows is enabled (the “snapshot tiling issue “- MAINT-628)
Phoenix Users
The Firestorm team have done everything possible to support Phoenix users and to provide as Phoenix-like an experience as possible when using Firestorm, including updates to the default behaviour of the Phoenix mode (such as all IMs and group chats now going into the console, full length of group names shown in console for group IMs, etc.). A new tutorial video has also been produced to specifically help Phoenix users make the move to Firestorm. If you are still unhappy with Firestorm as an option going forward, remember that there are still v1-style viewer available for use with both Second Life and OpenSIm, such as Singularity and Cool VL viewer, both of which support server-side baking and more.
What is NOT There
This release of Firestorm does not include the following notable viewer developments from Linden Lab:
- The Communications Hub User Interface (CHUI): As server-side baking has an immediate and unavoidable impact on all users, work on integrating those elements of the CHUI UI and code considered beneficial / necessary to Firestorm was deferred in favour of ensuring Firestorm is SSB-ready
- Materials processing: there is no support for materials processing in this release of Firestorm because Linden Lab have requested all TPVs refrain from implementing the viewer-side materials processing code for the time being, as the code is still very much being tested.
Feedback
This is a huge update to Firestorm, and one which has seen a massive amount of work poured into it from the Firestorm team and from beta and preview testers. There are enough new features in the release to keep the majority of users happy, together with the knowledge that Firestorm is – barring last minute changes coming out of the Lab – effectively “server-side baking ready”. Considerable work has been put in to the OpnSim side of things as well as readying the release for Second Life – and it’s hard to see how anyone can by upset with what has been provided.
For my part, I’ve been using both initial 4.4.0 releases and the recent Release Candidate versions, and have found the latter to be remarkably stable and with a performance on a part with the last release. As such, I’m more than happy to update to 4.4.0.33270 (barring unforeseen hiccups in changing up from 4.4.0.33718 RC!) as my primary SL viewer.
Related Links
- Firestorm website
- Firestorm download page
- Firestorm 4.4.0 change log
- Firestorm tutorial videos:
- Settings backup and restore (new to the upcoming release)
- Custom Quick Preferences (new to the upcoming release)
- Built in pose stand (new to the upcoming release)
- Custom Prim Parameters (imported from Phoenix and new to the upcoming release)
- Derender and blacklist (updated with new blacklist capability for upcoming release)
- Migrating From Phoenix to Firestorm
Inara Pey: Living in a Modemworld 
I hope that when Firestorm does introduce the CHUI, that it’s an option – As versus LL, where it’s not. The CHUI has been poorly implemented thus far, despite being a pretty interesting way of handling chats.
LikeLike
I think it’s safe to say that the Firestorm team will – so far as is possible, given the depth of some of the changes around CHUI – try to pull out the better parts of the approach and adopt them, rather than simply adopting CHUI wholesale. A lot (I gather) depends on the other updates which rolled out with CHUI – as there was a lot of overall code refactoring that came out with it. I’ve no idea how tied the refactoring might / might not be to all the CHUI changes.
LikeLike
The one thing that’s keeping me out of the latest release (and I did try it, and really wish I could reasonably use it, it’s great), is the total mess that LL made of AvatarZOffset. If I switch poses (like, from one kneel to another), I have to edit appearance (or have a custom shape) just for that pose? Seriously?
I really really hope LL reconsiders this one, because it’s a major inconvenience for anyone that switches poses more than, or say, once a week…
LikeLike
There’s a couple of points here.
The current “z-offset” fix is unlikely to be changing prior to server-side baking being deployed across the grid at some point in the next couple of months as the Lab do not consider the problem as you’ve described as a major “blocker” – and it has to be said the there are users who feel the same way.
HOWEVER, Nyx Linden is very aware of the problem, and has been since the wide issue of rapid pose adjustments (kneeling, sitting, etc.), was presented to him in detail (and I can atest from personal contact with him on Aditi that he has continued to look at the issue). Speaking at the Content Creator’s User Group on Monday April 22nd, he said on the matter: “Its on our list to investigate, but we don’t have a patch or update immediately.” Whether this means a future update will become available is unclear; the Lab are looking at a parameter to help adjust the offset of attachments, but beyond that it is in the hands of the Gods.
One thing which is clear is that SSB “breaks” the current capability for on-the-fly z-offset adjustment entirely – therefore, saying with an older viewer option in order to continue to use the capability as it is found in TPVs at the moment also means living in a world of grey people and being seen as a cloud by them …
LikeLike
That’s good news, that the Lindens recognize the issue and are looking into it. I just wish the developers of the platform were active users….
When they flip the switch for SSB, I’ll have no choice but to use the new version, I suppose I can make up a set of shapes at various offsets… not entirely a pleasant prospect but I suppose it will work.
LikeLike
Just a small observation.
Because we don’t often seen avatars with the “Linden” surname out and about on the grid, doesn’t mean they aren’t there. Users aren’t the only ones to use alts …
Also, and in fairness to the Lab, they are not always aware of the many and varied ways in which we use SL, or of all the little nips and tucks which go into all the various flavours of viewers in much the same way as we, as users, don’t know everything that goes on within SL or within various viewers.
The same applies to the many imaginative and sometimes eyebrow-raising ways LSL commands and functions are put to use.
As such, it is actually possible for Lab staff to miss things, and to have to go through various learning curves in order to appreciate different use-cases, etc., just as you and I and users in general are often going through different learning curves with the platform / viewer as we learn new things.
This doesn’t excuse everything on the Lab’s part, to be sure; but it’s worth bearing in mind :).
I’ll be continuing to follow SSB and the issues around it (as will other bloggers), and will bring any updates on things like the z-offset situation as they become known :).
LikeLike
I must admit that, after the initial estimates, when the Preview group was set up, of a one-week lead time, leave me feeling a little surprised by this release. The Preview tests did reveal some bugs, which were promptly fixed, but the process was effectively done over a long weekend. And weekends on SL always feel a bit precarious. I experienced the usual Weekend-Lag, and various bits of griefing. Was that crash the viewer? Or was it something called an LOD-Bomb?
The Firestorm people have a good history, so I don’t worry much. But there were a few things I noticed at the Preview stage where it was tricky to get a good answer on the expected behaviour. I’m beginning to think that some items in the Statistics Window are effectively useless, because nobody seems to know what they are measuring.
LikeLike
Don’t forget this release was running through the beta group being tested (including a dedicated SSB test on Aditi) for a fair amount of time before it arrived as the first preview group release candidate – so testing has been more involved than may be apparent purely from the preview group. Even so, the preview group proved its value by hitting a couple of blockers which prevented the 33717 RC making it to a full release, and prompting the 33718 and 33720 releases.
As it is, we’ll likelt be seeing a further update in the not-to-distant future, simply because so much within the viewer is in a state of flux (including possible final tweaks to SSB).
LikeLike
I see this rush to get everyone to upgrade to the new version of Firestorm that supports SSB before it is even rolled out onto the main grid, especially since I haven’t seen a notice from LL when SSB is being let loose on the main grid. I know people are starting to download it and use it and it appears to be working good aside from some minor crashes. I see no reason to update until SSB goes live since I have zero issues with 4.3.1.1.5(as in I can stay logged in for as much as 72 – 96 hours before needing to clear cache and relogin)
LikeLike
There is a concern about SSB, yes. This is because SSB represents a substantial change to Second Life which absolutely “breaks” all viewers which are not running the code. As many Firestorm users do stay with older versions of the viewer (some going back two or three releases), the concern is trying to ensure everyone has updated before LL “throw the switch” to enable SSB on the grid. As not everyone reads blogs, etc, (and so not everyone is even aware that SSB is coming), a good way to get people to update is get a viewer update out sooner rather than later, which is seen to be more stable and seen to offer attractive options and then let word-of-mouth among users and their friends help encourage people to update ahead of the switch-over.
LikeLike
There’s only one advantage that I can see to an early release like this, and it has to do with bugs. No matter how much Beta and Preview testing was done, that group can never come up with every possible scenario that a user might try or do. Where as having users download and use the new version will most certainly reveal undiscovered bugs that hopefully can be fixed before SSB goes live(personal experience with Beta testing), but that is only possible if people fill out and send the crash reports. That’s the biggest advantage to an early release, as for notifying your user base, that’s something that should be on the shoulders of LL(whom I think could do a much better job of it with in-world announcements[that could be made to look just like real news, heck they could write a Public Service Announcement and send it to all the in-world DJ’s to play during their sets even, that would then put the burden squarely on the user base when SSB does go live.)
LikeLike
The Lab will be communicating as best they can as the time draws near. The problem is hat – as I’ve noted elsewhere – few users read blogs; few still read the “official” blog.
I’ve personally long campaigned for the return of in-world notifications from LL, prodding Rod Humble and others on it a number of times. However, it appears that the capability to send out such messages – believe it or not – no longer exists. Ergo, there is a case to be made for getting users to communicate one to another. Word-of-mouth is a wonderful thing, particularly when everything is wrapped-up ina heap of additional / updated viewer features.
As far as beta testing is concerned specific to SSB/A – little can actually be done at this point in time on the main grid, beyond uncovering remaining bugs between the SSB/A viewer code and the existing avatar baking mechanism, simply because the server-side of the SSB/A equation hasn’t actually been activated anywhere on Agni as yet. However, once the test regions come on-line, you’re absolutely right: Firestorm and the other TPVs supporting SSB/A (as well as the official release viewer) will have a role to play in testing the system; not just bugs-wise, but also load-wise, prior to the switch being thrown.
In terms of whether this is an “early” release or not is debatable :). While it is early in as much as SSB/A is concerned, it’s nevertheless four months since the last Firestorm release – so some out there might actually claim it to be a little on the “late” side!
LikeLike
Only downloaded Open Sim version, where i do see a great deal of improvement!
If yesterday the latest version of Singularity was my choice, now with the v3 interface option that i do really enjoy, i think firestorm will prevail!
LikeLike
Btw, 1 q if i may!
I see the lack of a specif windows 64b version on both firestorm and Singularity viewers, why?
LikeLike
In terms of Firestorm, I refer you to Jessica’s comments at the Firestorm meeting in February:
Because as soon as we put out a 64-bit Linux, even though it may be buggy … and even though we may get a 64-bit Mac out, which is even further down the road … I think Linux and Mac together are 12 or 15 percent of all the users, something like that. So then we’ve got 85 percent of our users saying, “Where’s out 64-bit Windows build?” … People are going to want 64-bit Windows even though it won’t actually benefit you anything. We’ve got SSE2, we’re taking advantage of your extra memory, and that’s pretty much what a 64-bit thing will give you.
As to Singularity – you’ll have to ask the team.
LikeLike
Sounds good, and i hope cgui never comes in firestorm. its waste of screenspace.
Also i hope, but afraid its not done. the fixt the ui scale bug. that would be the biggest improvement,
LikeLike
There are no plans of replacing the current contacts/IM/chat behavior with CHUI. Evenmore, I already spent quite some time to push all of our communication related assets out of the way so the impact of merging the V3 code with CHUI included will have as less impact as possible. So the actual plan is to keep the interface as it is right now and selectively add features from CHUI that appear to be useful, for instance the expandable chatbar.
LikeLike
Thanks, Ansariel.
You’ve likely made a lot of Firestorm users very happy with this news! :).
LikeLike
So, it seems that the code refactoring isn’t as interwoven with the CHUI as I feared. That’s good news indeed. 🙂
LikeLike
Just tested, UI scale bug still not fixed. So annyoing, Well, back to V1 for the real work.
https://jira.secondlife.com/browse/STORM1913?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel
LikeLike
STORM1913 does no apparently exist.
But I do reckon that the default UI size was maybe OK a decade ago, but is squinty-small on modern monitors, which have pixel counts compatible with HDTV. The days of 640×480 graphics are dead.
LikeLike
Strom does exist. but maby something got wrong with copy & paste. hope this ones work.
https://jira.secondlife.com/browse/STORM-1913?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel
http://jira.phoenixviewer.com/browse/FIRE-3495
LikeLike
One more thing, why is it in this day and age people still make things that require a clean install. It’s not like there aren’t free installers out there that can do all of the work for you without having to delete and install clean yourself, that in itself would make it a lot easier for people to upgrade.
LikeLike
I’ve been hard on the Phoenix-Firestorm team in the past, but I’ve been using FS v4.4.0 and gotta give it a bigtime YAY! It works well on both my Dell XPS i5 desktop and Dell XPS i5 laptop.
I do seem to encounter complete blackscreens from time to time, even with Glow turned off. But the problem is a small price to pay for such an easy ride on this viewer.
Nice job Phoenix Team!
LikeLike
Have you checked-out Lette’s blog post on the black screen issue?
LikeLike
Hi Inara… i have read the post and it doesn’t seem to be the same problem i have. i have no problems at login, but i did turnoff Glow as a precaution. I’m going to look around and research deeper, but it is very erradic. Like I said, a small problem in the overall scheme of things.
LikeLike
OK! Might be worth a FIRE JIRA if consistently repro’d :).
LikeLike
Hi,
I read your review and installed the new Firestorm, but after spending the weekend running it I came away with a totally different impression from yours.
I’ve been using Firestorm almost since I first came to SL over a year and a half ago, and I’ve loved every Firestorm update since then. The last viewer, 4.3.1, worked beautifully on my computer–high fps, very few crashes, lovely graphics–so I was really looking forward to the new update, since I know SSB is coming and we all have to upgrade. But this Firestorm update was awful for me.
First, just so you know, my computer is an iMac with a 3.4 GHz Intel Core i7 chip (quad core). I have 16 GB of RAM (1333 MHz DDR3), and my graphics card is a AMD Radeon HD 6970M with 2048 MB. I’m not sure what all this means, I share it just so the techies know what my system is like. I do know that with 4.3.1, I enjoyed frame rates as high as 20+ in crowded sims (dance clubs, etc.), and in my Linden Home the fps was over 45. The viewer was super-stable, too. SL was wonderful for me.
With 4.4, my frame rates plummeted to as low a 5 fps in crowded sims, and what was worse, I would crash every time I entered a sim with more than 20 avis (again, like dance clubs) after 5 minutes or so. I tried adjusting my settings to improve fps and limit crashes, but nothing worked. SL became basically unplayable for me.
I tried asking for help in the Firestorm Support group inworld, but the only response I received was “avoid that new viewer.” I suppose I could try asking for help again, but honestly, the lack of response really was off-putting. I don’t know what to do now. I know SSB is coming and my 4.3.1 viewer will be broken when it arrives, but the new Firestorm is unusable for me. I suppose I’ll have to switch to the LL viewer (*shudders*), or simply give up SL. I’m pretty sad about this. I hope others aren’t having these technical issues.
Just my 2-cents.
–Cassandra
LikeLike
I’m sorry you’re having a bad experience. Frame rates can be a subjective things, as there a so much which can be going on within and outside of Second Life which can affect them; nevertheless your situation seems extreme.
As the the support group – the official support group is generally pretty helpful, and the firestorm helpers willing to go the extra mile, so I can only suggest you try again or perhaps see if the troubleshooting guide has anything of use for you. There’s also the in-world classes, which include troubleshooting lessons and where questions are welcomed. I believe the next trouble-shooting class is on Thursday, May 2nd and 18:00 SLT.
LikeLike