Firestorm 4.3.0 has arrived slightly earlier than expected, in the form of an initial beta release made as a result of the implementation of new Group Services code across the main grid.
While this is only a beta, and the associated Firestorm blog post gives fair notice that it may yet be somewhat wobbly while final work on getting it QA’d and ready for a formal release is ongoing, there is more than enough in the release to make it something people are liable to be hungry for. So here’s a preliminary review of the release as it stands today, with the caveat that things may change between now and the full release, which is currently scheduled for December.
Download and Installation
The download .EXE is big – 40MB, which is unsurprising given that Firestorm packs so much into it. I’ve been running pre-releases of this version for a while now, and the size has been consistent between them and while much bigger than other TPVs and the official viewer, it hasn’t grown overly much since the last release.
The installer is actually the place where the updates to the viewer begin for Windows users, as it now incorporates:
- A pop-up requesting whether or not the user wishes to have a Windows Start menu entry created for Firestorm during installation
- Addition of the version string and estimated installed size to the installer
- Addition of new OS detection code to warn if Windows Service Packs are not up-to-date and to prevent Firestorm being installed on Windows XP with
- Publisher data, Phoenix URLs and Firestorm icon for the Firestorm entry in the Windows uninstall list
- Automatic deletion of all previously installed skins to reduce issues arising from an unclean install
- Addition of a DETAILS button in the installer pop-up window to allow the installation to be reviewed.
Lab Updates
Version 4.3.0 of Firestorm sees the viewer merged-up the official Linden 3.4.1 code base and the inclusion of later updates which are just filtering through to the official viewer 3.4.2 code pipe. Together these mean that this release incorporates and number of LL updates, including:
- Recent updates and improvements to the viewer-side pathfinding code
- Memory leak and memory crash fixes
- Translation updates (together with further updates from members of the Firestorm team)
- Incorporation of the official LL spelling checker (contributed to LL by Kitty Barnett to LL) and the official Auto-replace function (contributed to LL by Kitty Barnett, Jonathan Yapp, Tankmaster Finesmith and LordGregGreg Back)
- Rendering fixes and optimisations
- Group Services (group management) update (from the LL 3.4.2 code branch) allowing groups with more than 10K members to be edited and updated
- Objects by multiple creators show creator details when viewed in inventory (Properties), rather than “unknown”
This release also incorporates the new LL maturity rating function which:
- Notifies a user when trying to enter a region without having set the required maturity level in the viewer and presents the option to change their maturity setting (subject to age verification)
- If applicable, sends a message to the person offering a teleport that the recipient is unable to access the region due to their maturity level.
Havok Sub-licence
Firestorm 4.3.0 sees the implementation of the Havok sub-licence agreement between the Firestorm team and Linden Lab. This means that this is the first version of Firestorm to be released without any support for OpenSim access. Both –loginURI capabilities and the Grid Manager functionality have been removed.
However, as Jessica Lyon has previously noted, development of the viewer will be forking, and OpenSim support will continue in the future via a version of Firestorm which excludes the code required to access the LL Havok libraries. How tailored the OpenSim version will be for use on those grids is not clear, and those who use Firestorm to access both SL and OpenSim grids should read Jessica’s comments on support in the future.
The Havok sub-licence agreement does mean that this release of Firestorm can access the new LL-supplied Havok libraries which in the first instance, enable TPV viewers to visualise and model the pathfinding navmesh.
Group Services
The Group Services update was the main reason for pushing out a beta release of Firestorm 4.3.0.
This code allows for improved loading of membership lists of very large groups, together with improved reliability in editing such groups (i.e. assigning roles, removing people, etc.), by the group moderators. The server-side element of this code has been available on the RC channels for the last couple of weeks, and was deployed to the main release channel on Tuesday November 13th, making it available right across the main grid.
However, in order to be used, it requires additional viewer-side code. Without this additional code, the viewer will be unable to display membership lists for groups with more than 10K members (although any groups with fewer than 10K of members can still be edited using any viewer). Thus, the decision was taken by the Firestorm team to release 4.3.0 in a beta version so that users responsible for managing groups with very large members lists can continue to edit them.
In making this release, Firestorm joins Cool VL and Niran’s Viewer in being able to handle large groups alongside the official SL beta viewer. However, the remaining TPVs are likely to have updates to support the capability out in the near future (and the code will soon be available in the SL release viewer as well).
Please use the page numbers below to continue reading this review
top of page
Inara Pey: Living in a Modemworld 
Just a dummy comment to provide you with the correct spelling of my name… ;p
LikeLike
Erp… I thought I did a cut-and-paste. Did for the others.
LikeLike
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.
LikeLike
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.
LikeLike
Some of them already have a JIRA, though I’ll make some as well.
LikeLike
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…
LikeLike
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.
LikeLike
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.
LikeLike
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.
LikeLike
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!
LikeLike
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 :).
LikeLike
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.
LikeLike
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
LikeLike