Monday 27th saw Firestorm 4.2.1.29803 released. Unfortunately, this included a visual bug being inadvertently introduced into the release which made moving items such as doors and wheels appear to be “broken”. While this was only a visual impact rather than a code breakage, the decision was taken to withdraw 4.2.1 and replace it with 4.2.2 once the problem had been fixed.
As a result, and in case the release of version 4.2.2 included additional updates necessary as a result of fixing the issue, I opted to hold-off on my review of 4.2.1, and wait until I’d been able to look at 4.2.2 before Pressing a review.
So here it is, a look at Firestorm 4.2.2, featuring some of the key changes and updates which include an initial implementation of pathfinding. Alongside this, the release sees includes Katharine Berry’s snapshots-to-Flickr option, temporary uploads from the snapshot floater, new toolbar buttons and more.
A Note on OpenSim
This release does not include any fork between Second Life and OpenSim. That will be coming in a future release, which, as Jessica reports in her blog post on this release, might be a while in coming as the team have a lot of work on their collective plate.
Installation
The windows installer is some 33.7Mb in size – so par for the course with Firestorm. If you’ve previously installed version 4.2.1.29803 then a clean install is not required. However, if you’re upgrading from 4.1.1.28744 or earlier, a clean install is required / recommended.
Pathfinding Tools
As mentioned above, and with the exception of navmesh visualisation, all the main pathfinding tools are present in this release, complete with the expected Firestorm finesse when it comes to Rebake Region.
The Linksets and Characters floaters can be accessed using both the context and the pie menu when right-clicking on an object or character. The Build and Object Profile panels also have their pathfinding information panels added.
The Firestorm team have implemented the Rebake Region functionality somewhat differently to Linden Lab. Rather than incorporating a button displayed at the bottom of the viewer window when a rebake is required, the team have combined the rebake function with the pathfinding icon displayed in the Menu Bar / Navigation Bar (if displayed). Thus, when the icon is displayed (either with or without the initial warning pop-up, as shown in the image below), clicking on the icon will display a dialogue allowing a rebake to be initiated.
Combined with disabling the initial pop-up (by checking Do not show this again), this option makes the need for rebakes less intrusive when using Firestorm.
New Buttons
There are three new toolbar buttons in the 4.2.0 release: Asset Blacklist and Sound Explorer, both of which toggle open / close the Asset Blacklist floater or the Sound Explorer floater respectively (each otherwise accessible via the World menu), and Ground Sit – which is pretty self-explanatory.
Snapshots: Flickr, Temp Upload and More
Flickr is a popular medium for SL photographers, so having an option to save pictures directly to it is likely to be a benefit to many. With this release, Firestorm obtains Katharine Berry’s code to enable snapshots to be uploaded directly from the viewer to a Flickr account.
In order to work, this functionality requires Firestorm is authorised to access a Flickr account. Therefore, the first time the Flickr tab on the snapshot floater is clicked, a pop-up is displayed, both explaining the need for authentication and what will happen. Clicking on NO on the pop-up will stop the process, and you can use another option on your snapshot floater for saving the image.
Clicking on YES will take you to the Flickr authorisation page, which will outline the possible risks of connecting Firestorm to Flickr (a standard alert page, common when using inter-application authorisation). Read the warning carefully, and if happy, confirm you wish to proceed (refusing cancels the link and denies Firestorm the ability to upload to Flickr).
Confirming that you’re happy to proceed will display a code number on the Flickr web-page. Type this into the authorisation pop-up displayed in Firestorm to complete the authorisation process. Once done, you’ll be able to upload pictures to your Flickr account without further hindrance.
This release of the snapshot floater also includes an option to temporarily upload a snapshot to your inventory. Temporary snapshots are saved to your Photo Album, where they will be available for personal use (e.g. non-transferrable, etc) until your next re-log. Finally for the snapshot floater, all settings changes are saved between sessions.
Use the page numbers below left to continue reading
Inara Pey: Living in a Modemworld 
They are very good at making UI uglier or less intuitive. The Flickr snapshot panel is a complete mess, and the group chat muting UI is arranged such that there is an implied dependency between the chat muting and group message blocking functionality (there isn’t).
Sigh.
LikeLike
The big UI problem I see is the Pathfinding stuff brought in from the Linden Viewer.
How many n00bs know, for instance, that they are not “mobile objects”, and what’s the point of encouraging them to press a button to start a navmesh rebake when it won’t do anything (needs build permission for the land).
I don’t use Pathfinding. I don’t have a use for it in my 512 sq.m. and I doubt I’m ever going to want to work on the Navmesh. The Firestorm people say they’ve made the UI less obnoxious, but it’s still being thrust in my face.
What I liked was the way that I could organise the Firestorm UI to suit my needs. Pathfinding breaks that. The worst is in the Pie Menu system, but if I could turn off the whole damn lot, like I can the Advanced and Debug menus, I would.
It is essentially, an advanced option. and every TPV is being dragged down by Linden Labs incompetence over deploying Pathfinding.
LikeLike
Here’s where I’m at a loss.
Leaving aside the fact (and I know I’m committing sacrilege is saying so) I find the pie menu about the worst abomination in the history of UI design and utterly lacking in any form of intuitive use… it seems to me that every TPV that has implemented pathfinding has done so such that the pathfinding option appears on the “last page” of the pie menu, well clear of the other more commonly-used options most people will want to access – so why is it a problem in having them there?
While I do use the context menu, I’ve found that muscle memory has already kicked-in so that I can easily ignore the pathfinding option when I don’t need it (the majority of the time) and slip into using it when I’m trying to get my head around pathfinding. So having it in the menu is a non-issue.
As to the implementation of the tools as a whole, I think in fairness, that’s a tough one.
Right now, I seriously doubt pathfinding will have anywhere near the take-up LL are perhaps expecting, and it won’t in the near future. Ergo, putting the tools off into their own category or as an offshoot of, say, the Advanced menu would perhaps seem preferable.
But let’s say, just for a moment, that LL hadn’t bungled things. What if they had actually managed to line-up all their ducks and get pathfinding rolled-out to the servers, the tools to the viewer, given time for TPVs to adopt them and – most importantly of all – sought to educate their users as to the possible uses of pathfinding, providing factual information (rather than leaving it to rumour, misunderstanding and misinformation) and use-cases. What if that had, perchance, lead to pathfinding being seen as a useful tool, rather than some kind of impediment, but LL had chosen to “hide” the tools in the Advanced menu, rather than putting them with the build tool “where they should be”? It’s fair to say LL would be getting pasted right now for being “stupid” in their placement of the tools.
That’s where they are constantly on a hiding to nothing. No matter what they do, they are going to be perceived as “not listening”, “not thinking”, “not caring” by some in the community. It’s where I really don’t envy them at all – that they bring a really good proportion of the ire on themselves simply because they won’t communicate fully and properly, other than through a few select channels best suited to a minority notwithstanding.
Having said that, I personally believe that pathfinding won’t find widespread use on the grid. However, I suspect LL are anticipating it will be like mesh: an initial huge outcry from people (remember the PE hoo-haw of 16 months ago, and the claims that LL were trying to “kill” prims and enforce some kind of indirect “tax” on people?), which will die down and then pathfinding will start to see wider and wider use on the grid as has been the case with mesh.
In all probability, however, is that pathfinding will remain largely unused and ignored, simply because of the narrow focus of the overall appeal, and will remain so until there is a substantial shift in the nature and focus of the majority of people using SL; and that day, despite all the doom and gloom circulating, is still some ways off.
LikeLike
Katharine, having seen your implementation of the Upload-to-Flickr box inside your own compiled viewer, when you showed this to me, uh… was it two years ago?… I wasn’t soooo impressed with Firestorm’s approach to integrating it.
LikeLike
Two years ago indeed. Firestorm had my version two years ago until it broke, but they apparently never managed to fix it.
I rewrote it for Exodus (for which I am now a developer) about a month ago, and the new implementation is a bastardisation of that new version, which looks like this.
The group chat muting feature is also mine (from Exodus), which is why I highlighted it as UI that makes less sense now than it did before.
LikeLike
I wish I’d noticed this sooner…
Katharine, I reworked the UI because as it stood, it did not fit with the design of the rest of the Firestorm snapshot floater, nor with the rest of the Firestorm UI in general. Reworking the entire snapshot floater was not in the scope of what I was trying to accomplish.
UI consistency beats UI flash *every* *time*.
LikeLike
Of course you had to rework it – it would’ve made no sense in its prior state mixed with the rest of the Firestorm snapshot UI (and, as you observed, featured a number of controls that made no sense). Your implementation is consistent with the Firestorm snapshot UI just as mine is consistent with the Linden Lab snapshot UI.
The Firestorm snapshot UI is just ugly.
LikeLike
Hello Katherine, I noted that Kitty Viewer app is not enabled any more, and I cannot link firestorm to flickr any more can you help please?
LikeLike
The latest firestorm includes Katharine’s Flickr code for the snapshot floater, which should allow you to re-link to your Flickr account once more, as does the Exodus viewer (Katharine is also a member of the Exodus team).
LikeLike
Hello
i use the snapshot upload to flickr.
but now i use a new flickr account. How can i change the settings o the upload.
every uplaod is going to my “old” flickr account and i don’t find any settings where i can change something to use my “new” account for uploading.
please help me. best you send the answer also to my mail (gummisandra@yahoo.de).
thank you first.
Greetings Sandy
LikeLike
It has, incidentally, been suggested to me that the way to influence Linden Labs is to use the JIRA, a suggestion to which my response is likely to be short an obscene. But there’s always Shakespeare…
Glendower:
I can call spirits from the vasty deep.
Hotspur:
Why, so can I, or so can any man;
But will they come when you do call for them?
Henry The Fourth, Part I Act 3, scene 1, 52–54
LikeLike
While unrelated to the question of JIRA responses, reading that reminds me of a quote from Julius Caesar I really wish someone would nail to a wall at the LL offices:
There is a tide in the affairs of men.
Which, taken at the flood, leads on to fortune;
Omitted, all the voyage of their life
Is bound in shallows and in miseries.
On such a full sea are we now afloat,
And we must take the current when it serves,
Or lose our ventures.
– Julius Caesar Act 4, scene 3
LikeLike
And i will not try any viewer that has path find tools, cause i dont indented to use them as of course, most of SL users, another proof that LL can’t even figure what kind of users they have!
Or that they just decided that SL is now only a tool for them to test new products, so let it be, cause sooner they will be the only ones in world to test them, haaa i forgot, no LL worker goes to the grid anymore!
LikeLike
Just to point out…
Your own favourite viewer, Niran’s already has the pathfinding tools in a first pass. As does Singularity, Cool VL, Zen, and RLV, together with Firestorm. Exodus have confirmed they’ll be rolling the tools out, and Lance Corrimal’s recent announce vis-a-vis stopping OpenSim support would indicate he’ll be including them in Dolphin.
Just sayin’.
LikeLike
I think I have managed to sort out what happens with the Navmesh warning message.
1: The reference to “moving objects” is the jargon for objects being moved by the pathfinding system. But it may apply to vehicles and avatars because the Pathfinding navmesh is also the ground surface used by the physics engine..
2: Firestorm has an indicator icon but it will only appear with the other indicators (such as “fly” and “voice”) if you have the necessary permissions, and a navmesh rebake is required. You still get the warning message, but if you don’t have the permissions, you won’t get the button the message refers to.
2a: I’m told the icon is also used, with the usual bar-and-circle, if you’re in a region with Pathfinding turned off.
3: If the icon is there, and you click on it, you will get the usual confirmation box.
I have the feeling that, initially at least, the Firestorm support people thought the icon was visible all the time. I have been told that the Firestorm team felt they had improved the Pathfinding UI, which doesn’t bode well for the prospects when the Linden Labs version gets into the default viewer.
LikeLike
“I have the feeling that, initially at least, the Firestorm support people thought the icon was visible all the time.”
I don’t think that’s correct. The functionality of the pathfinding icon has always been clearly defined in that it is only displayed when a) the navmesh requires a rebake, or b) when pathfinding is disabled for a region. Ergo, I don’t think the Firestorm team misunderstood anything about its purpose / when it is displayed.
Given the fact that the icon is only displayed when the navmesh requires a rebake does actually make sense of the way the Firestorm team have approached things: if you see the icon in the Menu Bar and / or the Navigation Bar. Regardless as to whether you have the warning pop-up enabled or not, then you know that the region needs a rebake.
There is initially going to be some issues in adaptation for users in moving from other viewers (all of which has opted to implement the “standard” button-at-the-bottom-of-the-window approach favoured by LL) to Firestorm, but I don’t actually think it’s going to lead to any form of major confusion over things. What it’ll probably result in is more of those with build rights within a region ignoring the fact the region needs a rebake, as they’re not looking at the icon.
LikeLike
Trouble is, at least initially, they were telling me that the icon was in the navigation bar, I was telling them I couldn’t see it, and we were looping though checking various Preferences and Debug Settings, suggesting by their response that they thought it should be visible all the time.
I reached the point where I was wondering if they’d tested the various skins. After all, that rotation bug had slipped into 4.2.1 despite people seeing the effect during testing.
Firestorm support is good, and they shot off on the wrong track with this. When these pathfinding tools and warning messages hit the default viewer that everyone starts Second Life with, I fear the already low retention rate is going to plummet.
LikeLike
The icon is in the navigation bar – that’s the same for all viewers. With Firestorm, they’ve added it to the Menu Bar as well.
To me, what they have missed is pointing people to the icon when the need for a rebake arises – at least for those who leave the initial pop-up warning active (again a default from LL).
In other viewers, the rebake button is clearly visible at the bottom of the window, so on clearing the initial pop-up, it’s very hard not to see it. With Firestorm there is no button – an no revision to the pop-up informing people that they need to click on the icon. That, to me, runs the risk of confusing people even without people actually understanding the basic ins-and-outs of pathfinding thanks to the (so far) non-communication on the subject from LL (although we’re promised that will change … some time).
As to user numbers; I don’t know. I think it far too early to say. Right now there is (with respect to those directly experiencing problems) a lot of over-wrought reaction to pathfinding. All major changes to SL tend to bring with them predictions that they’ll cause a mass exodus, and it has yet to happen. Which is not to say it won’t, just that it has yet to happen.
For me, the problem really is that if pathfinding doesn’t prove to be used anywhere near the degree LL may be hoping, and they continue to push out capabilities which are perceived as “intruding” on people’s in-world experience (whether or not there is any measurable impact in terms of performance, etc) – then people are going to get increasingly pissed off and will start looking elsewhere.
LikeLike
So, well, I gave it a spin. I was particularly interested in how the Pathfinding tools have been implemented, and looking for improvements in performance. Firestorm seemed a bit crashy every time it started to load a navmesh on high-prim regions — but, to be honest, so is LL’s own Beta viewer.
In terms of performance… on my old hardware, it throws me back to pre-3.2 days. Let’s be honest: at this moment, compared to all the viewers I’ve tested — and I haven’t tested many! — the fastest kid on the block is the HTTP Project Viewer, winning by a large margin. I get at least twice the performance with it.
A typical scenario: shopping for mesh clothing, on SL prime time. On a popular shop with 20+ other avatars in view. HTTP Project Viewer gets 20+ FPS without shadows on, and this on a late 2006 iMac with an ancient and deprecated ATI Radeon X1600. Not to mention that everything rezzes so fast (even from a completely clean cache) that it makes me dizzy.
Other viewers give me perhaps 5, 6 FPS on a good day — which is what I would get with shadows turned on with the HTTP Project Viewer. I get far less on the 1.X series, even not displaying meshes…
LikeLike
Firestorm’s performance has definitely dipped – as have other viewers. I also have to be honest, when using the HTTP project viewer (which is aimed purely at texture handling, nothing else at the moment), I notice massively-faster texture load time, but no overall change in performance FPS-wise, whether running in deferred or not. I’ve not noticed with the SL beta or any other pathfinding-enabled viewer any more or less crashy than previous versions. However, I have noticed what appear to be a lot of “false positives” on rebake alerts on Firestorm.
LikeLike
As i told, i refuse to use any then Niran on Sl, but on OSG i fired Firestorm, entered in world and in less then 5 min i was taking easily snapshots to Flirk, using All at max res, shadows and dr (To bad really that they didn’t even manage to place tone mapping and didn’t learn about how to make graphics look amazing!)
So it works great on OSG for sure, even if it is just imprudence with mesh in terms of graphics quality (and that by itself is already very good), but its inbuild Ao and the fact that the v3 interface makes the screen free of stupid bloating tabs (Nobody but newbies and I guess a few that really tried, can’t understand how a v1 interface now is so clumsy and useless compared with the freedom of the v3 and the fact that your screen gets really immersible now).
So it is my viewer of choice for OSG, even if it is useless with shadows as Fps hit is outrageous compared to a more modern viewer like Niran or Exodus (Don’t even try to deny that Inara, your computer is not even as close as good as mine and my love 1, so i can tell you that there is a big diff when using tone mapping combined with dr and shadows, for the better in terms of fps and quality!!!)
But the grid manager, flirk options, v3 interface and osg search engine plus its inbuild ao and mesh support, makes it perfect ot OS grid nevertheless!
Can’t wait for the v5 forked version!
LikeLike