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.

Heard That One Before, Part 9: Connecting the Dot Dot Dot

This post is part of a series on common barriers in communication when it comes to getting help for problems with Firestorm Viewer in Second Life. The series starts here.

9) Can't you just get the devs to do it?

Pffft. I wish.

"You there, dev. You got nothing better to do? Well, this random user wants me to get you to drop that project you're already in the middle of and work on the issue they think is more important."

Yeah…no.

There are two main reasons people ask, "Can't you just get the devs to do it?" One is that they don't want to file the bug report or feature request on it themselves for any of a variety of reasons (lacking in self-confidence, hate the JIRA, simply lazy, etc.). The other is that they think that a support person will be more effective at "getting a dev to do it" than they would be because we have "connections."

Both reasons are based on misconceptions of the process and our team's structure.

How It Works

The two biggest misconceptions that shape these problems have to do with 1) the process and 2) its pace, and these misunderstandings feed into animosity about or reluctance to engage in reporting bugs. Just a hunch, but I suspect that those who know more probably have more realistic expectations.

So we'll start with how bugs that you find or features that you want normally get implemented. I'll refer to bug reports here, but feature requests actually follow the same process.

In almost every case, it starts with a user submission at http://jira.phoenixviewer.com/. Now… a number of people who've delivered the "Can't you just…" line seem to argue, "But there was this one time when I mentioned this thing to a dev and it happened right away. I didn't need to file a JIRA then, so why should I have to now?" That's going to be an exception, not the rule, and most likely, the dev did it either because they were already planning to do it or because someone else filed a request for the same thing. If you look through old issues, there will most likely be one there that matches yours.

http://jira.phoenixviewer.com/

And so, it starts with a bug report on the JIRA. The issue will get its first look pretty quickly. A few people on the team look at new issues daily. They'll ask for additional info if necessary. They'll link and close issues that are out of scope or duplicates of previous reports. They'll move issues to the support section (not publicly visible, but you'll be able to view your own issues there) if they aren't true bugs. After that, though, it's time to wait.

Depending on the issue, it may sit for a while. Some sit for only days, others for months and months and months. This doesn't mean the issue has been lost, that it will never get implemented, or that it isn't getting looked at on occasion. All it usually means is that there is no developer available at the moment who has the time to work on that specific issue and knows what needs to be done to implement it. That's actually pretty straightforward when you think about it, right?

After an hour, a week, a month, or a year, it may get assigned to a developer. That developer will work on fixing the bug for however long it takes, given the complexity of the code, their real life and SL schedules, and their other development workload. After another hour, week, month, or year, they'll finish the code, mark the issue as fixed or completed, and add it to the viewer repository (the big code collection that comprises the viewer).

Once the code is in the repo, it waits to get tested. Since Firestorm's releases are usually about two to three months apart, it might take even more time before that bug fix actually shows up in a publicly available version of the viewer, but the status can be tracked in the issue you filed. If it passes QA (quality assurance), then it will be included in the next release.

And voila, that's the route from issue to fix.

How long can you expect it to take? Well, over Firestorm's history, the average time from issue creation to issue resolution has been about 73 days, though specific issues have taken anywhere from one to 535 days. As far as I'm aware, that's not an unusual pace for software development, especially when the developers are doing the work in their free time. I include these numbers to provide some perspective. Some people "hate the JIRA" because they think it "doesn't work," and they base this assumption on the fact that the bug they reported last month hasn't been fixed yet. It's like refusing to use a car because it doesn't fly. Or teleport. Patience, grasshopper. 

And there's always the duh factor. Although 73 days might sound like a long time to wait for something you think you need, guess how long it will take if you don't file at all? Go ahead and hold your breath. I'll let you know when your face turns blue.

"Connections"

The more laughable reason we hear "Can't you just get the devs to do it?" is when folks think that if the request comes from someone on the team, it will hold more weight than if they do it. In some cases, they think that we have so much weight that we wouldn't even have to file a JIRA for it -- that all we need to do is ask. I even got into an argument once with someone who wanted Jessica Lyon to file a JIRA for him because her voice would have the most pull. And she should do this favor for you… why, exactly?

To address the idea that we don't have to file JIRAs: We do. Everything gets filed. If we have a feature request, we file it. If we spot a bug, we file it. Developers file JIRAs for other developers to work on. Developers file JIRAs for themselves to work on. And if a developer has already done work on something, they'll file a JIRA retroactively so that it's documented for the testers.

The JIRA is a to do list and a record of what has already been worked on. Literally no one is spared from JIRAing.

As for the "connections" perception, well… it's an odd one because it's more skewed than it is completely wrong. But it's a weird interpretation of our actual team dynamic, and the weirdness feeds into why saying, "Can't you just have a dev do it? You're the one with connections," won't get you very far.

So… yeah, I know the devs. I'm in contact with them all day in our various inworld and out-of-world chat rooms. We have a whole virtual office going on. With that frame of reference, would you say the shoe department has "connections" with the furniture department? That patents has "connections" with accounting? That obstetrics has "connections" with oncology? We're just different departments on the same team. When we work together, it's not about pulling strings, it's about collaboration, as teams do.

We don't schmooze with devs, we work with them. And when we have issues we want looked at, we file JIRAs. Indeed, if we asked the devs for "special favors" for everything we wanted, let alone all those we are asked about, our working relationship would sour very, very quickly.

Making it Work for You

Admittedly, filing a JIRA is easier said than done. I can repeat the mantra til kingdom come and some people will still avoid it like syphilis. Let's talk about the legitimate concerns and how we can help you with them.

"It's designed for people who aren't me." Would it make you feel better if I said that's how I feel about Facebook?

"I can never find anything on it." The search functions actually became easier to use lately with a platform update, but I agree it can still be confusing.

"I'm afraid of putting something in wrong and ruining my chance of getting my issue looked at." Been there myself, so I'll try to quell the fears.

Yeah. A large chunk of it feeling foreign and uncomfortable is just that it's foreign and uncomfortable. The fact that it appears jargony and techie and scary can intimidate some into thinking it's hard to get used to, but it's really no worse than any other platform when it's new to you. The biggest difference is that when it comes to the JIRA, you have a team of support people standing by to answer your questions.

There are three ways you can learn about how to use the JIRA:

• Reading and following the wiki page on how to file a JIRA;
• Attending the Reporting Bugs, Requesting Features class we hold inworld (class schedule updated progressively);
• Asking a member of the support team -- not to do it for you but to explain anything you don't fully understand.

http://wiki.phoenixviewer.com/file_a_jira/

If you're just trying to find your way around, either the wiki page or the class will work well for you. If you're specifically having trouble with the search mechanisms, come to the class -- we give some tips on that, with visual aids. If you're worried about embarrassing yourself by filling the report out wrong, either attending the class or seeking out one-on-one help is probably best.

We're used to seeing errors in the JIRA, and we can edit your ticket if the errors create ambiguity. We'd rather have a shabby JIRA from you than no JIRA at all.

I should note that on some occasions, support people will do a JIRA themselves based on your complaints or comments, but this is most often the case if it's a bug they can reproduce on their systems and that they think they can describe best. It's not as common for feature requests, and if the team member can't reproduce the bug, they're not going to be the best ones to file the report -- you are. Furthermore, it's a case-by-case matter even when we choose to do the filing. If you have a bug that takes place only in Mouselook, for instance, I'm not going to file it for you even if I can reproduce it: I don't use ML regularly, and my familiarity with its quirks is probably limited to what you've just told me in our conversation. I wouldn't be able to describe the problem as well, and if a dev asked for more info, I'd be totally useless.

Fact is, you are the expert on your own experience, and in most cases we need to hear it from you when things are not right for you. Finding and reporting bugs is a collaborative responsibility. You are entrusted to take part in this process, and we'll do our best to show you how.