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.

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.