Firestorm 4.3.0: Cry “Havok!” and let slip the goodies of update

From Phoenix

This release sees further incorporation of functionality found in Phoenix, including the combat-popular “Use Crouch in Toggle Mode”, which allows PAGE DOWN to be toggle “crouched walking” on / off; the option not to trim “Resident” from legacy names; the inclusion of the letter key search in the Friends list; and more.

While Firestorm can never be a “Phoenix clone” in terms of the overall UI and menu system, it is fair to say that there is really more than enough in the viewer to allow any dye-in-the-wool V1-UI / Phoenix user feel reasonably comfortable in using Firestorm – providing they are willing to give it a fair shake (which should be measured in days rather than hours – after all, no-one mastered the V1 UI in just a handful of hours). Certainly, the V1 UI mode should go a long way towards assisting any transition.

Phototools

The main Phototools floater and dedicated toolbar button, shown in icon mode

Phototools is a suite of floater updates / new floaters which bring together a range of controls, debug settings and options available within the viewer into a single, cohesive set of options aimed at the SL photographer and machinima artist. Developed by William “Paperwork Resident” Weaver, prior to this release they were available as an optional “plug-in” for Firestorm. Now, thanks to William and Ansariel Hiller, they are available from directly within Firestorm.

The core components for Phototools are a new floater (right), updated Sky and Water Presets floaters and an optional Camera floater. I have extensively reviewed Phototools in the past, so will not be going into great depth on the subject here.

The main Phototools floater and the revised Camera floater now have dedicated toolbar buttons, so those who have been using the tools no longer have to overwrite the Firestorm Quick Preferences floater or limit themselves to using either the Phototools Camera floater or the Firestorm default Camera floater.

These changes mean that users are provided with the widest spread of options for using Phototools and existing capabilities within the viewer (Quick Preferences and Camera). This is particularly useful with the Camera floater, where the additional options included with it may offer greater convenience to the machinimatographer when filming, but might otherwise get in the way.

One option which is new to Phototools as a result of the work undertaken to integrate the floaters into Firestorm, is that the Phototools Camera floater includes buttons to save and load the current camera position.

Contact Sets and Mouselook Buttons

Besides the Phototools toolbar additions, Firestorm 4.3.0 gets two new buttons for the toolbar: Contact Sets, for accessing the Firestorm Contact Sets option, and a Button for enabling / disabling Mouselook. Additionally, and in the case of Mouselook, there is now an option to disable it in Preferences (Preferences > Move & View > View > Enable Mouselook functionality). When unchecked, this disables the Mouselook buttons on the Camera floater and in the Toolbar or via pressing M (if the keyobard shortcut is enabled via Advanced > Shortcuts > Mouselook).

Sounding Out

Firestorm 4.3.0 sees the addition of a raft of new sound options, from fully configurable UI sounds to new dedicated alert sounds. The majority of these can be found in two new Preferences tabs under Sound & Media (UI Sounds 1 and UI Sounds 2).

New UI sound option in Preferences > Sound and Media

These new tabs allow sounds to be turned on / off (check / uncheck Play Sound), and for the sounds themselves to be customised through the use of UUIDs for sounds in a user’s inventory. Additionally, if the sound itself can be toggled by an option elsewhere  – such as a menu option – then matching option in the tabs will also update. For example, setting Advanced > Quiet Snapshots will update the Taking Snapshot sound option in UI Sounds 1 to read “Mute this sound”, indicating it has already been turned off.

Additional sound options presented in 4.3.0 include:

  • The Radar (Preferences > Chat > Radar)  includes the ability to set and play a sound for each of its options (when a user enters / leaves chat range, etc.)
  • It is now possible to hide the white dot indicators which appear above people’s heads when Voice is enabled (and which turn into a green “speaking” indicator) in your world view when Voice is enable (Preferences > Sound & Media > Voice Settings > Show voice visualizers over avatars)
  • Parcel audio stream fading time can be adjusted / disabled (Preferences > Sound & Media > Enable Parcel Audio Fading)
  • Default collision sounds (the “thump-thump-bump” sound, etc.) can now be disabled from Preferences (Preferences > Sound & Media > General > Play sounds from collisions) or via the pull-down volume controls at the top right of the screen.

Finally with regards to sounds on Firestorm, 4.3.0 introduces an option whereby unpacked sound files can be kept cached after logout, rather than being deleted (Preferences > Network & Cache > Dont delete unpacked DSF (sound) cache files when logging out). This may improve your experience when playing in-world sounds (less delay in them being played back as they are already cached). However, this may fill up your cache directory very quickly, and will not adhere to the max cache value (so more than 10GB may be used with caching). Because of this, the option is disabled by default.

Updates for Builders, Creators and Scripters

In October, I report on Magus Freston’s request for assistance in testing a mesh upload patch. This overcomes a naming convention issue between the Sl avatar bone structure (which allows spaces in bone names, such as “left elbow”) and Collada (which does not recognise spaces, but uses underscores such as “left_elbow”). The patch had been designed to convert Collada format bone names to SL-format names on uploading a mesh.

Mesh upload bone name conversion patch from Magus Freston

A request to add this patch to Firestorm was submitted in mid-October (FIRE-7937), with Magus permitting Firestorm to use the patch under LGPL, and it makes its debut with this release.

Firestorm 4.3.0 also provides builders and scripters with:

  • The ability to include / exclude group-owned objects during selection (Build menu > Options > Include Group-Owned Objects)
  • The ability to turn off in-world object grabbing (CTRL+MOUSE) when building to avoid accidental dragging of objects or linksets in a build out of alignment (Preferences > Firestorm > Build > Use CTRL+Mouse to manipulate objects)
  • Two new buttons in the Build floater:
    • A Reset Scripts button on the Contents tab for resetting scripts within the selected object / linkset
    • A Transparent button in the Texture Picker floater, which will turn the selected object / linkset transparent
  • Taper and Sheer options on the Object tab of the Build floater now supporting editing to three decimal places
  • “Restore to Last Position” now obeys “Always rez objects under the land group if possible” option (subject to land permissions)
  • Uploading and saving files to disk using threaded file pickers which allow the file picker to be open without pausing the agent, allowing the user to continue anything else they’re doing while they look for the file they would like to upload. This also prevents the simulator from disconnecting the agent from the region if they’ve been paused too long while in the file picker.

Area Search

The Area Search function receives a complete overhaul in Firestorm 4.3.0. The search engine has been re-worked as is now “10x to 100x faster.” In addition the floater gets a new set of tabs which enhance usability, comprising:

  • The List tab – which opens be default and can be used to list objects within a region (the Refresh button at the bottom starts a scan for items to list). By default, this scan for all items in a region, however, a wide range of criteria can be set to narrow the focus of a scan
  • The Find tab – which allows you to search for items by the criteria previously found at the top of the Area Search floater (item name, description, owner, group) and to which the options to search by creator name and last owner have been added. These fields can be used individually or in combination, with results displayed in the List tab
  • The Filter and Option tab, which allow scans to be further filtered and refined, and what information is displayed in the List window, based on a number of additional criteria / settings
Two of the new tabs in the Area Search floater which allow more refined searches and set the level of information displayed in search results (click to enlarge)

Area search now has dedicated documentation on the Firestorm wiki.

readability Improvements

Open-Dyslexic, an open-source font, is designed to improve text readability for those suffering from  dyslexia. It  is available in Firestorm 4.3.0 and is available under Preferences > User Interface > Font > Font Scheme. Also to help improve readability for the visually impaired, Firestom now has an option to automatically convert all incoming text in nearby chat, IM windows, group chat windows, the chat console and bubble chat into uppercase (Preferences > Chat > General > Display group chats, IM sessions and nearby chat always in uppercase). User names are not converted, nor is outgoing text from the user.

And There’s More…

There are still more changes and updates with the release which I’ve not covered here. To see them all, I recommend you refer to the release notes provided by the Firestorm Team, which also provide full developer credits for the included updates, changes and additions. For my part, I will send out a special thank you to Whirly Fizzle, for one of her contributions – that of providing a Preferences option to disable the swirling particle effects seen when scripts communicate or when you are talking via a scripted item to save having to manually dive into the debug settings in order to find EffectScriptChatParticles and then set it to false.

Preferences > Firestorm > General > Create particle effects when scripts communicate may seem like a trivial change, but when those same like swirling particle clouds drive you bonkers and scrabbling through the debug floater to disable them, it’s an appreciated addition!

Performance and Feedback

Performance-wise, and bearing in mind I no longer have my “regular test region” on which to play with viewers, Firestorm 4.3.0 gives very similar results on my usual review system (see the panel on the right sidebar of this page) as the recent Catznip and Niran’s Viewer releases I’ve taken a look at in the last month, with my results as follows:

  • Deferred off:
    • Ground: 26-28 fps
    • 370 metres: 30-31 fps
    • 2875 metres: 46-48 fps
  • Deferred on + lighting set to Sun/Moon + Projectors; ambient occlusion off:
    • Ground: 9-10 fps
    • 370 metres:11-13 fps
    • 2875 metres: 18 fps

Interestingly, and like Catznip R7, these figures dropped only very slightly (1-2 fps on average) if I also activated ambient occlusion in deferred; again marking the fact that for me, things seem to have improved recently over the start of the year.

As a beta update, this initial release of Firestorm 4.3.0 may be a little quirky or suffer from bugs. I encountered a couple of issues which have encouraged me to switch back to the last of the pre-release builds I downloaded and await the full release. The issues were not major and, given I’ve also encountered one of them while using other viewers, I’m not altogether sure it is a Firestorm-specific problem (snapshot floater refusing to save pictures to my hard drive when using custom windlight presets). However, if you do encounter problems with the release, and don’t actually need the large group edit capability, it may be as well for you to revert to the current 4.2.2 release, and await the “official” release of 4.3.0.

That said, there is a lot packed into 4.3.0, making it one of the most significant updates to Firestorm to date. Kudos to all involved.

Related links

15 thoughts on “Firestorm 4.3.0: Cry “Havok!” and let slip the goodies of update

  1. I’m actually rather impressed at how far along Firestorm is to becoming a V1-like viewer. I was hoping the Dyslexic font would be a little more legible though – It helps organise the letters properly, but it’s setting off that same feeling you get with the Uncanny Valley effect. Weird.

    There is still little nit-picks with FS (hoping they come up with a better search floater, fixes the graphical glitch w/ the ‘buy L$’ covers the time, build/profile floater tabs are unnecessarily cramped, hopefully they can bring back the old IM tab or make a better one than the stupid toasty thing, get rid of the movement floater), but if Singularity ever stops being usable, I can almost feel comfortable with FS, though the menu system is still a whole new (seemingly a bit unnecessary) learning experience.

    Like

    1. If would be helpful if you create a JIRA ticket with a detailed description of those problems. Details especially means: What skin and what language. This is usually a skinning and/or localization issue.

      Like

  2. With the Havok/OpenSim clash I am a little wary of making the switch, since I have a local SimOnAStick I use for some testing of stuff I make. It’s the Pathfinding, and during the recent Zombie season I didn’t see any sign of anyone using it. Early days, but the Linden Wall gets ever stronger…

    Like

    1. It’ll be interesting to see how the SL / OpenSim divide is handled, and whether it’ll be possible to run both versions of Firestom on the same box (once the OpenSim flavour arrives), with each using unique localtions for user settings, etc. Pathfinding-wise, I’ve spoken with a couple of rp group leaders who have indicated they are looking towards using it as a means of increasing the depth of immersiveness in their regions (both run role-play across more than one region), but have yet to see anything concrete.

      Like

      1. It seems to me the real solution to having viewer forks for OpenSim is to find or create a replacement for the visualizations the Havok library provides.

        I’m not saying this is a trivial task, but it’s not a new challenge for TPVs. Kirsten did this with the Kakadu library for JPEG2000 with OpenJPEG. Imprudence and Kokua did this with FMOD for media with GStreamer. And Nicky D replaced Havok’s convex hull decomposition used with mesh upload with HACD.

        To my knowledge, no one has yet attempted this for navmesh visualization. This is a real shame, because doing so means that no one has to sign any licenses with any third parties, or potentially need to license those libraries themselves. Perhaps even more importantly, when used in the same viewer those replacements mean a fully, truly open source viewer. That means a viewer that LL has less leverage over, and one that can never be easily taken away from users and developers.

        Like

        1. The problem here, assuming an alternative thrid-party option could be engineered to visualise the navmesh, is that the new Havok library functions may not be limited to just the question of navmesh.

          We simply don’t know LL’s longer-term plans in this regard and whether they will be using dedicated Havok library functions for other purposes in the future (again, assuming this can be done). If they do, what then? Will TPVs wishing to support access to both SL and OpenSim need to re-engineer their solution each and every time LL announce the introduction of a new capability / feature which makes use of their Havok libraries? If so, that could get to be very top-heavy.

          Like

  3. Hmm… the comments seem to only allows for comment threads four deep. 🙂

    That LL may use additional functionality provided by the Havok libraries is a really good point. And it’s probably even not even very speculative. They have paid the license fees for it after all; they’d be silly not to use it. That license no doubt comes with the availability of support services for LL’s developers that open source alternatives lack. The real question here is how much of that functionality will be present on the viewer side. I’d be willing to go out on a limb and say the lion’s share of it won’t be. Most Havok functionality currently resides on the server, and with just a few possible exceptions, I think it’ll stay that way.

    There will be exceptions, of course. One that occurs to me as a possible future enhancement is cloth physics simulations. People would go gaga over something like that. It’s right up Havok’s alley, and would be mostly viewer side. We’d have to hope that LL provides a suitable stub for an alternative (they may be less inclined to do so at this point, with the sub-license available), and then hook up a replacement. In the case of my example, one exists; the open sourced Bullet Physics SDK provides for cloth physics simulation.

    For the vast majority of users for whom SL is their primary virtual world, this can easily seem like so much work for so little return. And it probably should, unless they’re part of the minority that are strong open source supporters. I don’t personally think LL is being intentionally antagonistic towards an open viewer. I think they’re simply being pragmatic and attempting to use the resources they have in the most efficient ways, bringing enhancements to SL users faster and at less cost.

    For people who are OpenSim enthusiasts or professionals, however, this really should be seen as a major priority. In the long haul, I think doing the (one time) extra work of a library replacement probably benefits a project like Firestorm if they’re really committed to OpenSim compatibility. For a project like Firestorm, they can do (or adopt) the one time work of implementing a replacement, or they can be saddled with two projects that may increasingly diverge over time, continually increasing the needed effort to maintain both projects. OpenSim users should worry that one project is, at some point, likely to suffer at the expense of the priorities of maintaining the other. With SL’s much larger user base, I’m guessing the OpenSim fork is the one that would get short shrift. Having a single, fully open source viewer eliminates that worry.

    OpenSim advocates and developers would prolly do themselves a huge favor by rallying behind and supporting a viewer that is wholly dedicated to OpenSim in a serious way, really. Sadly, there’s been very little momentum on that idea. Imprudence was that viewer for a while, and though it has a successor in Kokua (currently the only viewer I know of that’s wholly open source), very few people have taken a very active interest in participating in that project to this point.

    I’ll shut up now. 🙂 I do have my own blog. I should prolly damn well use the thing. Hehe!

    Like

    1. Hi, Marcus!

      Sorry for not getting back to you sooner, been faffing around all over the place :).

      The potential for shifting a range of “physics” capabilities viewer-side is something I’ve touched upon in this blog in the past when discussing the the sub-licence, and a subject Maxwell Graf and I chewed over in IM and elsewhere a few times.

      I agree with you that LL aren’t being antagonistic towards OpenSim in choosing to go this route – it is pragmatic, as you say. I will admit to being disappointed in some of the reactions from sectors of the OpenSim community – including some providers – in the way they have chosen to interpret LL’s decision in terms that are purely antagonistic and proclaimed so rather loudly.

      Your concerns re forking are valid – and I think that’s pretty much what Jessica was referring to in her post on the matter. With the best will in the world (including Cinder’s well-put reply below), the firestorm resources are finite, and there is a risk that in the future, divergence between the forks may come at a cost. Time will tell on that score, but I think Jessica is simply being fair and honest in outlying things in advance.

      It would be good to see a wholly OpenSim-focused viewer emerge, perferably in the not-too-distant future. There are some huge benefits in allowing / encouraging one to go that route, as Ilan Tochner of Kitely and others have pointed out. Certainly, it’s fair to say that OpenSim has sufficient critical mass, user numbers-wise to warrant it. I’d certainly have no issue in swapping between viewers when hopping between worlds :).

      Like

  4. Speaking entirely my own personal opinion and not for the rest of the Firestorm team, I can tell you I’m committed to ensuring a Firestorm version not only compatible with OpenSim, but the very best viewer experience for OpenSim. The way our repository is setup allows us to build either the SL or OS versions of Firestorm from the same code repository so there’s not a very high chance of something in the SL version not making it to the OS version (Havok obviously excluded.)
    I can tell you I’ve been personally in contact with several virtual world developers to help ensure Firestorm’s OpenSim version maintains compatibility with their grids as well as others.

    Like

  5. re. I’m committed to ensuring a Firestorm version not only compatible with OpenSim, but the very best viewer experience for OpenSim.

    Great. But please consider us Mac OSX users. Firestorm now crashes every time I try login to my space. Back to Imprudence for me for the moment.

    Thanks. Michael

    Like

Comments are closed.