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.

Why We Can't Have Nice Things

When the Firestorm team released its first Server-Side Appearance-compatible version of the viewer in April, one change particularly dismayed many users: the removal of the Height Offset feature that had conveniently been located in the Quick Preferences panel. Nyx Linden put in his personal (unpaid) time to create an alternative system to take its place, specifically to assuage the distressed Firestorm users who had come to rely on this functionality. But the replacement -- a shape parameter -- has shortcomings that have nonetheless disappointed the feature's users.

No one likes it when their toys -- or in this case tools -- are taken away from them after they've had the chance to play with them, get used to them, or even rely on them for critical functions. But the Height Offset example is not the first time this has happened, nor will it be the last.

Second Life residents have a history of creating things that go beyond what Linden Lab expected or intended them to create. This shows up most memorably with viewer features, but examples of inworld content that stretch the confines of Lab-given resources come up, as well. Here are some that come to mind:

• Invisiprims: The inworld objects designed to hide body parts but not prim objects were popular shoe components until alpha layers came around. Plenty are still in use because not everyone is in a rush to throw their old, no-mod invisiprim shoes away, but the growing popularity of shadows and the introduction of Materials are their nemeses, since enabling Advanced Lighting Model (formerly known as Lighting and Shadows) conflicts with them.

  

  Old-style invisiprims are incompatible with Advanced
  Lighting Model, which is off in the image on the left but
  enabled in the image on the right.

• Phantom mode: Phantom mode was a TPV invention used to prevent others from moving your avatar if they run into you. It was incompatible with Pathfinding (released in summer 2012) and was removed from viewer updates thereafter. These days, sitting is the fastest workaround, and you can load stands into your AO as ground sits if you want to appear to be standing.
• Viewer tags: The ability to see what viewer others were using in their avatar tags and to have your own displayed was disabled by Linden Lab as a matter of policy last year, but they would have been incompatible with Server-Side Appearance this year anyway, since they worked by piggybacking on the "old" avatar baking process. If they hadn't been shut off already, they'd fall into this category now. Viewer tags still work on other grids, but if those grids move to SSA, then you can expect this feature to be a thing of the past there, too.
• Temporary uploads: They still exist… for now. This is the next TPV feature to sit on death row, as it will be broken when Server-Side Appearance goes into effect in a couple of weeks. Instead of temp uploads, you'll want to use the Local Texture Browser. It actually does more than the old method of temp uploads did, but you won't be able to share the textures with others inworld. For that, there are plenty of temporary photo hosting websites that should work just fine.

  

  Local Texture Browser allows you to see what a
  texture on your computer will look like applied to an
  object inworld without paying to upload the texture.

These extensions of Second Life's inherent capacities, these Nice Things, fit some definitions of "hacking." Not the breaking-into-internet-security-and-causing-grief definition of hacking but the kind that simply refers to "exploring the details of programmable systems and stretching their capabilities." In the SL context, this practice is so commonplace that most who engage in it probably have no idea that they could be considered hackers until the foundation their hack is based on gets swept out from under them.

The fact that Second Life draws such creativity and innovation out of its users is one of the most fantastic things about our virtual world. It encourages the best kind of hacking, "white hat" hacking, the kind that enhances experiences and bends the system to greater potential.

But when innovation takes place outside of the institution that provided the tools for it (in this case, by users such as content creators and TPV developers, instead of by Linden Lab), there is both a positive side and a negative:

• On the positive side, the ideas go beyond the ordinary and are based on how residents use the world. They stretch expectations and intended uses of the system beyond what its programmers could have anticipated.
• On the negative side, they're always potentially temporary. They have no insurance. If LL didn't make them or intend them to be made, then they're unsupported, and there are no guarantees that the loopholes that were found to create them will always be open.

This means that when a Nice Thing goes away, it's not usually because the Powers That Be want it gone. More often, the innovations simply don't exist in the Powers' frame of consciousness at all. When they go, it's because the Powers have other plans that simply render your Nice Thing obsolete.

It also means that from a user's point of view, the idea of a "Nice Thing" can be understood as a "nice thing to have," not an entitlement. It may come, it may go, it may come back again through different means. Adaptability and flexibility become valuable traits for those of us who have no control over Linden Lab's priorities.

This tends to be true for lots of things in Second Life. And real life. Take it from the Buddhists, who base their Second Noble Truth on the belief that the origin of suffering is attachment.

The only aspect of the Height Offset example that is unique is actually the fact that a Linden made an effort to soften the blow to TPV users. Some appreciated this and adapted; others reacted as though this feature were something they were entitled to and as if any reduction in functionality would be a major setback to their virtual lives. How we react when we lose one of our Nice Things is our choice, though. No one else -- Linden dev, Firestorm dev, or content creator -- is responsible for that.

So why can't we have nice things? Because the brilliant, creative minds in Second Life exceed our ability to let go of what they create.

I believe it is safe to assume and hope that users will continue creating things that stretch beyond what is intended of the system they're creating in. And while they do, by all means take advantage of them. That's what they're there for. But you'll enjoy SL most in the long run by accepting things both as they come and as they go. Some Nice Things are unsupported and, thus, uninsured. If we lose them someday, it is your decision whether you cling and complain or whether you say, "Well, that was a nice thing to have while it lasted."

Frequently Asked Support Questions of May 17

The topics we'll be focusing on this week are:

• Mesh failing to render and the truth about that debug you might be using
• Notifications purging between logins
• System layers removing themselves when saved

Mesh Failing to Render and the Truth About That Debug You Might be Using

Mesh problems are not new, nor are they likely to ever fully go away, I fear. However, the complaints have increased with the current release of Firestorm, most likely due to the shift toward the greater reliance on HTTP-based code necessary for Server-Side Appearance (SSA).

To troubleshoot mesh rendering problems, start at our Seeing Worn Mesh wiki page. It lists the most common issues with rendering mesh and their fixes. If those don't help, see also the HTTP Fetching Issues page for the newer suggestions and some important information about how these issues will continue to affect you after SSA goes live on the grid.

Normally, mesh should be visible at all graphics levels
on Firestorm, but these are some settings to look at if
it is glitching. See our wiki page for more info.

Light at the end of the mesh tunnel. For those who don't find any joy with the troubleshooting, we at least have good news. One of our developers, Ansariel Hiller, just pushed a change yesterday that is expected to improve mesh loading in a future release by forcing the viewer to spend more time attempting to transfer mesh before it gives up and starts over.

In other words, right now, if I teleport to you wearing a mesh dress and your viewer tries to load it, it will spend 30 seconds trying before it gives up. Then if the dress is not loaded, your viewer will try for another 30 seconds… but the problem is, it starts at the beginning of the loading process to do that. It's like being challenged to fill a jar of jelly beans without spilling in exactly 30 seconds, and if you can't do it, the whole jar gets dumped and you have to start over. Since we're talking about mesh and not jelly beans, you may never see the mesh even partially rendered before it's forced to start (and never finish) loading again.

Ansariel's new change tells the viewer to try for a longer default period of time (60 seconds) before resetting the attempt and starting from scratch. In addition, for those with slower connections, it can be changed to be longer still. So far this has been working nicely in our internal testing. Here's hoping it continues to do so as we get more people on it to test on more varied systems. If so, it will be included in the next release.

Stuff you probably didn't know about MeshMaxConcurrentRequests. The JIRA associated with this new change, FIRE-8842, contains some additional mesh info in the comments. One bit that may be of interest to many has to do with a debug setting called "MeshMaxConcurrentRequests."

About a year and a half ago, after mesh had been around a few months, someone discovered that if they increased the number in this debug, it would result in unrendered mesh magically popping into view for them. Others found it worked for them, too, and this suggestion spread like wildfire, erupting into a "Bigger is not only better but must be bigger all the time" perception, with notecards circulating among creators, bloggers, mentors, and so on, promoting the adjustment of this setting to higher and higher numbers… and never reducing it afterward.

Using it in that way has never been recommended by support. Not ever. Like most settings, this is one where one size does not fit all and where you should be suspicious of anyone who claims it does. And like most settings, it's one where bigger -- and especially leaving it bigger rather than only bumping it up temporarily -- is not actually better. It can, in fact, contribute to sim lag. Plus, depending on your connection, it may in fact do the opposite of what you're trying to achieve, choking your mesh load instead of improving it.

Ansariel explains, "The problem with high concurrency is: if you have a slow connection and at the same time the viewer tries to download several mesh assets that are quite big, they will not finish within the timeout, and the viewer tries again. If you have 32 requests that are in this state, no new mesh will load. Increasing the concurrency will indeed load mesh again, but the situation will get worse since you are now trying to squeeze even more data through the line. So actually it's better to use a smaller concurrency in that case so requests have a chance to finish within the timeout."

Or in other words: if your connection is not very good, you want to reduce the number in that debug setting, not increase it. Nicky, another of our developers, adds that, furthermore, "when you're on a crap connection and you choke your download like that, there's a high chance you choke your upload, too, e.g., lag out everything you send (like chat, movement)." If your settings are not appropriate for your system, you may be creating new problems for yourself.

Bigger isn't better for everyone and shouldn't be left big
after the problem is fixed. Reset to default once the
mesh is visible.

On lag. Even if you have a good internet connection and you find that increasing the MeshMax number does help, there is no need to leave it at the larger number; our recommendation is to drop it back down to default when you're not actively trying to fix a mesh loading problem. Using it to prevent problems that haven't happened yet -- and may not happen at all -- merely places unnecessary strain on the sim.

The "Requests" in the name of the debug refers to how much communication you're doing with the sim within a period of time. More requests means more communication that might not have to take place. More communication means more work you're forcing the sim to do.

If it's just you trying to view one piece of mesh, it may not be so bad. If there are 40 people on a region all trying to view each other's fabulous mesh fashions, however, you can be certain that some of that lag you feel is due to the number of unnecessarily high mesh requests. Of course, some of it is also due to the many other effects of there being 40 people on the region, but when one of those effects -- the MeshMax one -- is easy enough to reduce, it seems pretty silly not to, right?

So please, stop hiking up your MeshMax requests for longer than the moment it takes to fix your problem, and stop circulating those notecards, unless you're planning to provide a detailed explanation of who should use the info, how, and when.

Instead, if you're helping someone on Firestorm -- or even if you're not, as some of the info is not viewer-specific -- share our wiki page with them. We try to keep our own pages up to date with this type of information, since it can and will change as the technology and knowledge about it change. That notecard that's been sitting in your inventory since December 2011? Not so much.

Notifications Purging Between Logins

The notifications we're talking about here include any bits of information that get saved and listed in the button with the envelope icon in the upper right or lower right corner of your screen. These notifications can include group notices, region restart notices, and other things depending on your settings (transaction notifications may optionally be saved there, for instance).

The envelope shows how many notifications you have
open, up to a "99+" maximum.

If you have any notifications that you have not yet closed, then this icon will appear with a number in it, up to a maximum shown of "99+."

How these are supposed to work. When all is working properly, these notifications are supposed to remain in place until you delete them yourself, as long as the number of notifications remains at a moderate number (below 100 or so). If there are too many notifications for the viewer to load, it is supposed to purge the extras upon the next login to prevent any hangups from occurring -- but only the extras.

What happens when they don't work. With several of our prior releases, we saw a problem where excess notifications were not being properly purged, and users were experiencing immediate forced logouts when logging in. This issue could be fixed by finding and deleting the open notifications file on the user's computer or prevented by not letting those notifications build up that much in the first place (see "Firestorm Logs Out During Login" on our Crashing During Install or Startup wiki page).

With 4.4.0, we seem to have shifted to the opposite problem, where notifications are being purged completely (i.e., not just to the point where login can be achieved) and are being purged even when they have not built up to excess.

Reports. The bug report for this issue is FIRE-7035, crosslisted with CHUIBUG-136 on the Linden JIRA. As the existence of an open Linden bug report usually indicates, it is something we picked up from a merge of Linden code. Don't let the label fool you, though -- Firestorm doesn't have any actual CHUI (Communications Hub User Interface, a recent Linden overhaul of the viewer's interface and other bits) code yet. Although the Lindens have it filed under CHUI because future notification fixes are being handled by the CHUI team, the problem actually precedes the CHUI project and was originally reported last July, when it was happening but not all that often.

Possible workaround. This workaround seems to work for some people but not everyone. It's worth a try if you're affected by the problem:

Click the envelope icon to view the list of notifications
before you log out. This seems to prevent them from
purging, at least for some people.

• Before you log out, click the envelope icon to view the list of open notifications. You don't need to click on the notifications themselves -- just open the list. Some people find that after they do this, the notices remain in place for the next time they log in.

This doesn't always work for everyone, but it's at least something to try. Keep an eye on the JIRA progress to see how it's coming along in development.

System Layers Removing Themselves When Saved

This bug emerges when you're editing a system layer (tattoo, pants, gloves, etc.) and try to save it. You may find that immediately after saving, it somehow gets removed from your body. It will show in the Appearance floater as worn but not in your inventory. All you have to do is re-wear the item, but that can get annoying, especially if editing or creating clothing is a regular thing for you.

The bug arrived with us via the Server-Side Appearance (SSA) code from LL. Our bug report on it can be found at FIRE-9705, while the Lindens' equivalent bug report is SH-3889, not externally visible. We're hoping for a Linden fix for this one.

In the meantime, there are a couple of workarounds (non-guaranteed) to try:

Unchecking "Appearance" here allows you to edit
appearance without your avatar changing position.
However, leave it checked to reduce the likelihood of
this issue occurring.

• Go to Preferences > Move & View > View, and make sure that "Automatically pose avatar during…" "Appearance" is checked. The bug is more likely to emerge with this setting disabled.
• There are reports that choosing "Save As" after you've finished editing instead of "Save" may lessen the likelihood of the problem occuring, as well.

If the workarounds don't help, then keep an eye on FIRE-9705. After Linden Lab fixes it (or if our developers fix it independently), it will be reflected there and will be included in the following release.

Other Problems? Where to Get More Help

Comments aren't open for this post. It's not because I don't want to hear from you but because I can't guarantee a response to requests for support here, and I don't want to leave the impression that such a response is likely. If you need help that isn't provided here, then please use the following means:

• The wiki is a regularly updated resource with all known fixes to common problems.
• If you can't find what you need there, join our inworld group, open 24 hours with help from support team members when they're available and from your peers at all times.
• If your problems prevent you from logging in on any viewer, you can request support through the JIRA. Bug reports go to the JIRA, as well.

Frequently Asked Support Questions of May 8

This week's most frequently asked support questions:

• Prims invisible until you {insert favorite workaround here}
• Lag (that is, if it's a lot worse for you on FS 4.4.0 than FS 4.3.1)
• Difficulty Clicking Continue on Terms of Service

Prims Invisible Until You…

…do the Hokey Pokey and turn yourself around or something. More effective, though, is to:

• Enter wireframe (Ctrl-Shift-R, with the Develop menu open; if you don't, Ctrl-Alt-Q will open that) and then hit the same keys to switch back. 
• Move your camera in and then pull it out, or vice versa (not as reliable but may be faster for some). 
• Right-click where the objects are supposed to be, but that could take a while if there's a lot of stuff.

Toggling in and out of wireframe can display
prims. Ctrl-Shift-R. Develop menu must be open.
(Mac users can use Cmd [shown above] or Ctrl.)

Whatever your workaround of choice, you have undoubtedly noticed an increase in how often you need to use it. The problem is the one where there are objects or pieces of them missing after you teleport.

However: it's not a problem that coincided with Firestorm 4.4.0. It has, in fact, been under discussion since "The main channel [got] the interest list project that was previously on Magnum" in the Deploys of April 1. It affects Linden Lab's viewer and all viewers based on it, including Firestorm.

Even though it was triggered by a server rollout, it's nonetheless regarded as a "viewer problem." Think of it like Dr. Linden Lab changing all our meds at the same time without giving us the chance to prepare for it, and we're all having a weird, freaky reaction. The problem isn't the pill, it's the unprepared body. Since we're talking about viewers and not human bodies, though, we'll need a viewer update from LL in order to get our viewer in sync with the server as well.

Andrew Linden addressed the progress of just such a viewer update at a user group on Tuesday (the transcript should eventually be posted on their wiki). Once the Linden code becomes public and available, the Firestorm devs will be able to pull it in. If Firestorm ends up on the cusp of another release before they make it that far, our devs have some alternative ideas in mind.

Despite the fact that it long preceded the Firestorm 4.4.0 release, we've nonetheless heard from people who associate the issue with our update. How to explain that? Jessica Lyon hit the nail on the head in her recent appearance on The Carter and Dar Show, pointing out that people tend to enter notice-new-stuff mode after they update their viewer. It's when you're most likely to be paying attention.

So the bottom line on this issue: We're all experiencing it, it's not just you. The next Firestorm release will have either the Linden fix or a homegrown workaround. Until then, I recommend getting comfy with your Ctrl-Shift-R.

Experiencing More Lag in 4.4.0 Than in 4.3.1

There are many kinds of lag. The kind this section refers to is frame rate (frames per second, or FPS). Hit Ctrl-Shift-1 to bring up the statistics bar or go to Advanced > Performance Tools > Statistics Bar. FPS will show up at the top. Higher FPS numbers correspond with better performance.

1. FastCache, new to 4.4.0, works better for some on and
better for others off. Try both ways.

Let me start by saying that we have actually received more positive comments about performance with this Firestorm release than any other I can remember. For the majority, this one has been providing improved speed in both frame rate and rez times.

Nonetheless, performance is highly individualized. Changes that improve conditions for some often end up affecting others negatively. So many factors go into performance -- many specific to your setup and various habits as a user -- that not all can be accounted for.

And so for this release, a smaller number of people have found a decline in performance, but some to a significant degree. For instance, some find that in locations where they used to see 20-30 FPS, they're now seeing 2-3, with no amount of graphics adjustment making a mark.

2. VBO improves performance for some and depletes
performance for others. Try this both ways, too.

Under normal circumstances, render quality (graphics) is the biggest and most predictable factor affecting performance. In Prefs > Graphics, the slider at the top has "Performance" at one end and "Quality" at the other. The lower the graphics quality, the faster your performance. The higher the quality, the slower your performance. It's that simple -- under normal circumstances.

But circumstances in Second Life are not always normal, and so for those times when there's something oddball going on, there are a few additional settings to look at.

Important: The results you find from the following settings are going to be specific to you. No specific option will be universally or predictably better for everyone, and your need may change from one version of the viewer to another. Experiment, experiment, experiment. And rather than telling friends what their settings "should be," recommend that they experiment, too.

3. HTTP is yet another setting that works differently
for different people. If you see no significant difference,
leave this on.

1. Fast Cache: Putting this first because it's brand new for Firestorm 4.4.0. Located in Advanced > Show Debug Settings, type or paste "FastCacheFetchEnabled," and try turning it to False. If there is no improvement, switch it back to True.
2. VBO: Located in Preferences > Graphics > Hardware Settings, "Enable OpenGL Vertex Buffer Objects." See whether you get better performance with it off or on.
3. HTTP: Located in Preferences > Graphics > Rendering, "Use HTTP Textures." Issues relating to HTTP got more complicated in the current release, though, so see our wiki page on HTTP Fetching Issues for more information beyond a simple experimental toggle. If there is no improvement with HTTP off, it is generally better to have it on.

Also try these in different combinations with each other. For more info on lag, we have informative wiki pages on general lag info and on troubleshooting lag.

Difficulty Clicking "Continue" on TOS

This hasn't been a particularly common issue, but it's timely.

The Second Life Terms of Service (TOS) got updated Tuesday. Every time there is a change to TOS, every resident needs to formally accept them (presumably after reading the new version) before being able to log in. A very small number of people inevitably have trouble doing so because the TOS loads in such a way that they cannot access the "Continue" button.

If this happens to you, just try using a different viewer to log in. TOS acceptance is per account, so you can do it on any viewer and then switch back to your preferred one. The problem is related to "webkit fail" and thus can theoretically take place on any viewer that uses webkit for web-related functions, i.e., any graphical viewer that is not based on the 1.23 code. Still, some will experience it on only one, and others will experience it on all of them, depending on why the webkit is failing.

And so you can try any other viewer you happen to have installed, but depending on the problem, your best bet might be the very old LL v1.23 (if you still have it) or Imprudence, which is still available for download. Or use a text-based client, such as Radegast.

More info on webkit fail and related topics can be found on our Media and Whitelisting wiki pages.

Other Problems? Where to Get More Help

Comments aren't open for this post. It's not because I don't want to hear from you but because I can't guarantee a response to requests for support here, and I don't want to leave the impression that such a response is likely. If you need help that isn't provided here, then please use the following means and those here:

• The wiki is a regularly updated resource with all known fixes to common problems.
• If you can't find what you need there, join our inworld group, open 24 hours with help from support team members when they're available and from your peers at all times.
• If your problems prevent you from logging in on any viewer, you can request support through the JIRA. Bug reports go to the JIRA, as well.

Fired Up,

Lette