Jessica Lyin' to Firestorm users: Don't Expect Working Update Any Time Soon

Well, at least she's not springing any big surprises on anyone.  Jessica Lyin' posted an entry on her blog April 5th stating flat out that there will be no usable update to Firestorm any time soon.  With server side baking coming at some undisclosed date in the near or not-so-near future, disgruntled users asking questions but receiving no honest or real answers, and as usual, Ms. Lyin' is, well, lying.

On the one hand, she says that the "coming Firestorm release DOES support Server Side Baking."  Then she turns around and says that she and her team of suckups won't release the new viewer now "[b]ecause Linden Lab has not released their viewer with Server Side Baking yet. And if we release Firestorm now, and then LL realizes there needs to be more code changes for Server Side Baking that will affect both their viewer and ours, then we will have to do yet another release immediately after."

Okay, so where, you might be asking, is the lie?  In the first sentence of the blog entry, Lyin' says flat out "that the release is quickly approaching."  Define "quickly."  If we go by the timeline Linden Lab has traditionally adopted, "quickly" could be six months or a year from now, or two years from now, or maybe never.  That's not what any reasonable person would call "quick".

So basically, Jessica Lyin' is telling Firestorm users that although the next update will be ready to roll out very soon, if not now, they're going to wait to release it until Linden Lab officially rolls out Server Side Baking, which could be a while in coming.

Commenter Bear Silvershade rightly called B.S. on this one, stating:

I had to think about responding to this thread, because invariably, the small number of people who voice an opposing view get bashed or labelled a troll. Sadly, that is likely to happen to me, but I am so frustrated.
So let me see if I have this right. You are not releasing a version of Firestorm you have, that you feel is stable, and would likely include the long awaited snapshot tiling fix, because… you don’t think it would be cool to have to release an update a few days to a few weeks after this one?
I admit I am not a loyal firestorm user. Though I think it is one of the best viewers available, the infrequency of updates to take advantage of newer code or newer features has always been a concern. That came to a head in December when the tiling bug fix came out. Since one of my main activities in SL is making images, that was a major fix, and one that many others had been waiting for as well.
That’s when Firestorm lost me completely. It’s now four months without that fix being implemented. The absurdity of including William Weaver’s phototools to make this an ideal viewer for image makers, even starting a flickr group to show off images made with it, but not getting out the tiling fix as soon as possible still has me shaking my head.
Other viewers, including LL, release regularly. Are you saying that you can’t even come close to living up to that standard?
More annoying, it appears from one blogger’s comments that there was a stable beta available some weeks ago, apparently only available to a select few.
Now we have to keep waiting, even though you have something you feel is releasable? I am sure I am not alone in being willing to update my viewer a few days after a release. It happens with all kinds of software.
Now, before the putdowns start, you really want users avoiding posting for fear of retaliation or otherwise being shut down or disregarded? Or would you rather have an inclusive group where users feel like they are contributing and their concerns are honestly being listened to.
I will likely try the new viewer when it comes out, hoping that it lives up to the wait, though I have some concern that it won’t.
But that’s as may be. The fact is, in the end, there are other viewers out there, including the Lab’s, that do offer regular updates, so problems are dealt with and new features/fixes are available.
Jessica, I applaud your and the team’s commitment to quality. But it’s time to leave this no beta model/favoured few model behind and show a little more respect for your user base.

Naturally, Lyin' went on the attack with her patented brand of lies combined with condescension and dismissal.  Bear replied:

Perhaps you could try not trying to pack so many changes into each release? You will always be chasing the next feature, and if you are waiting till a whole bunch is perfect, well this is the result, that needed working features aren’t released, because you are waiting on something else.
As to regular releases, well, I am not worried about how popular the viewer is. Exodus, like Zen, appears to have ceased development, though while they were developing, offered nightly builds. Singularity, when the tiling fix and others features/patches came out, got a baseline viewer out that they plan to build on, in a reasonable time frame.
But Dolphin releases regularly, usually every two weeks or so. Niran, while I think it goes too far wit UI changes, also releases regularly.
But as to “irresponsibly releasing a build” that’s what a system of development and beta releases are for… let us decide, instead of adopting this paternalistic and, frankly, somewhat condescending attitude. If I am trying a LL dev build, as I often do, and it has a problem, I don’t get angry at them, it was my choice. I’ve never got to report a bug, since others usually find them before me.
Though you say you are not dismissing my concerns, frankly, that is exactly what you are saying in your final sentence. “We have reasons, you just don’t understand” is how that comes across to me.
Maybe if I say it more clearly.
1) It is disrespectful of your larger user base to release betas to a special few so they can enjoy the benefits (and, yes take the risks)
2) It is a poor model that ends up with four months between releases, leaving users without fixes that are ready to go.
3) Incremental releases allow us to decide what level of chance we are willing to take.
4) Contrary to your comments, many viewers, including LL and TPVs, release more regularly, getting improvements into the stream as they are available.

More lies, condescension, and dismissal from Jessica Lyin', followed by a disheartened final response from Bear.  Again, no big surprise there.  The baseline response from Ms. Lyin' and her merry band of suckups is always to go on the attack, dismiss any and all criticisms no matter how legitimate, and engage in rampant dishonesty.

User Sorrow made the following observation:

Only issue is they generally don’t screw up either. Every CoolVL weekly patch has worked flawlessly, every Singularity Alpha build aren’t problematic, same as Nirans, etc.
Only up to date released problematic and buggy viewer is Firestorm.
With firestorm updates being so slow, by the time this next version is released, it will already fallen 1-2 months behind the Official, CoolVL, Singularity Alpha, etc as the other viewers are already far ahead in development with the next batch of LL Patches, code, and new features..
It’s almost like, instead of thinking ahead like other 3rd party developers and working with LL developmental code and beginning to code and enact their own version of the LL future development, instead you wait until the official LL viewer to implement it, then barely start working on it, while on the other hand, the other 3rd party viewers have already released their own updates as they already completed development of the new features.
Sorta like this Server Side baking.. it’s been talked about for months and months, implemented on the developmental viewer then beta viewer for months as well, however it doesn’t seem like the FS team bothered* to begin working on it during this time (like the other developers), instead waited all the way when LL was ready to roll it out on the official viewer, thus months behind everyone else.
“viewers with such a small user base can afford to screw up where we cannot.”
you should follow CoolVL’s or Singularity’s model, have weekly or bi-weekly (even monthly would be better than nothing) releases labeled as “Alpha (Use At Your Own Risk)” no matter how small the patch, having regular releases, even if they are alpha or beta versions, this will more likely keep everyone satisfied, plus help your team locate and identify bugs if you have an alpha version JIRA rather than previously where the bugs end up being located within the official major releases (much better idea than this “Preview Idea” as a few days probably isn’t enough to locate all problems in a viewer.

I put the key parts in bold-type. *: I corrected a grammatical error so the sentence conveys the writer's meaning.  Anyway, Sorrow makes a very good point: Henri Beauchamp and Siana Gearz update their viewers much more frequently than Jessica Lyin's team does, and their crews are smaller.  They do, however, have the benefit of being more talented programmers, and they stay ahead on the updates.  Lyin' is basically dismissing these and other TPV developers as being too small and insignificant to emulate so as to better serve her users.  Do you feel insulted by that attitude?  I am, and I don't even use Firestorm.

So there you have it.  Jessica Lyin' has what she claims (probably falsely, as usual) is a workable update to her crappy viewer, but won't release it until after Linden Lab rolls out Server Side Baking, which means it could be any time between now and never.

Oh well.

By the way, for any of you programming wizards out there who might be interested, I managed to download the code for Phoenix Viewer (not Firestorm), so that it can be updated and resurrected under a different title.  I have no programming skills, but I can pass on the files for you to work with.  What you do with them is up to you.  Send me an e-mail or reply in the comments to let me know if you're interested and I'll find a way to share the files with you.

Problems with Server Side Baking

Here are some links regarding the in-development server-side-baking feature being prepared for gridwide use by Linden Lab:

http://modemworld.wordpress.com/2013/02/23/sl-projects-week-8-3-viewer-materials-and-ssb-load-test/

http://modemworld.wordpress.com/2013/02/23/playing-with-ssb-and-viewers-quick-test/

http://modemworld.wordpress.com/2013/02/25/viewer-round-up-summary-week-8/

As expected, there are some issues with the feature, but many Third Party Viewer (TPV) developers seem to be getting their viewers up to speed, most notably Singularity and Cool VL Viewer.

Not surprisingly, the Firestorm elitists and liars are having a tougher time getting their resource-hogging, crashtastic, low-frame-rate to work, and are claiming that it will likely be some time before a stable version that can handle Serve Side Baking will be released -- so naturally, the Firestorm clowns will release a version of the viewer that has SSB before they can even get it working properly with Linden Lab's code.  "Genius" at its finest.

Also not surprising is that some commenters aren't buying the lies Jessica Lyin' and her merry gang of suckups are telling.  "Joseph" writes:

It really does not surprise me at all that Firestorm is in such a terrible state right now. And at the meeting it sure had a tone and implied like so many problems are caused by LL’s code even though Jessica did make sure to state that many problems come from Firestorm itself. The LL 3.4.5 is a GREAT viewer and certainly isn’t some mess of buggy code like it sounds like the Firestorm devs make it out to be. If any Firestorm user or any of the Firestorm devs truely used the LL 3.4.5 viewer for a decent amount of time they would see that not only does it perform a hell of a lot better than Firestorm it has a hell of a lot less bugs. Firestorm is a crappy clunky mess in comparison. All things considered the LL 3.4.5 viewer is an awesome viewer. The problems Firestorm is having right now is because instead of just adding features and UI improvements over the past couple of years to the LL viewer, they have delved and messed with so much of the internals of the program itself thinking they can do everything better than the lab. If one looks at the commits to the code since the beginning of Firestorm over two years ago, the developers have mucked and messed with so much more of the code than just adding features and UI changes. Instead of just letting LL deal with the internals of the program they have gone in and tinkered and messed with so much of the guts of the program itself and this is why now after merging it is such a terrible mess. If the Firestorm devs had a minimalistic approach to what they changed in the code other than UI improvements and adding features, the current internal version wouldnt be the unstable horrendous god awful mess it is now. Anyone can go to their mercurial repository and see exactly what they do to their source code, and see hundreds if not thousands of commits since the beginning of the project of them making changes to the core engine of the program so to speak and that is why they are in the mess they are in today. Often times Phoenix was described as a monstrous unmaintainable collection of hacks held together by bail wire, spit, duct tape etc…and the irony is that now a days that is exactly what Firestorm has become.

As evidenced from this and other comments, not everyone believes what Ms. Lyin' has to say, and for good reason -- people know from actually trying to use Firestorm that it's an unworkable mess of code, the very same critiques used against Phoenix, which actually works on more people's computers and which has now been abandoned by the developers.

As for the Server Side Baking issues, it's clear that the official roll-out may not come quite as soon as previously stated by Linden Lab or others.  It'll be implemented across the grid sooner or later, but it seems clear that the TPVs most likely to have stable viewers that have SSB won't include Firestorm.

End of an Era for Phoenix Users

As many of you already know, the Firestorm snobs have officially abandoned their only viable SL viewer in favor of an unusable, bug-riddled, resource-hogging piece of software junk.  The decision to kill Phoenix Viewer was always that of its developers, and now they've pretty much done it.  People can still log on to Second Life using Phoenix, but since it's no longer being updated features will continue to break as Linden Lab implements new code that is incompatible with Phoenix.

And it's a real shame, too.  Phoenix has a user interface that is far superior to Firestorm, is intuitive, and doesn't force you to spend countless hours trying to figure it out.  What's more, Phoenix always had and will always have a higher frame rate, more stability, and use fewer computer resources, than Firestorm.  Abandoning it might just bite the Firestorm snobs in the arse as people move on to Singularity and Cool VL Viewer.

Well, I guess it's time for me to move on to Singularity full time.  I won't be able to do as much building on that viewer, since its abilities to position prims aren't as precise as Phoenix, but I'll keep on the developers to get that problem addressed.

Doctor Who Series 6 and Sarah Jane Adventures Series 4, Decision Time, and Demolishing the Lies About Viewer 1

 DOCTOR WHO SERIES 6, SARAH JANE ADVENTURES SERIES 4

I was able to get hold of both seasons on DVD, and once I've gone through all episodes of SJA, I'll issue a review of the latter series.

I maintain my criticism of Moffat's tenure as head writer of the show as one fraught with inconsistency — on an overall storytelling basis, that is.  Moffat does well in doing one-off stories, but trying to keep a longer term story arc running and maintaining story continuity are two tasks he can't seem to balance.  We'll see how Sarah Jane Adventures' final season pans out.  Considering it was the last complete series of the show before lead actress Elizabeth Sladen passed away, there's going to be a certain poignancy watching that is bound to color my review, but I'll try to do justice with an honest one.

DECISION TIME

Now, I've been thinking a while on the events of the past year or so.  2011 was, needless to say, horrible for me, and a fairly large chunk of the SL side of things was my own fault.  Swiping prims from a copied Dalek avatar in a fit of impatience was pretty stupid, and that's going to haunt me for a long time to come, no matter that I paid back the guy whose builds were swiped and admitted what I did.

Since then I've passed the remains of Archangel Network over to others, and it now exists in the form of Sci-Fi Enterprises.  Right now the only things it sells are unscripted TTC exteriors and freebies, and that's it.  I haven't had the time or the inclination to package up my unscripted console builds, but I've been seriously thinking of changing that.  I'm tired of having them sit in my inventory gathering pixel dust.

Of course, even if I were to do that, what then?  Who'd buy an unscripted console?  The whole point of having a TTC in Second Life is to have a grid-wide teleporter that serves triple duty as a skybox and role-playing scene.  It kind of defeats the purpose if it doesn't actually do more than look pretty.

It doesn't help that two of my closest friends in SL are on indefinite hiatus from SL, and one of them was a scripter whose skills were slowly but steadily improving.  I was hoping that my consoles would one day be sold with a functioning set of scripts again, and that is true of two of them, which are sold through Novatech.  Those are the Steampunk and the Zero 3.0 console.  But the rest languish in my inventory, and that's just a waste.  I'd love to be able to script them myself, but I've had to accept that I'll never be able to find someone willing to teach me what I need to know.

So what are my options?  I can try to convince my scripter friend to return to SL, hoping she'll script my consoles for me, or I can hire someone else to do them up and do a fifty-fifty split on sales.  But then, given that the last scripter I had disrespected me, then stabbed me in the back by trying to take over my company, I've got obvious issues with the idea of letting someone else have that kind of advantage over me again.  I've been burned too often by trusting all the wrong people.  Never again.  I can always submit my builds to other sellers, but most of the Whovian TTC sellers in SL are either severely backed up on submitted builds or not inclined to have anything to do with me.

I'll have to make a decision soon as to what I want to do with my builds, and more than that,what I really want to do in SL.  I have goals I'd like to achieve, but never the means.  And really, there just isn't any point to having those goals if I can't ever possess the resources to accomplish them.  And then what's the point of even staying in SL?

Ya know what I'm sayin'?

 "VIEWER 1" IS NOT "GOING AWAY"

There are certain people going around spreading lies about the fate of SL Viewer 1.23.  They claim that because Linden Lab is no longer offering updates or support, this means that the viewers are going to go away any time now, so we had better get on the crappily designed, highly unstable, resource-hogging Viewer 2 and its clones — or we will be forced out of SL altogether.  The truth is that Viewer 1, or more accurately, Third Party Viewers (TPVs) that use the Viewer 1 graphic user interface (GUI), are going to be around at least until their developers decide to quit the projects.

One person to expose the Big SL Viewer Lie for what it is is Henri Beauchamp, the programmer who brought us Cool VL Viewer.  Henri's code work was incorporated into the latest Phoenix Viewer release, albeit grudgingly and still with the lies about Viewer 1 going the way of the dinosaurs.

Why is this claim a lie?  For one thing, no one making it is able to give a definitive date for Viewer 1 GUI being shut off.  This is because, according to witnesses, Rodvik Humble himself stated that Linden Labs "would NOT be turning off v1.x access - just that they would NOT be updating the 1.x viewer themselves, so their version would not be kept up with the new features - that would be the responsibility of the TPV coders."

What this means is that the CEO of Linden Lab himself is saying that there are no plans to turn off Viewer 1 access — no company is stupid enough to literally block access to its product for more than half its user base.  They're simply not offering updates or support for it anymore.  As long as TPV programmers are able to back-port features like mesh and other goodies, like Henri Beauchamp, Boy Lane, and the Singularity Viewer developers, SL Viewers that use the Viewer 1 GUI will stick around.  As one member posted on Henri's forum, the liars are starting with the false assumption that a viewer's features are inextricably bound to its GUI, and then using that false assumption to create a false rationalization for why they want to force everyone else who uses SL onto the Viewer 2 GUI viewers, namely, theirs.  But as was pointed out, "under-the-hood" features simply are not tied to the GUI.  At this point the only real difference between the official Linden Lab viewers and the TPVs generated using the Viewer 1 GUI is only...the GUI.

It is highly dishonest for people who love Viewer 2 GUI viewers and their clones, and despise Viewer 1 GUI TPVs, to claim that those viewers with the Viewer 1 GUI are going away.  They're not.  Linden Lab isn't claiming that they are turning off access to Viewer 1.  TPV developers who still like the GUI on Viewer 1 will continue to back-port Viewer 2 and Viewer 3 features into the Viewer 1 GUI until the only thing that is still "Viewer 1" about them is how the finished program looks on your screen; in fact, they're pretty much that way already.  If you don't like the Viewer 2 or Viewer 3 GUI, or if you simply find that the Linden Lab-approved viewers are still too buggy and unstable, you do have alternatives, and you will continue to have them for a while.

For your downloading enjoyment:

http://www.singularityviewer.org

http://my.opera.com/boylane/blog/rainbow-viewer

Cool VL Viewer - http://sldev.free.fr

http://downloads.phoenixviewer.com/windows/Phoenix_Viewer-1.6.0.1600_RELEASE_SSE2.exe


http://downloads.phoenixviewer.com/Mac/Phoenix_Viewer_1.6.0.1600_Intel.dmg

http://downloads.phoenixviewer.com/Linux/PhoenixViewer-i686-1.6.0.1600.tar.bz2