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.

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.

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.