Frequently Asked Support Questions of May 17

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Notifications Purging Between Logins

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

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

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

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

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

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

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

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

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

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

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

System Layers Removing Themselves When Saved

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

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

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

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

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

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

Other Problems? Where to Get More Help

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

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

Frequently Asked Support Questions of May 8

This week's most frequently asked support questions:

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

Prims Invisible Until You…

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

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

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

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

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

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

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

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

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

Experiencing More Lag in 4.4.0 Than in 4.3.1

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

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

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

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

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

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

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

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

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

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

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

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

Difficulty Clicking "Continue" on TOS

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

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

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

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

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

Other Problems? Where to Get More Help

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

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

Fired Up,

Lette

Frequently Asked Support Questions: May 1

(a day late because we were testing a couple of the fixes included)

The three most common issues this week addressed by the Firestorm Support Team (aside from those addressed last week) have been:

• Inventory missing in Firestorm but not in other viewers
• Textures never coming in (possibly in combination with inventory, voice, and/or stream problems)
• Black rectangles in snapshots at some resolutions

Inventory

Inventory problems can have a couple of different causes. If you're only missing inventory in one viewer, then the problem relates to fetching or caching it. We haven't figured out why there has been an increase in complaints in Firestorm 4.4, so if we discover any additional information that points to new fixes to apply, we will share them.

1) In the meantime, start with the suggestions on our Missing Inventory wiki page. We've organized it step-by-step, with easier steps first and longer steps later. We strongly recommend going in order.

2) An additional fix we have just hit upon is that if you can load your inventory in the Second Life Viewer (Linden Lab's V3) and if you're comfortable working in your file system, you can copy your inventory cache file from the V3 cache into the Firestorm cache. This has worked successfully with several people so far. Here's how to do that:

Fig 1: Avatar key is in profile.
Location will vary.

• Start by finding your avatar key (UUID) while logged into Firestorm or another viewer that displays it (see Figure 1). It is a string of letters and numbers that appears in your legacy-style profile, though the exact location will vary because different skin options display it differently. If you use web profiles, you will need to switch into the legacy profile to find it (see Figure 2). You can return to the web profile style afterward if you want. When you find your key, just copy it down someplace.

  

  Fig 2: Your key will only show in legacy profiles.
  Make sure the "Use web profiles" option is unchecked.

• If you haven't yet, log into V3 and get your inventory loaded in that viewer. This might work with other viewers, as well, but V3 is the only one we've tested with. Once your inventory is loaded there, log out.
• Locate your Second Life cache folder and your Firestorm cache folder on your hard drive. Our clearing cache page will help you locate where that is (just replace "Firestorm" with "SecondLife" in the path name). Don't clear either cache! Just use the paths shown to find the folders.
• In the Second Life cache folder, find the file named with your avatar key and ending in "inv.gz" (see Figure 3). That is the inventory cache file for that specific account. Drop or copy this file into your Firestorm cache folder. Allow it to replace the one there.

  

  Fig 3: Look for the zipped file with
  your key, ending in "inv.gz."

• Log into Firestorm and check to see if your inventory is there.
• Avoid clearing cache or you may need to do this process again.

Please note: Under normal circumstances, you should not share cache between viewers because it can cause other weird problems. This suggestion should not be read as an indication that setting your cache in different viewers to the same place would be useful. It won't be.

3) We've had two reports of a Firestorm bridge recreation coinciding with an inventory loading issue suddenly getting fixed. There isn't actually any intuitive reason for that to work, but hey, it won't hurt to give it a shot. To find that, go to Avatar menu > Avatar Health > Recreate LSL Bridge (Figure 4). For more info on the bridge, we have a wiki page on the bridge and what it does.

Fig 4: How to recreate your bridge.

4) If the above suggestions don't help, then try a clean reinstall of the viewer. A few people with inventory problems this week have discovered that a clean install fixed the issue. Take note that a complete clean reinstall includes three fulls steps: uninstalling or deleting the previous Firestorm install (or installs, if you have more than one), manually deleting your settings (and not putting the files back in afterward), and manually deleting your cache.

5) Even though there may be a difference in inventory loading from one viewer to another, it does not rule out the possibility of a network/connection component, as well. Sometimes problems have a combo cause. If this problem persists, see the suggestions toward the bottom of the Missing Inventory page concerning your connection.

6) Also see the next section, especially if your inventory loss is happening in conjunction with…

Textures Not Rezzing

In preparation for Server-Side Appearance (formerly Server-Side Baking), there have been some changes at both viewer and server ends concerning the use of the HTTP texture fetching process. It's out of scope of this post to explain what that is in detail, so I'll be focusing on fixes to the problems that appear to be related to these changes.

The problems may include:

• Textures remaining grey
• Textures getting stuck in a blur-rez-blur-rez cycle
• Inventory problems
• Mesh not rezzing
• Voice, stream, or media trouble

These all have multiple possible causes, so you can find additional suggestions at our inventory, mesh, voice, and media pages.

If you're seeing them in combination with texture failure, though, or texture failure alone, then please see our HTTP Fetching Issues page. It will give you things to try and some explanation of the causes. One possible cause you're not going to be happy to hear about? Your router. See the wiki page for more info.

Very important: One of the best ways for us -- and for Linden Lab -- to figure out how to fix things so that you don't have to jump through debug hoops is to provide us viewer logs so that developers can get a better idea of where the failure is happening. We're collecting logs at FIRE-10020 for that purpose. If you're experiencing this issue, we would love to have your logs. We have a wiki page that explains how to find and attach viewer logs to our JIRA.

Black Rectangles in Snapshots

Photographers are familiar with the long-running issue where high-resolution snapshots come out with a "tiling" effect, with subtle lines crossing through the finished image. The good news is, we received a fix for that from Linden Lab and included it in the latest Firestorm release. The bad news is, the fix has a side effect that some people consider worse than the original problem: it sometimes creates black rectangles along the edge of the image in the saved version of the picture.

The bug report for this issue is at FIRE-9097. This report correlates with reports on the Linden JIRA (which, unfortunately, are not publicly visible): BUG-1094 and MAINT-2150.

The Firestorm team doesn't have any developers at present who work on the sort of code that could fix all this high resolution snapshot wonkiness once and for all, so we need to continue waiting for Linden Lab or other outside developers to address it. If you're about to say, "Well, why don't you get one?" then, uh… if you know any, send them our way and we just might! If only it were as easy as plucking one off the Developer Tree!

At best, our developers might be able to provide an option between the old and new behavior. That means you get to choose which bug you prefer to Photoshop around. Not the ideal solution, and they're not sure they'll be able to implement it at all yet, but if they can, it might do until a bug-free snapshot experience comes our way.

In the meantime, there are a couple of known workarounds, though the shortcomings will be obvious to photographers:

• Sticking with the standard resolution sizes, rather than setting a custom one, will allow you to avoid the issue.
• The problem only occurs when Advanced Lighting Model (formerly known as Lighting & Shadows) is on. In other words, you get a tradeoff between using high resolution or using shadows, depth of field, etc.

If you discover any workarounds that will be more appealing, please post them as a comment on the JIRA.

Since we'll most likely need a fix from Linden Lab for this, feel free to file reports on their JIRA under the BUG heading. Just make sure to log into and test the problem on the Linden Lab viewer first and to include the system info from their viewer, not ours. Just as we can't work with problems that aren't reproducible on Firestorm, they can't work with problems if you haven't checked for them on their viewer.

Further Help and Why No Comments?

I hope this blog post contained useful information. Last week I made the mistake of leaving comments open and unmoderated. You'll notice that's not the case this week. 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.
• A one-stop list of all the ways you can get help from our support team is right here.