All You Do Is Talk Talk: Disentangling the Firestorm Chat Settings

The Firestorm chat options are among the most customizable and therefore complex set of settings in the viewer—and possibly in any viewer. They are a mix of Linden and Firestorm code merged into or written into the viewer over the course of more than three years and designed to allow people comfortable with either V1 or V3 interfaces to find a combination they’ll be happy with.

Some of the terminology is non-intuitive, and many of the settings interact in ways that are difficult to anticipate without getting your hands dirty and figuring them all out.

Let’s start with some basics. There are three main formats in which you can view chat text on your screen. They are:

• Conversations window, sometimes referred to as “chat window”
• Console, sometimes referred to as “onscreen console”
• Toasts, which are popups that show up differently as local chat versus IMs

If you know what each kind of chat is called in the viewer preferences, you’ll be more likely to locate the settings you’re looking for. If you have to ask for help, it can save a lot of confusion if you’re able to communicate in the same language as the people trying to help you.

Conversations Window:

This is communication central for your chat. Nothing gets said that gets past the Conversations window. If you miss something the first time, you can always scroll back up through the tabs in here—or the broken-off windows—to find it.

Here’s the basic Conversations window, using default settings in Firestorm mode: IMs in vertical tabs with “V1-style” chat headers.

Figure 1: Conversations window at default settings

Figure 1 settings:

Preferences* → Chat → General, “Show IMs in:” … “Tabs”

Preferences → Chat → General, “Chat Tab Mode Orientation” … “Vertical”

Preferences → Chat → General, “Use V1 style chat headers” (checked)

If you prefer your tabs across the bottom of the window, that’s easy enough to do.

Figure 2: Conversations window with horizontal IM tabs

Figure 2 settings:

Preferences → Chat → General, “Show IMs in:” … “Tabs”

Preferences → Chat → General, “Chat Tab Mode Orientation” … “Horizontal”

Preferences → Chat → General, “Use V1 style chat headers” (checked)

The final window option is a little more unexpected for most. It’s a V2-style option to have your IMs open up as separate windows that do not dock into the Conversations window. Either they're open on your screen separately or they’re minimized in such a way as to make it necessary to click the little icons up top—called "chiclets"—to view them. If you look at this image closely, you'll see a tiny triangle between the IM window on the right and the chiclet associated with it. This indicates that the IM window is docked to the chiclet. When you're using IM windows in this style, they'll automatically minimize when they aren't active, unless you drag the window away from the chiclet to undock it.

Figure 3: Conversations, with IMs in separate windows

Figure 3 settings:

Preferences → Chat → General, “Show IMs in:” … “Separate Windows”

Preferences → Chat → General, “Use V1 style chat headers” (checked)

You can also alter the appearance of chat in the Conversations window. We’re going back to tabs (vertical ones) now, but this appearance can be used with horizontal tabs or with separate windows, as well. What you’re seeing here is the use of V2/3-style chat headers, as opposed to V1-style, which are used in all the other examples.

Figure 4: Conversations displaying V2/3-style chat headers

Figure 4 settings:

Preferences → Chat → General, “Show IMs in:” … “Tabs”

Preferences → Chat → General, “Chat Tab Mode Orientation” … “Vertical”

Preferences → Chat → General, “Use V1 style chat headers” (unchecked)

Preferences → Chat → General, “When using V2/3 style chat headers, show mini icons” (checked)

You have the option to view IMs in nearby chat. This will allow you to follow all the conversations going on in other tabs without tabbing into them. You will have to tab in to respond, of course. You might find this useful, or you might find that it produces too much chat in one place to easily follow.

Figure 5: Conversations with "Show IMs in nearby chat window" enabled

Figure 5 settings:

Preferences → Chat → Notifications, “Show IMs in nearby chat window” (checked)

Preferences → Chat → Notifications, “Fade IM text into the background of the chat transcript window” (checked and set to 0.50)

If you do that, you can either have all the IMs—whether from groups or individuals—display only the prefix “IM:” before them or you can have the group name show, in full or in part, at the beginning of the chat line. To change this setting, do as follows below the figure:

Figure 6: Group chat showing in the nearby chat tab of the Conversations window. The group name appears in the chat headers of the faded-out chat.

Figure 6 settings:

Preferences → Chat → Notifications, “Length of group name to be printed in chat transcript”

Setting to “0” will show only “IM:” at the beginning of the line;

Setting to “-1” will show the entire group name (shown in image);

Setting to a positive number will show that number of characters in the group name.

Chat Console:

This is the part that scrolls up the left-hand side of the screen with a non-windowed, semi-transparent (by default) background. Not everyone loves the console, but under normal circumstances, local chat is going to appear somewhere outside of the Conversations window when it isn’t open to the Nearby Chat tab, and console is a fairly customizable place to put it.

Figure 7: Chat console, also called "onscreen console" or just "console"

Figure 7 settings:

Preferences → Chat → Notifications, “Use console for chat popups instead of floating toasts (Viewer 1.x style)” (checked)

Preferences → Chat → Firestorm, “Use classic draw mode for console” (checked)

Preferences → Chat → Firestorm, “Use full screen width for console” (unchecked)

You can view either local chat alone in the console or local and IMs interspersed. Above, there is only local chat. If you’re viewing IMs in the chat, as well, it will show up as below:

Figure 8: Chat console, with "Show IMs in chat console" enabled and both local chat and IMs showing

Figure 8 settings:

Preferences → Chat → Notifications, "Enable incoming chat popups" ... "IM Chats" (checked)

Preferences → Chat → Notifications, “Use console for chat popups instead of floating toasts (Viewer 1.x style)” (checked)

Preferences → Chat → Notifications, “Show IMs in chat console” (checked)

Preferences → Chat → Firestorm, “Use classic draw mode for console” (checked)

Preferences → Chat → Firestorm, “Use full screen width for console” (unchecked)

If you choose to include group chats in chat console (Preferences → Chat → Notifications, “Show group chat in chat console”), as well, then the same setting that adds the group name to the beginning of each line of text in the Conversations window will carry over here, as well. See Figure 6 for that and for the settings explanation that follows. Although you can display group chat in both or only one of the two places (Conversations or console), the format for both is determined by the same setting.

There are a couple of additional settings that affect the appearance of the chat console. They’re pretty easy to distinguish from one another, so I’ll illustrate them both in one picture. One is “classic draw mode,” which displays all of the console text against a single background, as shown in Figures 7 and 8. Below you’ll see this turned off, which displays each line of console text against a separate background.

The other setting is “full screen width.” Don’t confuse the phrase “full screen” here with using “fullscreen mode” in Graphics; they are unrelated. “Full screen width” here simply means the console extends all the way across your screen, however wide your screen is, as shown below. Disabling it will cause the console to extend only about one-third of the way across the screen, as is the case in Figures 7 and 8.

Figure 9: Console with "classic draw mode" unchecked and "full screen width" checked.

Figure 9 settings:

Preferences → Chat → Notifications, “Use console for chat popups instead of floating toasts (Viewer 1.x style)” (checked)

Preferences → Chat → Firestorm, “Use classic draw mode for console” (unchecked)

Preferences → Chat → Firestorm, “Use full screen width for console” (checked)

Chat Toasts:

Because of the default settings in the most commonly used login modes (Firestorm and Phoenix), it’s possible you’ve never seen a chat toast. Local chat toasts show up in the same location as chat console, while IM and group chat toasts appear in whichever corner of the screen your chiclets are in. Notice how these are in the same location as chat console but look significantly different. If you hover your cursor over them, an "x" will appear in the corner that allows you to click them closed if you want them to go away before they fade.

Figure 10: Local chat toasts

Figure 10 settings:

Preferences → Chat → Notifications, “Use console for chat popups instead of floating toasts (Viewer 1.x style)” (unchecked)

Group and IM toasts are different from any other chat display in that they show up in the upper right or lower right corner of the screen, depending on where your chiclets and group chat are displayed (Preferences → User Interface → General, "Group Notices and chiclets in Top Right"; if this is unchecked, they will appear in the lower right), and if they are in the upper right corner, they will appear in reverse order. Take a look at the time stamps in Figure 11 to see what I mean: the bottom toast is the one that came in first, and so forth—the toasts push each other downward as new ones come in.

Figure 11: IMs in toasts, upper right corner of screen

Figure 11 settings:

Preferences → Chat → Notifications, "Enable incoming chat popups" ... "IM Chats" (checked)

Preferences → Chat → Notifications, “Use console for chat popups instead of floating toasts (Viewer 1.x style)” (unchecked)

Preferences → User Interface → General, "Group Notices and chiclets in Top Right" (checked)

Preferences → User Interface → General, "Hide group and IM chat chiclets" (unchecked)

Since the IM toasts have led us to the chiclets, let's look at a couple of other options. We'll put the chiclets (and therefore the IM toasts) at the bottom of the screen and hide the IM and group chat chiclets. Note that although you can hide the chiclets that represent specific conversations, you cannot hide the chat bubble ("Conversations") and envelope ("Notifications") icons. You can of course close out all of the notifications to make the envelope icon go away, and if you have not yet received or sent an IM during the login session, the chat bubble won't be there yet, but those are not the same as hiding icons that are there and functioning.

Figure 12: IMs in toasts, lower right corner of screen

Figure 12 settings:

Preferences → Chat → Notifications, "Enable incoming chat popups" ... "IM Chats" (checked)

Preferences → Chat → Notifications, “Use console for chat popups instead of floating toasts (Viewer 1.x style)” (unchecked)

Preferences → User Interface → General, "Group Notices and chiclets in Top Right" (unchecked)

Preferences → User Interface → General, "Hide group and IM chat chiclets" (checked)

The settings for customizing the appearance of toasts are located in Preferences → User Interface → Toasts, but I'll let you experiment with those and figure out what works best for you. They are not all about chat toasts, though; the word "toast" refers to any popups in the viewer that appear in a corner of the screen and then fade after a time if you don't interact with them in some way that makes them do otherwise. So if you make changes there, expect them to apply as well to other toasts, such as group notices.

Additional Settings:

The above is meant to be an introduction to the major UI options with regard to chat appearance. There are many, many other options in the viewer, though, that affect chat in some way, some of which show up in the images in this post. They're all covered in brief on the Chat Tab page of our wiki, or you should come to our classes; the class called "Preferences 1" covers all of the chat options.

Finally, here are a few that affect the appearance of the images above:

Chat color: Preferences → Colors → Chat Color. I use green for "My text" and white for "Others"

Viewer skin: Preferences → Skins. I use Firestorm skin, CtrlAltStudio scheme here.

Toolbar buttons: Avatar → Toolbar buttons. As you can see from the pictures, I keep my toolbar very empty, but you can do a whole lot. We have a wiki page that explains more.

Channel selector: Preferences → Chat → Firestorm, "Show channel selection in chat bar." This adds a number box to the right of the chat bar in Conversations to allow you to change the channel on which scripts are listening. If you use this to change the channel, don't forget to change it back to 0 when you're done or else your local chat will not show up.

If you have additional questions about the settings, check out the Firestorm wiki for answers or come to our classes. There are additional ways of getting help listed on our getting help page.

* To open the Preferences window, hit Ctrl-P or go to Avatar menu → Preferences.

I Was Floored: Frequently Asked Support Question

Frequently Asked Support Question: Editing Shape Shoves Your Avatar Into the Floor

This problem appeared along with the new "Hover" parameter in the Edit Shape window. It's a variable issue, affecting some people all the time, others not at all, and the good majority occasionally.

What the Problem Looks Like:

This was me, the one and only time the bug has hit me.
I'm the fuzzy gerbil-sized clump of hair in the middle.

You're doing your regular thing—something to do with appearance, generally—and the next thing you know, your avatar has plunged into the floor, up to or over its head.

Most cases will have happened when you closed the window after editing your shape. Some folks have narrowed it down for themselves to editing certain shape parameters, such as Body Fat. But in other, more dramatic cases, people end up in the floor while engaging in some more common appearance-related task, such as attaching or removing attachments. All attachments, all the time. Serious nightmare for them.

As you can tell, this is an inconsistent bug. Although a few people are hit extra hard, many others have been editing their shapes with nary a hint of their avatars drilling for oil and are saying, "Huh? I've never heard of this. How common can it be?" As for me, it's happened exactly once—never before and never since. When a bug is not consistent, it's hard to test. Just like when you take your car to the mechanic and that sporadic noise suddenly refuses to happen, it similarly seems like you can never make a bug like this reproduce itself when you most want it to.

Why it Happens:

We know it's related to the existence of the Hover function but not to its use. Beyond that, we're not sure. But the Lindens seem to know more (based on the fact that they've been working on it), and since the issue came from Linden code, that's what matters.

"But I didn't even touch Hover!" you might be thinking. That's actually irrelevant. The only two factors that contribute to the bug are that 1) you are wearing a modifiable shape, and 2) you did something—anything—to alter your appearance.

Before the pitchforks about this new (and possibly, for some, seemingly unnecessary) shape parameter come out, let's just toss out a reminder that Hover exists because server-side appearance was to render the old Height Offset unusable. Height Offset, meanwhile, was strictly a Third Party Viewer feature. One Linden who has proven himself generous with his time and energy took it upon himself to replace that doomed feature with the Hover option (without it, there would be nothing at all to adjust your distance relative to the ground), and although it has some wrinkles to iron out, I would bet it's been more helpful than it's been a problem.

The bug can strike even if you
don't touch Hover, but this is
where it is in your Appearance
floater.

How to Fix It:

Linden Lab has been working on a fix, and they might have hit on one, but it's untested as of yet, and the code is only available in the super-experimental "sunshine external" branch of their own repository. It has not yet made it into one of their release candidate versions, much less a release, much less our release. But at least we know there has been active work done on it, and the fix is in the pipeline (albeit way up-pipe).

If you'd like to keep track of progress for Firestorm in particular, keep an eye on FIRE-9951. When the fix gets merged into Firestorm, tested, and confirmed to be working, it will all be reflected there.

In the meantime, there is a workaround, but it's really only good for people who are affected by the bug at times other than changing shape because it involves making your shape no mod. So if you're one of those unfortunate souls who can't so much as change their shoes without getting shoved underground like a Whack-a-Mole, then this will at least give you some relief:

• Make a copy of your shape no mod by sending it to an alt account, where you can change it a teensy bit and save it as no mod for next owner. Then send it back. If you don't have any alts, you can send it to a friend to do the same thing.
• Use that newly no mod copy as your usual one to avoid the bug.
• This does mean that if you want to change the shape, you'll need to rewear the modifiable one on the alt account, edit it, hope you don't get sucked into the ground while you do, and then re-send the non-modifiable copy for wearing.

Like I said, this workaround is only useful for those who have the worst form of the bug. For those of us who only experience the issue when editing shape, it's not going to help much. There are no known workarounds for preventing the issue while editing shape.

As for what to do when you find yourself under the floor and all you want to do is get out, the following have worked for someone at some point; none is guaranteed, but any could do the trick:

• Simply re-enter appearance mode.
• Re-enter appearance mode and toggle the Hover setting, changing it in any direction and then returning it to your preferred value.
• Relog.

So it's an annoying issue, but the fix is well underway, and there are some workarounds you can try until then.

For help on other issues, please see the troubleshooting section of our wiki, join our inworld group for assistance, or file a ticket on our JIRA. Support questions will not be responded to in the Comments section of this blog.

The Three Hours That Can Change Your Second Life

Audio version of this blog post, for multitaskers, the visually impaired, and anyone else who feels like listening to nine minutes of me chattering: http://vocaroo.com/i/s0ck5thsFfWF

We've been holding classes for Firestorm users for over two years now, attracting a range of people, from folks brand new to Firestorm—or to Second Life—to long-timers interested in filling in the gaps in their knowledge. 

Some come only once to learn about one specific Firestorm feature, like the client-side AO or the contact sets. Others attend our full slate of fifteen classes, over and over, until they're sure they've absorbed everything they can. And then they come back again the next time the viewer is updated and there are new things to hear about.

There's no specific order in which the classes need to be taken. They're held with starting times ranging anywhere from 8am to 7pm SL time, seven days a week, including two text-only class slots. Most of them last about an hour or less, with an open-ended Q&A period after every one.

But if the class schedule overwhelms you, and you're still not sure where to start, or you know you don't have the time to devote to fifteen entire one-hour classes, then let me narrow it down for you.

There are three classes that I would recommend to every Firestorm user, one of which is fully applicable to other viewers, as well. I'd call these the Power Trio, the ones that help you learn about your viewer's everyday performance, as well as what you can do to fix problems or to get them fixed when things go wrong. At the risk of sounding like a motivational speaker from an infomercial or the "bestselling author" of Smile Your Way to Bliss, the hour you spend in each of these three classes can make you a happier Second Life resident. 

Prevention is the Best Cure: Preferences Set 2

We have four classes on the preferences because there are so darn many of them. This one sort of blends in with the other three in the schedule because of its generic name, but it's arguably the most valuable class you could attend in Second Life.

A class being taught at Wailele Moku,
one of our three usual class locations.

That's because the preferences it covers are those most critical to your performance in and overall experience with SL: the Graphics and Network & Cache tabs. They are also the settings that are most underestimated, overestimated, or wildly misunderstood. 

Preferences 2 covers each one to explain its possible effect on your inworld experience and how to determine the right settings for yourself (hint: it's not one size fits all). As is true with many of our classes, the core material for it is also available on our wiki. But rather than just summarizing what they do, the class attempts to reframe your understanding of how these preferences interact with one another and how you can respond intelligently to changes you notice in how your viewer seems to behave.

Home Remedies: Basic Troubleshooting

Although our support staff is ready and willing to help you out with suggestions for a variety of problems, there's actually quite a bit you can do on your own before you come to us, either to fix the problem yourself or at least to narrow down the possibilities.

In most cases, these are the same steps we'd be putting you through when we first start working with you anyway. The Basic Troubleshooting class goes over what you can try and where to look for more information, both in the viewer and on your computer.

While we would never call the viewer bug-free (no viewer can make such a claim), the simple truth is that ordinary users have a lot more control over the majority of issues than they may realize. Although it's easy to mutter, "Stupid Firestorm" (or your favorite curse word in place of "stupid"), whenever you have a problem, it's often not accurate or productive. Many times, prematurely blaming the viewer means you've actively chosen to look in the wrong place for a fix. If you assume you have no control over the issue, your prophecy will be self-fulfilled.

This class is only the tip of the iceberg in getting a feel for the factors that might be playing a role in your issues, not just on Firestorm but on any viewer at all. Or just come to hear about why the phrase "Clear cache and relog" seldom escapes our lips.

Graphics are the most important yet misunderstood
settings. Learn about them in our Preferences 2 class.

By Prescription Only: Reporting Bugs, Requesting Features (RBRF)

In some ways, this one is a companion class to the troubleshooting one. Because sometimes problems are viewer bugs.

But most bugs affect people differently; any bug that affects everyone—or everyone on an entire operating system—is easy enough to spot in QA (quality assurance, our pre-release beta testing phase). It's the bugs that affect specific types of users (by combination of computer components, for instance, or by inworld habits and activities) that fall through the cracks. 

This means that any viewer bug that didn't affect our beta testers needs to be reported to the JIRA by someone experiencing it, or it simply will not get fixed.

If you want to be sure that happens, it's useful to know how to do it yourself and not hope that by some random chance someone else will jump in and take responsibility for it.

I'm aware of a lot of reasons people don't want to use the JIRA, and I've spent a lot of time in this blog addressing them and giving my rebuttals. The Reporting Bugs, Requesting Features (RBRF) class is designed to assist those hindered by many of these reasons: the impression that it "doesn't work," a lack of familiarity with the process, intimidation with the interface, and so on.

This is the third of our Power Trio of classes designed to make your SL much more awesome. Having reported a few bugs in my time, I can tell you it feels super when something you filed ages ago finally gets fixed—and knowing that the fix might never have happened if you hadn't simply filled out that JIRA form.

We have a team of volunteer teachers who rotate through
fifteen classes every 9–10 days. Schedule updated regularly.

Now… I said there were three Power Classes, but I'm going to add a cherry on top of our triple-scoop treat, with an extra half-class.

Lag

This is a mini-class, usually paired with a second mini-class on customizing your quick preferences. And the name says it all. It teaches you about lag.

In this one, you learn how to differentiate among client, server, and network lag and what to do about each. There might be a few surprises in store, such as how poor building practices contribute to sim lag (the key word here is "collisions") and some of the myths and facts about script lag (for example, that script lag is unrelated to the scripted object's proximity or visibility to you).

Unsurprisingly, this is one of our more popular classes. It's our most-requested class for private or semi-private presentations (yup, we do that—just send an IM or notecard to Ed and/or me for scheduling at your home region).

So to sum up:

• We've got Prefs 2 to help you wade through the muck of information out there about what your most important settings should be to keep things running as well as they can.
• We've got Basic Troubleshooting to help you pin down the causes and possibly the fixes for the majority of issues you might fall victim to.
• And we've got RBRF to help you properly report the problems that turn out to be rooted in the viewer after all.
• Plus a bonus mini-class on Lag to… well, that one's probably obvious.

We're looking forward to seeing you at one or some or maybe all the classes on the schedule!

Is Firestorm the Right Viewer For You?

This post was written as a companion piece to Ed Merryman's rant on the same topic. Please visit his blog for his thoughts, as well.

Audio version of this blog post is available here: http://vocaroo.com/i/s0qFhuop4kks

Is Firestorm the right viewer for you?

Has it ever occurred to you to ask yourself that? Most people I've known in Second Life fall into one of two or three camps when it comes to how they use viewers. Let's call them "hoppers" and "squatters."

The hoppers bounce from one viewer to another because every time something goes wrong while they're using one, they conclude that it's a problem with the viewer itself and hop along to a different one. V3, Catznip, Exodus, Singularity… each one ends up with some sorry problem that sends them hopping continuously on — and often, but not always, back to Firestorm. They don't ask anyone for help aside from their own friends. They don't report their issues on any development team's JIRA. They just hop. Hoppity hop.

Squatters, meanwhile, pick one viewer and stick with it. Some of them wait as long as they possibly can even to update the version of their chosen viewer. And as long as that viewer is working for them, hey — nothing wrong with that. Where the trouble comes in is when a squatter has an issue with it.

Maybe the squatter comes to us for help on a support issue and, for the purposes of testing whether the problem they're experiencing is specific to Firestorm or something we picked up from Linden code, we ask them to try V3. They refuse. "I'm never going to use anything but Firestorm," they say. Um, well, we appreciate your loyalty, but really, this is just a test. You can come right back and use Firestorm afterward. "No, I'm not using V3." Erm… ok then, how about one of the other fine V3-based viewers on the TPV (Third Party Viewer) list? "No. I'm having the problem on Firestorm, and you should be able to fix it on Firestorm." Okaaaay.

The French beret look will make more sense later.

Or maybe the squatter isn't actually experiencing a support problem. Maybe they've just found something about the viewer to complain about. This kind is usually a transplanted or migrant squatter. Someone who was previously squatting elsewhere but had to move on. If this makes you think of Phoenix Viewer users who stayed on two years past the viewer's prime, then give yourself a gold star. We've gotten a lot of them recently because server-side appearance (SSA) is pushing them off their land. We hear them in the support group: "So we have to go to Firestorm now?" and although we answer over and over — No, you don't have to go to Firestorm, but you can't stay here — many of them nonetheless deathmarch their way to Firestorm with their heels dragging in the dirt.

And inevitably they will be dissatisfied. This is not necessarily a problem. Dissatisfied users who submit feature requests are entirely welcome in their dissatisfaction. And I can't neglect to mention those users who make an effort to adapt to Firestorm even in their frustration and find it's not so bad as they initially thought. Rock on, o determined ones! But for some, dissatisfaction is not an impetus for productive suggestion-making but a perceived entitlement to complain. I want to focus on one particular theme of complaints:

• "Why is this such a complicated viewer? There's so much crap in here I don't need."
• "Classes? Really? I need to take classes to use this sucky viewer?"
• "I've been having all kinds of problems since I was forced to move onto Firestorm." What kind of problems? "I can't find anything!"

And so for different and separate reasons, I would like to ask members of each of these three camps — hoppers as well as both the settled and migrant types of squatters — is Firestorm the right viewer for you?

Hoppers, or: Being Arsed

Just to make sure it's clear up front: The fact that hoppers try different viewers is not a problem. That's a good thing. But hoppers do the right thing for the wrong reason. Firestorm and each of the other viewers available serve different userbases with different priorities… and they're all supposed to work decently well. Speaking for myself, I am never upset when someone chooses to use a different viewer because they prefer its feature set or interface or because it gives them smoother performance. That's a matter of determining which viewer is "right" for you in just the right way.

Hoppers bounce from one viewer to the next for any
little problem: the right thing for the wrong reason.

But it is irritating when a hopper says, "I love Firestorm most, but I started having this problem, so I switched." And exactly which of our 70 support team members* did you contact for help with that problem? Which of our wiki pages did you look at? Where is the JIRA you filed? "Oh, I just asked a friend and they said they heard from another friend that it happened to someone else too. I'll just see if it's fixed in the next version." Sigh. Can someone lend me a wall? My head won't damage it too much.

Oh, and I wish I could exaggerate how often that "problem" turns out to be a setting they assumed didn't exist and thus didn't toggle. Everything from WASD keys to horizontal IM tabs. They couldn't be arsed to look into it and thus went viewer-hopping for a few months when they could have been on one that was Right For Them. Be arsed, people. Please be arsed.

Granted, viewers do vary in terms of the help resources available: Other TPVs don't have such extensive support as Firestorm, and full Linden support is only available to premium account holders. But most have inworld groups where you can get peer support. And if, after you're sick of the pogo stick method, you've decided that Firestorm is right for you, we're happy to help you with anything keeping it from working great. We're sure your friends are very nice people, but the majority of them won't compare, in terms of helping, with those who investigate problems with the viewer and in SL every day.

Settled Squatters, or: Fans and Fanatics

These are the ones who cry, "I have claimed this viewer and I shall not be moved!" There's nothing wrong with that most of the time, but the issue arises when it interferes with receiving support for a problem, i.e., when this outlook carries over into refusing to test on other viewers.

You didn't bind yourself to Firestorm in a commitment
ceremony (I hope).

C'mon now. Seriously. How many people on the Firestorm team do you think are that stubborn? Nearly all of us use Firestorm as our primary viewer, sure, but a few developers code for more than one viewer project, many of us have a text-based client or mobile app installed for non-graphical or on-the-go purposes, and most of us have tested viewer behavior on V3 occasionally as a benchmark for diagnosing Firestorm problems. It is doubtful that more than a handful of Firestorm Team members are viewer-monogamous.

You didn't bind yourself to Firestorm in a commitment ceremony (I hope). V3 won't give you cooties. Although viewer use can sometimes feel like religion, please don't lose sight of the fact that all we're talking about here is software.

In this context, the question "Is Firestorm the right viewer for you?" has an obvious answer: yes. The squatter has decided Firestorm is right for them, and I wouldn't try to change that. But if you're having trouble with your favorite viewer, it would be rational to do what you need to do to help support and/or developers figure out the issue. Doing so quite often means testing against the viewer that Firestorm is based on and from which it gets most of its code.

Or to put it another way, fan loyalty to our viewer is commendable until it starts to become unhelpful. At that point, it's merely fanaticism.

Migrant Squatters, or: In France, They Speak French

It is for migrant squatters that the question "Is Firestorm the right viewer for you?" is most important. They prefer to settle into one viewer for the long haul like settled squatters do, but for one reason or another they find themselves uprooted, and their natural impulse is to find a new viewer to cleave to in the same way.

We've gotten a lot of Phoenix squatters recently
because SSA is pushing them off their land.

It is not surprising that a lot of Phoenix users trudged their way over to Firestorm for this purpose. They're familiar with the project and possibly with the support team, and more than likely they know a ton of people already using it. And as I said above, many are happy with the migration. Others are not, but their quibbles are fixable and they take the steps necessary to communicate to our team what they are. Both of those early experiences with Firestorm are awesome.

However, there's a final camp of migrant squatters who, first, believe they're being "forced" to use Firestorm (yes, we hear that word at least once a week) and, second, complain not about specific bugs or desired functionality but about aspects of the viewer that are inherent to it. This is kind of like going to France and then complaining that everyone there speaks French.

Specifically, a surprising number of people are annoyed — sometimes seemingly offended — that Firestorm has approximately a gazillion preferences, menu options, different ways to find the same thing, interface choices, font choices, colorability choices, buttons, windows, gadgets and gizmos aplenty, and even hippos and cookies. Understandably, it leaves them feeling overwhelmed.

The inclusion of all these options is not an incidental characteristic of this viewer, however; it is the point. Providing users with options so that they can make their viewer do what they want it to do is the purpose of Firestorm's existence. Of course, this creates some drawbacks as well as benefits in the viewer:

• It means that it takes a bit of searching and experimenting to locate what you're looking for sometimes.
• It means that there will be a number of options that simply sit there because they don't interest you. This will be true for everyone, as no one uses everything in the viewer, but you can be sure that someone out there is using the very same options you're ignoring.
• It means, alas, that the preferences in particular are a bit of a jumble. Every so often, the developers attempt to shift them into a more logical order, but that task has its drawbacks, as well, when a setting is suddenly no longer where you're used to finding it.

We provide resources for learning about those settings and getting more familiar with them, both written and in person. The documentation sections of our wiki are like a big owner's manual. And why shouldn't software come with an owner's manual? Classes generally work off of the same material as the wiki but offer a more personal and interactive context. So do you need to go to classes to use the viewer? Of course not, but we have a lot of regular students who say it sure does help. There's a lot of functionality in Firestorm; taking the time to learn about it will help you get the most out of the viewer.

Firestorm classes generally work off of the same
material as the wiki but offer a more personal and
interactive context.

If the presence of so many options is really a dealbreaker for you, if it is that onerous for you to simply (or not-so-simply) find what you need and ignore the rest, then I would say unequivocally that Firestorm is not the right viewer for you. Sorry. We will not stop speaking French (metaphorically, that is — I don't actually speak French).

Niche-Picking

I'm going to conclude this post by addressing the flawed understanding of the Firestorm Project that underlies the following two questions that we often get asked:

• Will there ever be a Firestorm-Lite?
• Will there ever be a mobile Firestorm app?

The problem with both of these questions is that they are oxymorons. What the questions actually mean is: Would the Firestorm team ever develop one of these? The answer in both cases is "Probably not," but key to this discussion is that in the unlikely event that the team did develop such a product, it would not be Firestorm Viewer. It would be a different client produced by the same team, like Phoenix and Firestorm are different clients produced by the same team.

So why is this distinction so important? Isn't it just semantics? Not really, because the questions stem from the assumption that our team can do stuff better than other teams. Aw shucks, that's too kind of you. Stop. No, really, stop. You're flattering us.

Our developers are indeed pretty darn awesome. They're great at achieving the goals of the Phoenix Firestorm Project: to provide feature-rich alternatives to the official viewer compatible with Linux, Mac OSX, and Windows. That's what the team does. A different goal would be someone else's goal. Other teams produce more scaled-down viewers, and other teams produce mobile apps. The belief that the Firestorm team ought to fill those needs when other people are doing a fine job of it themselves is based on a misunderstanding of the team itself. It is, once again, expecting to go to France and speak, like, Russian or something. Which some French people undoubtedly do, but you'll be better able to practice it in, oh, let's say, Russia.

It's also an over-reliance on the Firestorm "brand" name. It is, moreover, a failure to recognize Firestorm as cornering a niche market the way that all other viewers do — it just happens to be an uncommonly large niche, which makes it hard to see as a niche. But "Feature-rich alternative compatible with Lin, Win, and OSX?" Yeah, that's a niche.

To tie it more firmly into this post's main point, the questions about "Firestorm-Lite" and "Firestorm Mobile" stem from a belief that Firestorm is so emphatically the right viewer for the curious questioners that instead of seeking out other viewers/apps that actually exist, people start inventing new Firestorms that probably never will.

You're looking for "Firestorm-Lite"? Use V3. That's exactly what you'd have if you took Firestorm and removed all its special features. V3 is not just for newbies and Linden Lab fankids. It's a perfectly adequate baseline viewer that simply doesn't possess all the bells and whistles that TPVs include to enhance functionality. Linden Lab's niche is the streamlined, minimalistic viewer.

Oh, but by "Firestorm-Lite" you don't actually mean bare bones, you mean a viewer with exactly the features you use, and no others? Um, well, you can see if the other TPVs coincide better with what you're looking for, but to be honest, no one gets to have such a narrowly customized viewer except for the developers who create their own. So… get cracking.

You're looking for "Firestorm Mobile"? You do realize that a mobile app would bear nothing in common with the one you use on your computer, right? Although things could easily change in the next five or ten or twenty years, you cannot at present jam the equivalent of Second Life's minimum system requirements for running a "real" viewer into a phone. You have two options here. 

• You can take a gander at the mobile apps in the second half of the TPV directory (Lumiya for Android comes particularly recommended; iPhone/iPad users have Pocket Metaverse). This will let you access SL through apps that are meant for the purpose.
• Or you can use your mobile device to connect remotely (using TeamViewer, LogMeIn, or another mobile app) to your own computer at home. This second option will let you view Firestorm on your mobile device while it is running on — and the heavy lifting is handled by — your computer. Of course, you might be missing some functionality, but this is the closest you're gonna get to using Firestorm itself on a phone or tablet in the forseeable future.
• Oh, here's a third option: You can enjoy rewatching our April Fool's Day 2013 video.

So, finally, is Firestorm the right viewer for you? It would be pretty nifty if it is, but if it's not, you should not feel obligated to stick with it. Every blessing is simultaneously a curse when it comes to flexibility and options. Thank goodness the range of viewers available is itself a source of options.

* This number includes support team members across all nine supported languages, though only the English and German groups are fully listed on the linked page.