Firestorm 6.0.2: Animesh release

On Sunday, February 17th, 2019, Firestorm release version of their viewer, marking the official release of Animesh support within Firestorm.

This release is essentially a follow-on to the Animesh Early Access release made in December 2018.

Table of Contents

As I covered this in Firestorm 6.0.1: Animesh Early Access, aside from highlighting some of the more user-visible updates in that release, this article provides information on those updates specific to Firestorm 6.0.2.

Please use the table of contents above right to jump to any specific topic of interest. Full details of all changes, and contributor credits can be found in the official release notes.

The Usual Before We Begin

As per my usual preamble:

  • There is no need to perform a clean install with this release if you do not wish to.
  • Do, however, make sure you back-up all your settings safely so you can restore them after installing 6.0.2.
  • Please refer to the official release notes for a full breakdown and changes, updates and credits associated with this release.

Notable Firestorm 6.0.1 Updates

The following is a short update of some of the more user-visible updates present in the Firestorm 6.0.1 Early Access release, presented for the benefit of users who may not have downloaded that version.It includes both Lab-drived and Firestorm-specific updates. For a more detailed overview on that release, please refer to Firestorm 6.0.1: Animesh Early Access.


For a detailed overview, see my Firestorm Animesh notes.

Animesh allows the avatar skeleton to be applied to any suitable rigged mesh object, which can then in turn be animated using suitable scripts and animations contained within the object’s Contents. This opens up a whole range of opportunities for content creators and animators to provide things like independently moveable pets / creatures, and animated scenery features.

While Animesh is likely to primarily be used by content creators, it has been designed so that any suitable rigged mesh can be converted to Animesh directly from the Build / Edit floater . Do be aware, however that simply converting an object will not cause it to start animating – you’ll need suitable animations and a script to run them. Like any other object utilising animation, this is done by adding the animations and scripts via the Edit > Contents tab for your converted object.

The best way to get started with Animesh is to use the available resources. These include:

Firestorm Animesh Additions
  • Derender Animesh: depending on your system, Animesh may impose some performance impacts, particularly where a lot of Animesh is active within a scene. To help mitigate this, Firestorm 6.0.2 includes an option to derender all Animesh in a scene (Developer menu > Rendering > Derender All Animesh). Note that this is only temporary, and derendered Animesh will reappear after a teleport or re-logging.
  • Auto-scaling amortisation of the new Animesh dynamic bounding box calculations. This fix limits the overhead of the new dynamic bounding box calculations to AvatarExtentRefreshMaxPerBatch per AvatarExtentRefreshPeriodBatch frames. The default is 5 avatars per 4 frames, so in a busy region, 25 avatars would take 20 frames to refresh the bounding boxes.
  • Performance tweaks by reducing Matrix operations per render pass.
  • More JointMatrix Palette caching tweaks:
    • The cache has been moved to drawable for more benefit (reduces CPU overhead when rendering shadows and materials by caching the jointmatrixpallette).
    • Sacrifices some potential cache locality but savings seem to outweigh this.

Other Notable 6.0.1 Updates

Additional updates in the Firestorm 6.0.1 pre-release worth noting are:

  • Mesh Uploader (for full details on the mesh uploader changes, please refer my Firestorm Mesh Uploader notes): Beq Janus has overhauled the mesh uploader to improve its use and the information it provides. She has also provided comprehensive documentation on these updates, which are summarised below:
    • Upload cost and physics cost calculation breakdowns – see image below for more.
    • Physics details, the costs of the different types of physics (convex hull, prim).
    • Resizable preview window with higher resolution image and improved shading/lighting.
    • Correct highlighting of degenerate mesh.
    • Improved error handling for physics models (avoid some MAV errors).
    • UV Guide overlay.
    • Note Firestorm 6.0.2 includes further updates to the uploader
  • Experimental Teleport Attachments Fix (Debug Settings > FSExperimentalLostAttachmentsFixKillDelay): a timer delay designed to prevent attachments from being detached temporarily after a teleport has completed.  Works with FSExperimentalLostAttachmentsFix when set to TRUE; set to 3 seconds by default.
  • Left-click None option (Build Menu):  allows transparent prims / mesh to be clicked-through that might otherwise be in the way when trying to touch other objects (via LL).
  • Auto Replace for Note Cards: dynamic replacement of text within note cards when the Auto Replace function for spelling is enabled via Preferences > Chat > Typing > Auto Replace (see the Firestorm wiki on Auto Replace).

Linden Lab Derived Updates in Firestorm 6.0.2

This version brings Firestorm up to parity with Linden Lab release viewers through to release version (formerly the Spotykach RC viewer, promoted on December 13th, 2019. Major updates in that release include:

  • Voice Server:
    • Second Life: Vivox version 4.9.0002.30313 (Mac and Windows) (Opensim: Vivox version 4.6.0017.22050 (Mac and Windows); Linux: Vivox native voice version 3.2.0002.10426, Firestorm only).
  • Chromium Embedded Framework (CEF) Dullahan:
    • Dullahan: 1.1.1080
    • CEF: 3.3325.1750.gaabe4c4.513446
    • Chrome: 65.0.3325.146
    • Page of test URLs for Dullahan. With the Developer Menu enabled (Ctrl Alt Q) press Ctrl-Shift-Z then the Home page button.

Firestorm 6.0.2 Updates

Appearance and Inventory

  • The Avatar menu includes new short cut for the Avatar > Avatar Health > Refresh Attachments option (Alt-Shift-R).
  • Replace Links – Delete links check box

    Inventory: Delete Links: the Replace Links inventory option now includes the ability to delete all links to an object:

    • Open your inventory.
    • Locate the object which has links you wish to delete (or one of the links themselves). Right click on the item / link and select Replace Links.
    • The Replace Links dialogue box opens, recording the object link name, the option to replace it with a new name and a new Delete Links Only check box.
    • Click the Delete Links check box to activate it. The Replace field in the dialogue box is replaced by the warning Links To This Item Will Be Removed.
    • Click Start to delete all links.
  • Experimental Lost Attachments Report (Debug Settings > FSExperimentalLostAttachmentsFixReport): when enabled, this reports attachments that were attempted to get detached during a teleport or region crossing to nearby chat.
  • Inventory should no longer automatically opening to show new items regardless of settings (FIRE-23476).
  • Enabling Disable Random Eye Movements (Preferences > Firestorm > Avatar > Disable Random Eye Movements) will no longer cause the avatar’s hands to splay (FIRE-23457).

Build Updates

  • Revisions and updates to the mesh uploader introduced in Firestorm 6.0.1
    • Allow intentional degenerate placeholders – this fixes the problem of “Physics mesh too dense” false positives (FIRE-23367 and FIRE-23387).
    • Allow override of client side mesh validation as a workaround for edge cases and different grid validation.
      This effectively restores previous server-side MAV error dialogues alongside client-side warnings.
    • Fixed up 3-point lighting (so it has 3 points) that was messed up in a rogue merge.
    • Fixed up black bar in mesh preview when the mesh uploader is used with low resolution screen (FIRE-23340).
    • Increased panel height to avoid warning message overlapping.
Mesh Uploader: new cost calculations breakdown elements by Beq Janus – see Firestorm 6.0.1: Animesh Early Access

UI Updates

  • Texture picker should no longer open the wrong floater when pressing space in preview mode (FIRE-23582).

RLVa Updates

Firestorm is still using RestrainedLove API: RLV v3.2.1 / RLVa v2.2.0.56680.

@setgroup Throttle

With Firestorm 6.0.2 @setgroup is throttled to one (unowned) call every 60 seconds across all objects. An object a @setgroup lock may bypass this throttle once, to allow @setgroup=n,setgroup:[;]=force to succeed regardless of any/other objects’ command history.

This will break all animated group tag cyclers introduced after the @setgtoup feature was added to Firestorm 5.1.7. However, it has been introduced at Linden Lab’s request due to the performance issues multiple frequent @setgroup calls were causing (each call generates a database write). Further, Linden Lab will shortly be introducing a server-side throttle to active group changes and group role changes, and so @setgroup will be broken in any viewer using it.

Please do not blame Firestorm or any other TPV using @setgroup for this change. There is nothing that can be done about it, given the forthcoming server-side throttle. We did attempt to contact all the sellers of these group title animators on the Marketplace many weeks ago to warn them that the feature had to be removed & sadly only one creator removed their listing.

Other RLVa Changes
  • New ‘RLVaSplitRedirectChat’ setting: splits long chat lines when @redirchat restricted.
    • Debug: RLVaSplitRedirectChat) – set to TRUE.
    • Menu bar > RLVa > Split Londe Redirected Chat
  • Fixes for:
    • @setoverlay_alpha causing a diagonal line to appear on the rendered texture.
    • @shownames exceptions should not have their name anonymised in nearby chat.
    • @shownames exceptions not having the correct colour on the minimap (FIRE-23473).

Other Updates of Note

  • FMOD Studio updated to version 1.10.10.
  • KDU updated to version 7.A.6.
  • Firestorm application icon should no longer randomly flash on the Windows 10 taskbar (FIRE-23498)
  • Fix for the camera floater zoom glitch (FIRE-23470).
  • Firestorm should no longer crash when adding a large number of users to a contact set.
  • Firestorm should correctly request microphone permissions on OS X Mojave (FIRE-23405).
  • The context menu in scroll lists (LLScrollListCtrls) can now be opened with the Windows keyboard (FIRE-19933).
  • Skinning and translation updates – see the release notes.


Not a major update, unless you skipped the 6.0.1 early access. As with that release, the core element for 6.0.2 is Animesh, together with the revised mesh uploader for content creators.

Performance-wise, I’ve found Firestorm 6.0.2 to be equitable to Firestorm 6.0.1. Other than this, not a lot to report.


8 thoughts on “Firestorm 6.0.2: Animesh release

  1. As an aside… I’ve always wondered…

    Is there a simple reason why Firestorm and Linden Lab’s SL viewers continue to be developed in parallel? It seems apparent from the rate of progress that LL’s resources for Second Life’s development are limited. So would it not make sense to pool resources on the viewer?

    I understand that Firestorm is open source and developed by volunteers, but open source projects can be managed by companies.

    As far as I know (probably not accurate) the main differences are that Firestorm supports RLV, and Firestorm independently added Region Windlight (which I heard Linden Lab is now developing an official version of).

    Might a reason for not wanting to merge the products be that LL is opposed to ‘officially’ condoning the RLV functionality, given that it is largely used for adult purposes?

    I don’t think I know anyone who routinely uses the LL Second Life viewer so it seems like a huge amount of effort spent on something just used by newbies. Maybe I’m wrong about that and the official viewer is used much more widely than I thought.


    1. This is a simple question with a quite complicated answer I’ll do my best to boil down to key points.

      The first thing to remember is that the Lab’s viewer code is open source, and probably makes up about 80-90% of the code seen in all TPVs. While there are additions to some viewers that come by way of code written entirely outside of LL (RLV and RLVa being the most obvious examples), much of the “extra” stuff seen in TPVs is in fact the result of changes made to the code supplied by LL.

      These changes can take a number of forms. Some might simply be a “tidying-up” of UI elements; some might be a complete UI re-write; many – but by no means all – are a case of taking capabilities buried within Debug Settings in the LL code and exposing them through UI elements, or combining multiple existing capabilities in the viewer more logically through a UI element (e.g. Firestorm’s Phototools or the “machinima panels” found in other TPVs).

      Doing this allows TPVs to meet the needs of a wide range of more “specialised” users in Second Life, while Linden Lab can remain focused on providing core viewer code maintenance and adding features and capabilities that can benefit everyone using SL, regardless of any special interests they may have – Adult game, role-play, machinima, etc.

      That said, given the viewer is open source, the way is always open to for working on TPVs to contribute their code back to LL for possible incorporation into the official viewer. The re-working of the mesh uploader seen in Firestorm 6.0.1/6.0.2, for example, has been contributed to LL by Beq Janus. Similarly, the developer of the Black Dragon viewer has contributed an animation poser system to from that viewer to LL.

      Thus, by having a broad ecosystem of viewers allows SL users to be presented with a wider choice of options, rather than being forced to accept a “one size fits all” of viewer which could end up so convoluted and UI heavy in trying to please everyone, it is universally hated to one degree or another.

      There are also other more practical reasons for something like Firestorm not “pooling” with LL – such as matters of employment, etc. (There’s also the complication of OpenSim support, but I’m deliberately ignoring that here.)

      Also, I’d tend to dispute LL’s resources being “limited” vis the viewer: their rate of viewer output far exceeds most other TPVs. As a rule of thumb, they tend to have at least one viewer release a month, and always have a number of viewers at release candidate or project status. Again, this is where they are carrying a good deal of the load: LL carry out the heavily lifting of QA testing and initial user exposure of the core viewer code and new features they add to it, allowing TPVs to focus more on how core updates produced by the Lab might impact on the work they’ve done to expose existing capabilities, or in providing capabilities to meet the needs of specific groups of users.

      In terms of users, it is true that Firestorm is the most popular viewer in SL – but the Lab’s viewer remains the second most popular.

      Liked by 1 person

      1. Thank you for your detailed reply. That makes a lot of sense! I didn’t know the LL viewer was also open source, so yes of course Firestorm must be branched off that codebase. And also it’s great that they can contribute back with improvements and features for possible incorporation into the official viewer (I know a fair bit about development so understand how this works with git pull requests for example).

        Regarding LL’s updates – yes I suppose the viewer itself does indeed get lots of updates. I was thinking more about progress on the platform in general (maybe more the server side of things). Seems there are some things that are not quite right long term but which people just accept. Maybe being new I notice them more. But that’s totally off-topic 🙂


        1. You’re welcome!

          Server-side, there is a lot going on under the hood and out-of-sight of users, notably the upgrade to the underpinning server operating system and in the work preparing for (and actually making) the transition of all the SL services over to cloud infrastructure. This has led to a slow-down in more visible development of capabilities and updates to the simulators.

          Liked by 1 person

          1. Yes, I know about the cloud migration. I noticed – I think – that assets are already on S3. I don’t doubt for a moment the technical team is extremely dedicated and busy – I know how difficult it is to maintain any application long term, not least one this complicated! And moving servers while live… Nail-biting at the best of times 🙂


  2. 1. Singularity had the ability to show the LI of a particular mesh part in “Edit Linked” this needs to be implemented.
    2. Singularity had the ability to show ONE highlighted folder in a separate inventory window. This needs to be implemented.
    3. Firestorms Search – sucks. Once the item or items are found, you cant hit escape and have it drill to that items folder. All it does is un-collapse your entire inventory again and you end up scrolling trying to find the item you highlighted. This could be cured with #2.
    4. Singularity Correctly reports link number. Firestorm doesn’t, at least not without a re-rez of the item. They can do all this stuff with that old ass viewer it would be nice if Firestorm could too.


    1. Unfortunately, I can only review what a viewer provides, as I’m not part of the Firestorm team (or part of any other viewer team). This being the case, the best way to put forward proposals for potentially improving a viewer is directly to the team responsible, as that way ideas are far more likely to be seen by the relevant people (not everyone reads blogs like this 🙂 ).

      For Firestorm in particular, suggestions can be submitted as feature requests via their Jira.


  3. Re: the Left-click None option allowing transparent prims / mesh to be clicked-through– my understanding is that this option was added in response to the feature request in Lab BUG-216339, as a way of preventing child prims within a linkset from being clickable when the root prim contains scripting with Touch events. Since upgrading to Firestorm 6.0.2, neither my partner nor I can reproduce the behavior described in your post– transparent prims or mesh set to left-click none continue to prevent click-throughs just as they always have. Is there confirmation that click-through is now the expected behavior? Are we just missing something dreadfully obvious?


Comments are closed.