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!