Update February 25th: As per a comment from Jessica Lyon, Firestorm have now merged the Server-side Baking code and updates to RLVa into one of their private repositories.
Update, 19th February: A transcript of the core part of the meeting, including Jessica’s Firestorm status overview and the Q&A session, complete with the video recording, is now available.
Update, 14th February: The initial video recording of the meeting is now available on YouTube, and an HD version will be available soon.
Wednesday February 13th saw the Firestorm team host an open meeting to discuss what is happening vis-à-vis Firestorm given all the various ongoing viewer-related projects currently underway (CHUI, materials processing, server-side baking, plus Firestorm’s own updates and improvements) – and when the next release is liable to hit the public at large,
Several members of both the Firestorm development and support teams were on-hand to field questions, with Project Lead Jessica Lyon leading things off with a 15-20 minute overview as to what is happening, where the viewer stands at this point in time, what the plans are for the immediate future and what we might expect to see in Firestorm in upcoming releases.
The Short Version
- The Good:
- Firestorm will be supporting all of the new viewer capabilities coming out of LL, although CHUI will require careful consideration as to what is adopted and how, as Firestorm already offers several similar options to those being added to the viewer by CHUI
- Firestorm will be getting a range of new features (although not all at once) which include: further work on re-implementing legacy search capabilities, the ability to save and reload personal settings; more OpenSim support; new windlight settings; new UI skinning; further work on adding v1-style functionality
- The Not-so-good:
- Serious crash and other issues have also come to light in merging Firestorm with the latest LL 3.4.5 code which the team are endeavouring to resolve
- Server-side baking (SSB) is the priority for the Firestorm team at present (as it is with other TPVs), as it has a major impact on how people will see things in-world, and it is the project which LL are emphasising. However, integration of the SSB code into TPVs (particularly those supporting RLVa) is not proving easy
- The emphasis on work at the moment is overcoming bugs, issues and problems and trying to get Firestorm to a point where it is running the SSB code.
Taken together, the latter points mean that while a new version of Firestorm is in development, there will be something a further wait before it appears, and when it does, it my not have such a huge range of new features as has been found in previous releases and might suffer from stability issues.
Viewer Status
There are some serious issues within the Firestorm development code which are delaying progress towards a potential release. Firestorm has been merged-up to the Linden Lab 3.4.5 viewer code, and this has given rise to some severe problems for Firestorm (and is actually having an impact on other projects, as I reported earlier this week).
Commenting on the situation, Jessica Lyon pulled no punches, stating:
I’m going to be completely honest with you guys. Right now Firestorm, for us internally, is in pretty bad shape since our merge with Linden Lab’s TIP (3.4.5 code). There are a lot of bugs that we’ve inherited; there’s a lot of regressions which we’ve inherited. Ed [Merryman, lead for Firestorm Support] is crashing about two times a day – and for those of you know Ed, know that Ed never crashes. So if Ed is crashing on our recent builds, we’ve got some problems. We’ve got some log-out crashes, log-out things; log-in crashes … Basically, we’re not in great shape, and we’ve got a lot of fixing-up to do before we’re ready for a release.
As well as inheriting bugs, the merge has also highlighted bugs and issues within the Firestorm code itself which also need to be fixed. All of this adds up to recent builds for the viewer being “way worse” than the current release version in terms of stability and issues, and it is going to be a while before these issues are fully resolved.
Server-side Baking
Server-side baking is perhaps the most prominent viewer project underway at the moment, inasmuch as it is essential that all viewers connecting to Second Life be able to support it in order to avoid in-world experiences from being broken. Simply put, avatar skins and system clothing will not render on viewers which do not support SSB once the code is fully deployed, as shown below. )Things are somewhat more involved than that, and for those unfamiliar with the project, I’ve covered it in-depth in Avatar Baking: “and the clock has started!”. )
As it stands, Firestorm has yet to be merged with the Lab’s supplied server-side baking code for the viewer, although work has been underway within the team in a separate repository to the 3.4.5 code merge. A major problem here, as I again reported earlier this week, is that SSB has considerable (and negative) impact with RLVa. These problems are compounded by the fact that the test regions for SSB functionality are all on Aditi, which has considerable issues of its own at the moment, which are affecting people’s ability to reliably test code, and all have scripts disabled – which makes testing RLVa fixes alongside SSB somewhat difficult.
Currently, the Lab remains sympathetic to the issues TPVs are facing (and have offered help wherever practicable), and are not currently pushing a date by which TPVs must be ready for SSB to go live. They’ve also acknowledged that some of the problems TPVs are facing are down to delays on the Lab’s part, such as not making any bug fixes to the viewer code available until January 30th, some seven weeks into the planned eight-week window in which it had been hoped TPVs would be able to integrate the code. However, it is clear that TPVs are feeling under pressure to get SSB-capable versions of their viewers sooner rather than later.
Please use the page numbers below to continue reading this article
Inara Pey: Living in a Modemworld 
Starting to sound like the FS team is working on things they said were impossible to do, funny how things turn out like that, but all in all, glad to see that they realized their (for lack of a better word) bluff wasn’t working and they’re now going to start working on fiddling with things to bring about V1 again.
If nothing else, they could collaborate or get some help from the Singularity team, who’s brought in almost every main V3 feature into the V1 viewer with no stability issues at all. I dunno if it works in reverse, but hey, these “miracles” are happening across the board and SL is benefiting greatly. I wouldn’t even want to imagine how small SL would be without TPV’s~
LikeLike
No, they’ve not changed their tune and no, they’ll not be “bringing about v1 again”.
The Firstorm team has always maintained they’d strive for as much v-1 like functionality as possible. However, as noted here and during the meeting, as as endlessly mentioned in past blog posts, some things are simply not possible either because the v3 code won’t support the changes being demanded, or the changes are simply too much of an overhead technically to implement and then support or because the changes represent support issues for the FS support volunteers – or because of a mixture of all three.
This has always been their stance, and remains their stance.
LikeLike
They have changed their tune a few times, you of all people should know, but I’m not terribly worried about that. They’ve worked quite hard to bring v1 back, so it doesn’t make sense to deny it when you’re writing about how they are current planning on or currently in the works of doing it.
LikeLike
*YAWN* – You’re beginning to sound like a broken record. So thank you, please drive through.
LikeLike
This is actually a related topic, but wholly different from the last few discussions, aside from that – Why don’t you mind your own business?
On a personal side note; wouldn’t this someone count as public interfering, and the attempted start of internet drama? Your top 2 dislikes, right?
Non-deadpan passive-aggressive comments are on my dislikes, so good day to you.
LikeLike
You still sound like a broken record. Other than repeat yet again how much you dislike Firestorm, do you have something to say?
LikeLike
Now you’re sounding like a broken record. And I don’t dislike Firestorm, if you are actually following what I’ve said in recent weeks, then you’d know that.
Do some research before posting, or you could simply not post at all and both our time would not be wasted.
LikeLike
All these changes and updates are good and all but I see nothing in regards to the voice component being fixed with the new MAC OS X Mountain Lion. We still have absolutely no voice abilities at all with this most recent release. When will this be addressed and fixed?
LikeLike
Did you miss the part where Linden Labs is going to change the basic architecture of the way things are going to be done?
LikeLike
Open the gates and set loose the Wackadoodles! “Conspiracy”, “The end of SL”, “Everyone will leave / no one will come”, “I know a better way”.
sigh – – – – – . . .
LikeLike
Aren’t they already here? 🙂
LikeLike
When do they actually stop handholding their users and start arriving in 2013?
LikeLike
Some of us actually practice good software engineering practices and don’t suck up every changeset that shows up on the radar from every source. Some of us also care about more than just the bleeding edge.
LikeLike
I can only say that, on a platform where the operator is routinely (and rightly, in many cases) at the receiving end of calls for better communications and frustration that they don’t reach out to their user community consistently through all the channels available to them, the Firestorm team’s attempts to actually do so is actually to be applauded, particularly given the sheer weight of numbers users their viewer(s).
LikeLike
There’s a pattern I see with the LL Viewer which sits uneasily with the Open Source idea.
How many of the bugfixes which TPV developers implement get into the Linden code? The successful Open Source projects don’t use every third-party bugfix, but at least they talk to the people submitting them. The Lindens often seem unduly reticent about bugs, and the current JIRA system is no help.
LikeLike
I think this rings a few bells that resemble what Oracle did with OpenOffice. There are, of course, differences here, but some similarities regarding the mindset seem to be present…
LikeLike
Actually, many TPV bugfixes *do* get into the LL viewer. In particular, a lot of the crash fixes in Firestorm got into the LL viewer pretty quickly. The main thing is that the fix needs to be submitted to LL by the author if it’s more than a very few lines; LL does that to avoid any questions about ownership of their code.
I do agree that the current JIRA is a serious mistake on LL’s part.
LikeLike
If you don’t like it there’s plenty of other viewers you can be using.
LikeLike
Angelita, Niran is very aware of the number of viewers available – he actually develops his own viewer, also on the TPV directoy – Niran’s Viewer…
LikeLike
Firestorm’s communications tools/floaters are probably the number one reason I use Firestorm so frequently. Having said that, I also have come to really like CHUI. This is a project out of LL that’s gone really well. I can’t help but feel that LL must have looked at how TPVs handled communications, decided that there were great ideas there that could be polished up, and did exactly that.
Materials… awesome. 🙂 I got my greedy hands on a binary of the (currently crashtastic) code in the materials repo, and created some normal maps for some of my meshes. Mmmm… that was a nice taste of things to come.
Settings backup… nice! I do clean installs of a variety of viewers frequently, and make sure to manually clear out any cruft left behind. So this will be handy, and hopefully adopted on a wide scale. I am curious how well this will hold up if settings are moved or removed, as sometimes happens. One little thing I find irksome is that the last thing FS needs is something else in it’s preference floater. But other than dedicating a floater and menu item to it, I guess I’m not sure where else they’d put it.
Import/export is something people will love to have again. I’m wondering if their implementation will support content within objects. Support for Kitely’s export permission would be nice to have as well.
LikeLike
Ack. Ignore the link in my comment… it’s wrong. I meant instead the export permission mentioned on Kitely’s blog here.
LikeLike
From the description, it looks like the export flag will be a purely server-side thing, but I will be in contact with Kitely just in case. We try to support as many OpenSim-specific features as possible.
The problem with this sits with closed-source grids who keep their incompatible changes proprietary and secret, essentially biting the hand that feeds them. This has not, however, been the case with Kitely.
LikeLike
You may definitely be 100% correct. I’m not actually a user at Kitely, and I haven’t paid super close attention to their activities.
My reading of the blog post was that the export flag would be marketplace only in that that would be the only place merchants would have the ability to set an item as exportable. Since viewers don’t currently know about and can’t respect an export permission, that’s how I interpreted things. That they implemented it as much as they could, but without viewer developers on board, it only goes so far. But as you say, Kitely would know about that much better than I do.
There’s actually been fairly wide interest among the OpenSimulator community for the last few years in an export permission. Because this feature would require strong TPV participation, I presume that’s why it’s not gone anywhere. With it’s popularity, the participation of Firestorm developers would be a valuable step in making it a reality. Not that you guys don’t already have enough to do. 😉
LikeLike
Hi Cinder,
Lacking viewer-side support for setting/viewing an Export permission, we plan on implementing this flag only for items sold via the upcoming Kitely Market, where merchants will be able to set/view their items’ permissions.
If there were viewer-side support for this permission we would gladly use it for all items on the Kitely grid.
LikeLike
I agree on FS’s presentation with communications. The approach they use is not unique – other TPVs offer IM doking / undocking, vertical tabs, etc., but I still find FS’s apprach the most “comfortable”. I think it is fair to say that CHUI is more than a nod towards TPVs (and users) and an attempt by LL to move things in a direction that should enhance not only the usability of their viewer, but also (at least in terms of those who do routinely use TPVs, but may need to swap over to an “official” viewer at times) reasonably familiar, to be a very positive move.
Settings back-up & Preferences: perhaps this will be one of the options which people can add to their Quick Prefs for ease of access? No idea on the export / import functionality. Maybe someone from Firestorm can comment :).
Materials: I’ve had the opportunity to play with the recent private dev viewers being used to test this, and am really looking forward to seeing not only the deployment of the capability, but how it it will enhance the in-world look to SL over time – and how it will (hopefully) be enhanced itself.
LikeLike
I think I’ll be sticking with Singularity…..FS crashes like crazy on my machine. I love Niran’s viewer, but would need a much better computer in order to run it in such a way as to do it justice. In fact, Nirans was the first viewer I could ever get to work on my computer, as the original LL viewer simply wouldn’t run. Singularity seems to be the happy medium for me at the present moment.
LikeLike
That’s the beauty of having so much choice, the ability to mull over viewers and use the one which best meets our needs and hardware, be it the official viewer, FS, Singu, Cool VW, Radegast, Lumiya, etc. We’re really quite spoiled for choice!
LikeLike
The one thing that I think we all can agree on Linden Labs doing right was allowing 3d party viewers.
LikeLike
Firestorm only entered my computer for open sim, same with singularity.
No doubt i prefer Firestorm over sing, just for the fact that it allows a v3 xui (Yes, I still think if one lesson should be taken is Niran’s xui, but frirestorm is enough modulable to make the xui almost as logical and good as niran’s one!).
The only thing i was missing is the export/import and that will be amazing!
To firestorm team i can only say,. make your viewer the best for open sims, you will not regret it.
Check and think about allowing a xui choice like Niran’s.
If possible make a graphic sett that can be as good as Niran’s (It seems easy,. according to Gainz).
LikeLike
Import and Export is liable to provoke some very vocal merchants. There are already things which Firestorm can export which it cannot import. William Tare Fox and similar expressions of startled bewilderment.
I would like to see a rigged mesh come with a full-permissions shape, which I could export, and pass through an external utility, to gave me the correct shape with my unique head and face, which I can then import and use.
(I suppose that could be done within the viewer, but I prefer keeping that sort of tool safely outside.)
I now wait for a merchant drama-queen to bemoan the encouragement of content theft. But what, I ask, when I can get a word in, is the valuable property to me? The rigged-mesh, or the shape with a face that looks nothing like the identity I use?
The Mesh Deformer might short circuit this, but I have experience of the weaknesses of such tools.
LikeLike
There’s also another issue with importing and exporting stuff, especially from one virtual world platform to the other – and this is not only about the whole intellectual property issue that will certainly upset some extremely vocal content creators, but also because several things (sculpts, mesh, scripts) are implemented in a significantly different way between platforms – that way, chances of a successful import/export are slim.
LikeLike
Of course, it has to be pointed out that this import/export facility is (a) intended only for prim-based objects, (b) intended (if I’m not mistaken) only for content someone has created (and not content from others), (c) mesh and sculpt maps won’t really need to be imported/exported, because a creator will already have them stored on their hard discs, independently of their SL (or other virtual world) inventory. Also, it would be useful to point out that mesh is implemented differently across virtual worlds – while sculpts are pretty much universal.
LikeLike
We have been in SL for a longtime, used all browsers available, and have settled on Firestorm, as the best. New server software, and development problems with other browsers is not my concern. The concern is, with the viewers perception of the land I have built. I pay a lot of money to do what I do. It’s the Browsers Dev teams Mission to bring it to the viewing experience, in a consistant manner. What I don’t need now, is to be told it’s going to be a rough couple of months. Please explain why the Communication between Lindens and the Third Party Browsers can’t solve this?
LikeLike
I’m not sure what you mean by the “viewer’s perception of the land I have built”. All viewers – third-party or LL’s should effectively treat land the same way in terms of general management, the tools at your disposal for managing that land (recognising the parcel size and boundaries, tools for access control and terraforming, and so on).
Communications between the Lab and third-party viewer developers are, for the most part, relatively open. There is a mailing list where issues can be raised and responded to openly by both LL and third-party developers, and there is also a twice-weekly open-source development meeting held in-world between LL and developers and a viewer-focused meeting held every other week as well to help ensure a good level of information exchange and to assist in keeping TPVs informed (as much as possible) as to what is going on on LL’s side of things with regards to the development and enhancement of SL (there are also meeting sin which the server side of things are discussed, and which some TPV developers also attend).
However, even with these channels of communication and ongoing echanges between LL and third-party developers, and while there is perhaps greater sensitivity from LL towards TPVs in complex matter such as Server-side Baking, there can still be conflicts when it comes to the actual deployment of new functionality and capabilities to SL which impact the viewer.
This means that – and while it has not happened yet – there is a risk that the Lab might, despite their sensitivity to date, end up drawing a line in the sand and saying, “We will be rolling-out the new Server-side Baking on this date” – simply because they, and the majority of TPVs are reasonably confident they can support the service.
Because of this, the Firestorm team are sounding a note of caution, simply because they are undertaking so much and have a viewer which does offer considerably more capabilities than perhaps other viewers (which is itself an added overhead in terms of maintaining and enhancing Firestorm), that were LL to announce they were satisfied with their own progress on SSB, they are going to deploy it in (say) “3 weeks time”, the Firestorm team would likely have to freeze all other work on the viewer (bug fixes, etc.), and simply focus on making sure they can offer users a version of the viewer which supports SSB even if it is “broken” in terms of stability, etc.) – simply because if they don’t, every Firestorm user’s in-world experience will be broken.
This is hopefully a somewhat rare situation in this regard, as SSB is a hugely significant change to the way SL works, and it has come at a time when, unfortunately, several major viewer projects are all converging towards release (which also adds to the pressure). But in sounding a note of caution, the Firestorm team are simply being transparent and honet with their users s to their current state-of-play. Hopefully, the resasons for being so cautious will remain a “worst case scenario”, and not actually come to pass.
LikeLike
I am curious as to the status of the fix to the now well known bug of sound cutoff for media streams, requiring a relog to fix the issue. I was told Phoenix/Firestorm were aware of this bug and would fix it in the next release. Does this mean this rather annoying problem will still be around while you guys fix other problems with the next release?
LikeLike
There is a media fix which will be in an upcoming release of Firestorm. I gather it is to do with the issue of streams continuing to play once you’ve left a region. However, it may address other issues as well.
The best place to get a direct answer to your question is through the Firestorm support groups, as I and this blog are not not directly involved in Firestorm development nor affiliated with the Firestorm viewer in any way.
Sorry I can’t offer a more detailed response than this.
LikeLike
I understand. I was curious with the new host of problems the code integration was bringing if that meant already known bugs would have a delay in being fixed.
LikeLike
I think that will come down to a) whether or not the team is forced into a position of having to focus purely on SSB and get a release out (if a deployment date for SSB suddenly pops up), and b) The status of any given fix should that happen. So if the fix is ready and tested, it could well go in with the SSB release, if it is still being worked upon or yet to pass QA testing, it might be put to one side while the effort goes into SSB.
LikeLike
Bottom Line: I don’t want to know why a viewer does or does not work. I just want to know which one will work the best when the “Fit hits the shan”.
Suggestions appreciated. Thank you.
LikeLike
That’s a big question in terms of Server-side Baking.
Clearly, the Firestorm team have a lot on their collective plate, and it may well be that, as Jessica warns, the next release may well have significant issues.
However, it is fair to say (for the moment) that as there is no release date for the new SSB service, and LL have a fair few things to sort out for themselves, viewer-wise and with the project, it may well be that it is going to be a little while yet before SSB emerges – and that might be long enough for the Firestorm team to get a somewhat more robust build of the viewer ready for the SSB deployment than might otherwise be the case.
That said, all TPVs are pretty much in the same boat to some degree or another. Currently, only two viewers which are available and include SSB support are the official SSB project viewer and an experimental version of the v1-style Cool VL Viewer, although obviously the majority of TPVs will be working on implementing the required code. And the fact that the Server-side baking code has yet to reach the main ciewer code repositories at LL is also a sign that we have a little way to go yet before SSB is rolled-out.
As such, I’d suggest that right now there is no reason for undue worry. Keep an eye on this blog and other like it which regularly carry news on LL’s various projects and on the development / release of third-party viewers as well as on the official SL and Firestorm blogs, and see what news is forthcoming nearer the time.
LikeLike
This whole thing is sick. I can’t even run the labs viewer anymore .. it is totally broke on Ubuntu 12.04, and server side baking has no purpose whatsoever, unless it is just to lock down DRM for the benefit of vendors. The whole world is sacrificing everything for the benefit of sellers. Customers don’t mean anything anymore. I love Second Life and I hate to be pushed out this way by the Labs hatred of its most loyal customers.
LikeLike
Have you tried reaching out to Firestorm support vis. your Linux issues? They should be able to provide some guidance.
Server-side baking does service a purpose, as it is aimed specifically at ending issues of avatar bake fail which are, and have been for years, prevalent across the grid and which is something everyone has encountered at least once in their in-world times, if not on numerous occasions. It’s the situation where you log-in or teleport, and avatars around fail to render properly and appear blurred. Or when you change from one outfit to another, and you appear OK to yourself – but to everyone else you appear to still be wearing the original outfit (or you can’t see the outfit you’ve just changed into, but everyone else around you can). It’s when you think you’ve changed outfits, go out, and someone tells you that you appeat to be wearing two different outfits simultaneously where you see only one – or worse, they tell you you are naked, when you appear in your world view to be dressed.
SSB should, hopefully, solve all of these issues for us as far as avatar skins and system-layer clothes are concerned, and lead to a much improved in-world experience.
LikeLike
I have heard of some cases where Firestorm support people had suggested Linux users to “install windows” to resolve their issues.
Just as well then, the overwhelming majority of Linux users use Singularity now.
LikeLike
Seriously? Do you believe everything you hear?
LikeLike
You do realize that windows OSes are the majority right?
LikeLike
Yes server side baking is some that is needed and if well done it will make Sl way better!
LikeLike
Well, I have been trying out the new Firestorm…and I’m pleasantly surprised. I’m a bit lost wiht some of the differences between it and Singularity, but overall I’d have to say I like Firestorm. It’s certainly less crash-prone than the previous version, and although I often have issues with the sound not connecting properly (which never seems to happen with Singularity), it’s not a bad viewer.
LikeLike