Ashes to Ashes

The prospect of the "death" of Phoenix Viewer has been vexing its ardent users for anywhere from the past week or so to two years (depending on when they first heard something about it). Our team first warned of Linden Lab's intentions to make the grid increasingly incompatible with traditional V1s in the fall of 2010 and then ramped up the volume a year later. Although LL's plans have taken much longer to develop than we expected, the end of Phoenix's viability on the grid is now concrete and fast approaching. 

Some Phoenix users see the Phoenix Firestorm team's decision not to keep the viewer up to date with the grid's impending changes as a betrayal of their loyalty or a murder of the client; they can't imagine using another viewer. I will attempt in this post, as straightforwardly as possible, to explain why it is actually neither one.

Viewer software for Second Life is open source, meaning that anyone who wants to and knows what they're doing can obtain the source code and try to improve on it, customize it, make it something closer to what they want it to be. As long as you stay within both legal parameters (a lot of the code and the supplementary software is subject to licensing terms) and Linden Lab's policies, the options are as broad as your imagination and coding abilities.

Sounds a lot like creating inworld content, right? Your world, your imagination, and your proficiency with Blender and Photoshop. Only with a lot less Blender and Photoshop and a lot more C++.

Where do developers get this code and do this fun stuff with it? Linden Lab and any Third Party Viewers on the Linden-approved TPV list keep their released code and most of their unreleased code in online spaces called repositories. It's available for anyone to view or download. Whether you can make sense of it or not is another story.

But the important thing is that some people can. And not all of them are on the Phoenix Firestorm Project. 

The important thing, in other words, is that the Phoenix Firestorm team has no ownership, no monopoly, no exclusive claim to the Phoenix code. It means that anyone with the desire and the know-how can dive right in and claim the continuation of Phoenix's development as their own ambitious project. Not just one person. Lots of people. Lots of Phoenix forks can come out of the Phoenix code.

They'd have to change the name, and if they wanted it on the TPV directory, they'd need to incorporate some original code, but there's zero reason why the Phoenix Firestorm team's decision to no longer be the ones developing Phoenix should mean the viewer dies.

All you need is the desire and the know-how, and YOU can be Phoenix's savior. YOU can be the one whom Phoenix fans adore for your passion to keep the viewer alive. YOU can do for Phoenix users what was once done for Emerald users back in 2010, pulling the "viewer from the ashes" from, well, the ashes. YOU can be -- fine, I'll just say it -- the Jessica Lyon of 2013.

But there's that one hangup: the fact that this task has two requirements, both desire and know-how. Which means there are Phoenatics saying, "I'd love to do that, but I don't know anything about coding!" and there are developers saying, "Well sure, I could do that… if I cared."

The trouble for Phoenatics is not solely that our team no longer wants to work on -- and, soon, won't be supporting -- Phoenix. The trouble is that there may be no one else with development background who wants to, either. There seems to be no overlap between those with desire and those with know-how. Why is that?

Let's crank out some theories.

Theory 1: Developers are technologically progressive, and most have moved on to V3 viewers.

This can work as a partial explanation but not a full one, since folks generally have lots of different reasons for their viewer choices. It does, however, thin the herd for potential candidates considerably. Although there are still coders, developers, and self-compilers who prefer Phoenix over Firestorm, they seem to be in the minority, and an ever-shrinking minority at that.

The most common reasons that people remain on Phoenix are less likely to apply to the people most equipped to keep it going.

• Developers are more likely to keep their systems up to date than most of us, so they are seldom the ones being held back on an old viewer because of their hardware.
• If there's something they hate about a viewer (like Firestorm), they are more likely to know how to change it themselves rather than avoid it completely or know the correct avenues (JIRA) for requesting the change.
• Many spend more use hours inworld, which means more of a chance to push themselves to get used to the V3 interface even if they can't improve on it themselves.
• If they experience poorer performance on V3s than on V1s, they're more likely to know what adjustments to make at their end to compensate.

There are certainly developers the above points don't apply to. I'm not gonna say they aren't out there. There are even devs on our team who still use Phoenix. But my general impression is that the vast pool of Phoenatics who would be passionate enough to fuel a revival simply does not include a lot of people who possess the expertise to do it, largely because most of the folks with expertise have already moved on.

Meanwhile, most of the V1-using developers around are already spoken for.

Theory 2: V1 developers are already hard at work on their own projects.

There are, in fact, two V1-based viewers under active development -- Singularity and CoolVL -- whose developers clearly challenge Theory 1. Are developers like Siana Gearz and Henri Beauchamp contenders to the savior-of-Phoenix throne? They could be if they wanted to be, knowledge-wise, but I have the feeling they're more ready to watch their own viewers' user numbers go up in the near future.

You see, what you may not know is that these viewers have had releases more recently than Phoenix and have thus advanced beyond Phoenix in some areas, such as multiple clothing layer support (the ability to wear more than one tattoo, alpha layer, or other clothing item on the same system layer -- not to be confused with multiple attachments, which Phoenix has had for two years). If existing V1s were to refashion themselves as Phoenix forks, they'd actually be moving backward. Phoenix hasn't been the most advanced V1 viewer in a long time. Anything these devs wanted to draw from Phoenix in terms of code content has been available to them for months.

In other words, the revival has long been in progress. Just not by our team. Or even by people who would associate themselves with the Phoenix name. But they're there for the V1 diehards, and I'm sure they'll be happy to see your downloads.

Those developers, in fact, have done most of the work that Phoenix pulled in during its final six months of development -- most notably, mesh rendering, built by Henri Beauchamp. Our devs did the work of merging it in, but the original coding was done by others. 

If Singularity and Cool aren't what you're looking for -- if nothing will do for you except an actual Phoenix resurrection -- then let's tabulate… now you need someone who not only has the desire to develop a V1 and the skill to develop a V1 but who isn't already busy with their own V1 project.

Theory 3: Keeping a V1 viewer compatible with a V3 world is difficult and time-consuming.

Well… it is. It's the entire reason for where we are now.

Theories 1 and 2 only explain part of the reason why no one so far has jumped in to pump new wind into Phoenix's sails. Number 3 takes care of the rest. It explains not only why our team doesn't want to do it but why we may find that no one else does, either. Or at least no one has been making a visible effort so far. The last major Phoenix release was a year ago this month, with a minor one in March 2012. Jessica Lyon warned that Phoenix 1.6.1 would be one of the last Phoenix releases 53 weeks ago. Those were 53 weeks during which someone could've gotten their butt in gear to be ready for the final end to development and support.

Didn't happen.

Of course, now that the cat is out of the bag about the team's decision to move away from Phoenix, we might see people stepping forward. If someone does end up coming to bat for Team Phoenix, then their first essential task is going to be preparing the viewer to be compatible with server-side baking. This is a fix for avatar bake issues (think clouds, ruths, blurry people, and unintended nudity) that Linden Lab will be rolling out some time in the New Year and that will considerably break the usability of any viewer that doesn't upgrade between now and then, Phoenix's included. There's no real disadvantage to using an unsupported viewer right now. But when that change comes, you'll be -- pardon my Esperanto -- up shit creek. Unless your favorite color is grey.

These hypothetical Phoenix-of-the-future devs will also probably want to work on pulling multi-layer support from the other V1 viewers to make Phoenix current. And if they're trying to get Phoenix's users before they migrate fully to another viewer, they might want to scramble some support resources together or prepare for a deluge of questions and requests for help.

It will be a significant amount of work and will take someone who has a true passion for Phoenix. If someone decides to do it, they can probably expect a moment of notoriety and a lot of grateful users at first, but that will fade as soon as those happy users start to take the viewer and its upkeep for granted. Eventually, there will be all the usual support and bug complaints, along with passive-aggressive reminiscences of how great the old Phoenix was (not because the new devs do anything wrong but for the same reason we still hear people fondly remembering Emerald and asking, "Why do none of these viewers run as well as that did?" and conveniently forgetting that its problems were not fewer but merely different), and whines about why it doesn't yet have that Awesome Feature X that all the V3s got weeks ago.

Goddess help them if they ever discover it's too much to handle, though. Take it from us… as hard as it is to jump into an endeavor like that, it's a lot harder to disengage from it.

Heard That One Before, Part 7: What the Mean Means

Welcome to the next installment of "Heard That One Before," the series in which you hear from the front lines of Phoenix Firestorm Viewer support on how not to make it more difficult to troubleshoot your issues. Today's topic got a little lengthy because there are nuances to it, and I wanted to be totally clear about what I do and don't mean by it. Hopefully, it's clear enough.

7) "I'm not a techie / Second Life professional / support person / dev and therefore can't understand a word you're saying / anything on your wiki."

As usual, there are different layers to this, so let me be specific. This is not about those who are aware that they don't know a lot about the viewer or their computer or SL. If by "I'm not a techie," you mean "I'm computer illiterate" or "I need more help understanding what's going on here," then don't worry, this is not about you.

It's about those who, if they don't understand something we tell them or that they read on the wiki, conclude that we're speaking too technically not just for them but for the "average person" and go on to tell us so in a way that suggests that we must be technological elitists who aren't interested in helping the "majority" of users.

In other words, the problem is not in whether the person knows something or not -- it's always ok not to know things -- but in where they attribute any criss-crossings of communication that occur when support is trying to help them.

If you need us to explain anything better, just ask. We work with such a wide range of people with so many different backgrounds that it takes a lot to make most of us judgmental about what you do or don't know. Ordinarily, all you really need to say is, "What does that mean?"

In this context, "What does that mean?" differs from "You're too technical for the average user" in a very important way: it's neutral. It doesn't imply that either of us ought to know more about what the other person knows than we could possibly be expected to.

It would probably surprise most people that I don't think of myself as a techie, either, and this is part of why the "You're too technical" comment is not only unproductive but sometimes startling. I know the viewer decently well, but if you want me to talk about computers, I'll be pleading the Fifth. Anything I know, I learned by lurking in the viewer group, eventually chiming in when I knew something (which, almost without exception, I had learned there in that group), and then picking up more on the "job." I entered support not knowing my operating system was out of date, never having performed a clean install, and terrified that I'd be expected to know things about Macs simply because I'm a Mac user. I wasn't invited to the team because I was a genius or an expert; I was invited because I was helpful and open to learning. There are a number of people on the team with similar beginnings.

Further, the more you know, the more you become aware of not knowing, so I really don't feel like I'm anywhere nearer to being "a techie" (whatever that means) than I was almost two years ago. The most valuable skill I've learned is not how to answer questions but how to ask them. Sometimes I'll be asking for help from others, and other times I'll be asking a user questions to figure out how best to help them. Either way, when you ask questions, you turn the helping process into a conversation where you can gain the information you need, and the helper learns how to explain it in a new way.

When you use the line, "This is too technical for the average user," a barrier comes up. Unlike "This is too technical for me," a comment that implies that the information is still accessible, the replacement of "me" with "average user" suggests the opposite: that it's closed off, that the user bears no responsibility for it and thus may not be interested in learning it. It's a subtle difference, but I've seen it make or break dozens of support sessions.

Who Speaks for the "Average" User?

This is really the question at the root of where the "You're too techie for the average user" issue comes from. Fortunately, most people have a pretty good sense of what they don't know and can admit to the gaps in their knowledge, and as a result they're good at asking questions or at least pinpointing what they don't understand. I love working with people like that because it means the issue might turn out to be a little one that just needed a better explanation.

The problem comes in when a user and a support person's perceptions of "average" don't mesh. So let's talk a bit about where these separate perceptions come from.

Our (support's) perceptions come primarily from past experience helping people, with specific explanations tweaked according to other factors, like what kind of an understanding a user has exhibited earlier in the conversation and how long they've been in SL.

When it comes to how we explain stuff, we get opposing complaints from both sides, as the very first post in this series should illustrate. We're about equally likely to get "You're talking over my head" as we are to get "You're talking down to me," and sometimes -- more often than should be logical -- we get both from the same person, in the exact same conversation. Both of these reactions are different sides of the same coin. They're defense mechanisms, the first against feeling dumb and the second against feeling like your intelligence is being insulted.

As a result, the way we explain something will be a result of weeks, months, or years of experience, of talking to users and eventually figuring out what explanation works for the greatest number of people: detailed enough that most people will understand it, but not so detailed that most people would be offended, with the recognition that there are always a few people who will still need more explanation.

We'll adjust that as needed, too. I have some regulars to whom I immediately give detailed explanations because I know they need that and others who need exactly the opposite. If I'm talking to a newbie, my answers are going to start out more precise than if I'm talking to someone with a 2004 rez date.

It could turn out that the holder of the eight-year-old account might have taken seven years off and now needs a newbie-level explanation. The person on the new account might be an experienced user on an alt. In either case, I'll adjust. I'll feel my way as I go. But in all cases, I'll be starting at a flexible middle point that I came to not by basing the "average user" on myself but by honing what kinds of explanations seem to work best with the widest range of users.

Am I wrong sometimes? Of course. But the point is that if I speak over your head, it's not for lack of doing my best not to. It's not because my explanation is "meant for" someone who knows a lot. If I fail to explain something you need explained, more likely than not it's because the majority of people I've spoken to previously were ok with the explanation I gave.

Here's where it gets tricky because there's no easy way to sugar-coat it. You might notice this means I'm suggesting that if you don't get what we (or the wiki) are saying, your level of understanding might be below average. Well… sometimes, yeah. Sorry, but yeah: on that particular subject.

This shouldn't make anyone feel defensive, though. Knowledge (including viewer, computer, and SL knowledge) isn't a greater than/less than quantity. It's pretty normal to know plenty about one subject and very little about another, so we expect to be asked for clarification sometimes.

But what if you don't feel unknowledgeable? What if you see yourself on par with the average user? In most ways you probably are. Those who are aware of the gaps in their knowledge on a particular topic won't be embarrassed by having to ask for clarification; it's only when a user thinks they're about average, but our experience with a range of users tells us otherwise, that this uncomfortable situation comes up.

What is "Too Technical"?

Here are some examples of subjects that I have been told are "too technical." To be clear, these are not all topics that the "average user" necessarily knows; in fact, the number of times I've been asked for clarification on some of them has taught me to present them differently or have an explanation at the ready. Others I've only been told are "too technical" once.

• The term "docking" (as in tabs docking into windows, or windows docking to other parts of the UI).
• The abbreviation "UI" ("user interface") and its meaning (the buttons, windows, and other graphical parts of the viewer but not the world).
• The abbreviation "OS" ("operating system"), as well as what it means (Windows, Mac, and Linux and their various flavors).
• How to find a skin or shape in one's inventory.
• Anything included in a wiki page.
• How to follow a path in the First Menu -> Next Menu -> Setting or Preferences -> Tab -> Subtab -> Setting format to locate a setting.
• A computer file path in the [USER NAME]/First Folder/Next Folder/Last Folder format.
• The use of the word "path."
• How to locate the number of items in one's inventory.

As I mentioned, the above list is not intended to imply that everything included is basic knowledge. Rather, the list is there to give a range of topics that do come up, some of which might make you say, "Yeah, that's kinda techie," and others of which probably make you go, "Seriously?" They're also not listed in any order of difficulty, and I won't be identifying which ones I'm asked for all the time and which ones I've only had to explain once to a non-newbie.

That variety is the point. You never quite know what people are going to think is "too technical," and if we err too far toward assuming people know nothing and need everything explained, then we risk irritating a lot more people than we're helping.

There are two sides to the solution, however. One half of it is for support and the other half is for users.

Our responsiblity is to keep mental note of what topics we're asked to explain over and over and over again and to adjust our approach to them if we have to. That process is continuous -- we've all been doing it since we joined the team, and we'll continue doing it while talking to you.

Users' responsibility is, if there's something you don't understand, all you have to do is ask. No attributions of techieheadness necessary. A simple "What does this mean?" will do.

The Wiki: Contestable Terrain

This applies to our wiki, too. Sometimes we'll direct a user in need to one of the wiki pages already set up for troubleshooting the particular problem they have, and they'll return after a few minutes to say, "I don't understand anything on that page; it's written for techies, not regular people." Well… the wiki doesn't have the easiest design to read when you're new to it, and sometimes it's frustrating to face a wall of text and not know where to begin (though the beginning is usually a good choice), but the instructions are meant to be straightforward.

Trouble is, although I can adjust my explanation for someone line-by-line in a real time conversation, the wiki is only changed if and when we know it needs to be.

This means that if it isn't as straightforward as we hope, then you can do us a load of good by telling us what should be straightforwardized better for you (and possibly for others). What this takes is specificity. "It's written for techies" isn't as helpful as, "When it says to go to a certain folder, I don't know what that string of words and slashes means." If you're unable to give us that specificity, then it probably won't get fixed.

In the end, let's make it about the information. About problems and solutions. If you don't understand a suggestion we make about a solution, let's focus on helping you to understand it. When there's a wrench in that system, we'll rely on you to help us just as much as we're helping you. Implications that we don't know how to speak on your level won't get us nearly as far as straightforward questions and pinpointing what you need explained.

The Phantomless Menace: Using the Firestorm AO to Replicate Phantom Mode

Up until recently, a number of Third Party Viewers have had a popular feature known as "Phantom mode" that allows the user to make his or her avatar immobile. Phantom mode was excellent for preventing one's avatar from being pushed by griefers or aimless noobs.

Unfortunately, when Linden Lab introduced their Pathfinding feature, Phantom mode was broken as collateral damage. Yes, the setting still shows up in your menus if you're on an older viewer, and yes, you won't be able to walk if you turn it on. But your avatar will be pushable. That part is gone, probably for good. Consequently, if you've upgraded your viewer since Pathfinding came out, you're probably using one that does not have Phantom mode as an option. Doesn't work anyway, so why leave it in?

So what other options do you have now?

• Option A: Just use a Force Ground Sit. In Firestorm, this is found in Avatar > Movement > Force Ground Sit, or Ctrl-Alt-S. As many of us learned as our first lesson in virtual self-protection, you can't be moved if you're sitting. And Force Ground Sit will sit you down anywhere at all, even hovering in the sky. 
• Option B: There are HUDs you can purchase that include a "movelock" feature that works similarly. No, I can't name a single one. I'm not a HUD person. Search the Marketplace if you're interested.

The drawback of Option A is that you'll be sitting down. There may be times when you'd rather be more subtle about what you're doing, and you probably don't want to sit in the middle of a club where everyone is standing or dancing. The drawback of Option B is having to use a HUD when it's really not necessary. Some people don't give that any thought, but I like to keep my screen and my attachment points free and clear, and I prefer to minimize worn scripts to only those for which there is no alternative.

So here is a nifty alternative that works well on Firestorm and any other TPVs that have incorporated the Firestorm client-side AO. It involves using the internal animation overrider to put your avatar in a ground sit while it appears to be standing. After it's set up, it's close enough that we can call it Fake Phantom. If you've already been using the Firestorm AO, then this will be very straightforward and you can mostly skim. If you're new to using the Firestorm AO, then read carefully and go one step at a time.

Replicating Phantom Mode in a Post-Phantom SL

1) Make sure you have at least one stand animation in your Inventory. You can copy one or more out of your animation overrider HUD if you need to (and if they are copiable). See "Extracting Animations" below for more info.

2) Open the client-side AO window. On all skins except the Vintage skin, do this by clicking the button marked "AO." On Firestorm's Vintage skin, click the Up arrow alongside the part that says "AO."

3) If all you see in the AO window when you open it is a dropdown, a couple of arrows, and a "Sit" box, then it's in its collapsed state. Click the Wrench icon to open it to full size.

4) Click the "+" icon in the full-size AO window and name the set you're about to create. "Standing Ground Sit" would be a logical option.

5) About a third of the way down the window, find a dropdown that most likely shows "Standing." Change that to "Sitting on Ground."

6) Drag one or more stand animations from your Inventory onto the open AO window. It will say "Reloading Config / Please Wait" while it processes. When it's done, you should see the animation(s) listed in the window.

7) To turn your new Fake Phantom mode on:

• Make sure it's selected in the upper dropdown in the AO window.
• If you have other AO sets loaded in addition to this one, click the checkmark icon to the right of the name. This tells the AO which set to use.
• Turn the AO on using the toolbar button. On all skins besides Vintage, click the box in the corner of the button so a checkmark appears in it. On Vintage skin, click the part that says "AO."
• Force a ground sit by going to Avatar > Movement > Force Ground Sit, or hit Ctrl-Alt-S.

8) Find yourself standing unmoveably in one spot. Don't forget to hit Stand before you try to go anywhere.

Additional Bits 'n' Pieces

• Extracting animations: Your AO HUD is just like a box. You can unpack the contents in the same way.
• If the animations are copiable, then you can wear the HUD, right-click it on your screen, and put it in Edit mode. Flip to the Content tab, find the animations you want to use, and left-click drag them from your AO into your Inventory. It doesn't much matter where they are in your Inventory for this particular use of the AO, but it doesn't hurt to create a folder for them so you can keep track of them.
• If they're not copiable, then you can't have them in more than one place at once. Either in the HUD or in your Inventory, but not both. You can, however, use the same animation in more than one set in the client-side AO. So instead of just unpacking the stands, you might as well unpack everything at once and create not just a faux-phantom set but a regular set as well. Take the HUD off if you're wearing it, rez it on the ground, right-click it, and choose "Open" and then "Copy to Inventory." Then go back to the above instructions to finish creating Fake Phantom.

• After you've created your Fake Phantom mode, you will have actually followed the same instructions you'd use for creating a full internal AO set using the Manual Method. To create that, as well, hit up our wiki page. Most of it will sound and look very famliar now.

• Instead of stands, you can use dances for entering Fake Phantom mode at a dance club. Just follow the above instructions, but instead of loading standing animations, load dance animations. They will allow you to appear to be dancing when you're technically ground sitting.

• If you've loaded more than one stand (or dance) animation as ground sits, you'll probably want them to cycle. In the AO window, make sure you have the ground sit set selected at the top and "Sitting on Ground" selected in the lower of the two dropdowns. Check the box marked "Cycle" and put your preferred cycle time in the space provided.

• You can always add or remove animations from this set. To add, simply drag the additional animations from your Inventory onto your AO window as you did when you first set it up. Just make sure you have both of the dropdowns in the window set properly. To remove animations, highlight them in the AO window and then click the lower of the two Trash icons.

• It doesn't matter what store you bought the animations from. It doesn't matter if they're copy or no copy once they're in your Inventory. This process works the same way regardless of those factors.

And that should do it! With just a little bit of prep work, you can get back that phantom functionality you're used to!

Heard That One Before, Part 6: Everythingitis

This is the latest in a series of support-related blog posts. These pieces are meant to focus on approaches people sometimes use with members of our support team when asking for help but are, for one reason or another, not conducive to the troubleshooting process. My hope is that some of what I've written here will be applicable to other circumstances, even if it's just trying to get tech support in some other context.

6) "I've tried everything."

This is never literally true, which makes it somewhat frustrating when someone tells us this but then refuses to elaborate. "Everything means everything," they say. Well… you'd be surprised how many definitions "everything" has. For some people, "everything" means they cleared their cache. Claiming you did "everything" is, ironically, an invitation for us to start you from scratch.

You know that one meme, don't you? Just imagine, while you're reading this, three boxes depicting:

"What I think 'everything' means"

"What support thinks 'everything' means"

"What it actually means."

No matter what you put in the first two boxes, the third should contain absolutely nothing.

Why this phrase is a problem:

There's a vast difference between everything and everything you can think of. If you had actually tried everything, then there would be nothing else to try and no point in asking for help, right? I mean, you tried everything. What more is there? In realityland, the fact that you're asking for help inherently implies that you know there may be fixes you aren't aware of.

If you've tried everything you can think of, on the other hand, then step right in and tell us exactly what that consisted of. We'll see if we can think of more options.

If you can't tell us what that was, then try not to be offended when we backtrack and suggest you do things that it turns out you already did. We've already determined that "everything" means "everything you thought of," so hopefully you can understand that we don't automatically know what that is.

Working with our wiki:

Sometimes we get the "everything" line after we've offered a wiki page of suggestions and the user returns (sometimes ridiculously quickly) and says he or she has tried everything on the page and nothing works. If we're skeptical about this, it's because of two factors: 1) the sheer frequency, in our experience, with which that turns out to be untrue, and 2) the fact that if none of the fixes on the wiki work for you, then you're not experiencing a "known" and reasonably fixable problem.

If your problem and its fix are not immediately known, then we'll be stabbing in the dark. You may be in for an extensive round of filing bugs, sharing viewer logs, allowing a team member onto your computer via TeamViewer, completely losing your saved settings, or worse. You don't want us to have you reinstall your operating system all because you skipped a step on a wiki page and got ticked off when we suggested going back over it.

Seriously, you may not want to work on your issue alone. You may not want to use the wiki. But you want one of the fixes on the wiki to work because those are the ones that will take less time or that have worked for enough people before you that we confidently recommend them. Some involve learning something new about your computer, but they're still a lot easier (for both you and us) than anything that is not yet documented.

Questions as specific as answers:

A lot of the time, when people say they tried "everything" on the wiki, it turns out to mean they tried everything they understood. Anything that looked like gibberish to them ceased to exist in their awareness, as if it were not there at all. That's not helpful.

If there's something you don't understand, please ask about it. Point out: "I don't understand what this line means." Ask: "Does it apply to me?" The more specific you can be about what you need help with, even in our wiki, the faster and better we can help you.

So to sum up:

• Specificity is good.
• You don't have to avoid the word "everything" as long as you realize that it doesn't substitute for a detailed explanation of what you've tried.
• It's ok not to know things or not to understand something on the wiki. It's not helpful to overlook instructions because you didn't understand them -- ask about them instead. Specifically.
• If we want to retrace steps you think you've already taken, don't be upset. Chances are it'll go a lot faster than whatever we might have to try next.
• Even if you're asked to redo something you did do, it might still pay off. Competent users are the ones who know the value of double-checking and who don't get offended if we ask them to do it.

Need something more concrete?

Here's an example that happened just today. The user was having a not-uncommon issue, in which she was getting logged off at the end of the login process on Firestorm. She'd been in the group since last night trying to get the issue fixed, beginning at around 8pm SLT. I went to bed in the meantime (though I had a sneaky alt logged in), and the same person was still around in the morning with the same problem.

After I saw a couple of suggestions not work for her, I directed her to the fs_install_crash wiki page and its instructions for the problem "Firestorm Logs Out During Login." I asked if she'd already done that one.

"I did everything on that page," she answered immediately.

Now, she'd probably been getting weary of wiki pages by that time, and for those who don't read them frequently, they're likely to blend together. So I dug. "So you've deleted your open_notifications.xml file?" I prodded, because specific questions are good.

"I can do that without logging in?" she asked.

Well, since you have to be logged out to do that, that pretty much told me all I needed to know. I got her OS from her and copy/pasted the path to the file to her. A helpful user in the group helped her figure out how to locate it in Windows, and once she had, I explained what to delete. She logged back in on Firestorm with no problem and came back to thank us.

I became curious and searched through the logs from the previous night. Sure enough, around 11pm SLT, Miro had given her that very page and told her which section to look at. What I had told her to do, step by step, was exactly what the wiki instructed. Textbook case of Everythingitis.

Let's rewind a bit. Let's say I had taken her literally when she said, "I did everything on that page." Here's what probably would have happened: I'd have had her spend time resetting her router/modem, checking packet loss, running a speedtest, adjusting bandwidth, and attempting to log into a bunch of different places. When those didn't work, I'd have had her register for the JIRA, figure out how to locate logs, attempt to reproduce the problem, file a ticket, and upload the logs. Then I'd have waited six hours or so for Whirly or Nicky to wake up, poked them to look at the logs, and gotten confirmation on my very first guess: that the user just had to delete her open notifications.

This was also, of course, a solution the user had been offered eleven hours prior.

Sometimes you will get asked to redo things you did already do. But in my experience, the most knowledgeable folks are the ones who don't mind repeating steps even if they've already tried. They know that it pays to double-check. And they know there's no such thing as "everything."

Not One Size Fits All

I'm all for people being more informed about how their viewers work, and so I was interested to see Cajsa Lilliehook's Under the Hood: The Debug Settings blog post. While it is all informative, a few of the recommendations offered point to the ways in which different inworld priorities sometimes clash. That is, what's best for making things look good isn't always best for how things run. And I would like to offer additional insight into some of these settings. This isn't meant as a dispute or a flame, and only in some areas as criticism; it's meant as a contextualization and an offering of additional information. If Cajsa takes us under the hood, I'd like to talk about what motor oil to use.

Those of us on the Phoenix/Firestorm Support Team tend to look at things from a troubleshooting angle, which doesn't always coincide with the priorities of creators or photographers. Unfortunately, some popularly recommended settings aren't universally ideal for all users, and we frequently end up with people asking for help for issues that were caused because they heard that a certain setting was "best." But best for taking high-quality photos, for instance, is seldom best for everyday use, and that distinction isn't always evident. My personal view is: if you're not experiencing issues, do whatever suits you. But a lot of people end up with a "So-and-So recommends it, so if it's not working for me, the problem must be your viewer" mentality, and that's never useful for problem-solving. Settings are not one-size-fits-all. Let's talk about the ones that sometimes bite folks in the tush.

"MeshMaxConcurrentRequests: 128"

Bumping this debug up is, indeed, recommended for helping mesh to appear. However: leaving it at a high number is neither recommended (by us) nor necessary for keeping the mesh rendered. Some people experience higher rates of crashing when this is set to a higher number (over 100 or so). Regardless of whether you're having trouble, though, "requests" refers to how much communication is going on between you and the server, and the more requests are being made, the more it will contribute to sim lag because you're simply giving it more work to do. If there's only one person with their setting this high, the effect will be totally unnoticeable. But if we're talking about 40 people all sending >100 requests to the sim whenever mesh appears, then sad to say, this one will end up contributing to the lag you're all feeling.

So our recommendation is: bump this up when you need to, and return it to default once you can view the mesh (or have determined it's not helping, in which case you'll probably need to relog). We have some additional suggestions about viewing mesh on our wiki. You don't need to be sending that increased number of requests once it's rendered for you anyway -- it's not helping to keep it rendered, only to render it initially.

"RenderVolumeLODFactor: >3"

I have no issue with this recommended minimum, but a max and a couple of caveats need to be included, as well. We don't recommend turning this higher than 4. Although LOD sometimes needs to be raised in order to view sculpts correctly, there are two downsides to increasing it too far. The first, which affects everyone, is that at higher LODs, small prims such as some jewelry will become invisible. They will cease to render to you. Higher isn't better when it comes to LOD; what's best is finding the balance that works for you.

The other factor is performance. Although sometimes notecards packaged with purchases that direct customers to this setting say, "This won't cause lag," that's only partially accurate. It will not contribute to sim/server lag (that is, unlike leaving MeshMax at a high number, a high LOD won't affect other people). However, any setting that increases the amount of detail that you're rendering may affect performance at your end. I'm not saying it will be a big difference. In fact, folks on higher-end machines with great graphics cards and lots of RAM probably won't see a noticeable impact at all. Those of us who slug through SL on low graphics to function will be seeing more of one.

To see if and how it affects you, just go to an area with lots of objects, open up your Stats bar (Ctrl-Shift-1 on all viewers), and keep an eye on FPS. Toggle between a lower LOD, like 2.0, and a higher one, like 4.0, without changing anything else at all. Some people won't see a noticeable change. Others may be surprised by how much of an effect it has. Personally, my FPS changes by about 25-50% between those settings (i.e., if my FPS is 20 at an LOD of 2, I'll usually see it drop to around 10-15 when I turn LOD up to 4, though it depends on how many objects are present). What happens to me is not necessarily what happens to others. In fact, the whole point is that such results are not generalizable. So we prefer to recommend a range of anywhere from 2 to 4 for LOD, rather than any exact number. If you choose to turn it higher than that, simply be aware that if you experience the vanishing miniprim problem, that's what caused it and what you need to revert.

"RenderUnloadedAvatar – Load avatars in your view."

Although we don't have a strong recommended setting for this one, it's important to know what it does and doesn't do. It's strictly an aesthetic preference: Do you prefer to see ruths or do you prefer to see clouds, when avatars are not fully loaded with their own body parts? If you like ruthies, have this set to True. If you like clouds, have it set to False.

If you want to fix the actual problem causing the ruths or clouds, however, you can pretty much ignore this setting.

The issue is bake fail, and our Phoenix page for troubleshooting will apply to most V1s, while our Firestorm page will apply to most V3s.

If you're not planning to fix the bake fail when you see it, you can have RenderUnloaded set however you want, but if you're going to work on it, it's probably best to set it to False. It can sometimes be harder to tell whether a fix worked or not when you're partially rendering the avatar. On the other hand, if you know what to look for, as a student in one of my classes recently pointed out, rendering the unloaded avatar can help you figure out what body part needs to be added or replaced. I've used this setting to do that myself. However, the important thing is realizing that switching this setting on does not, in and of itself, fix any actual issue. The problem will still be there; it'll just look different, and only to the person toggling the setting.

"NoInventoryLibrary"

At first, I was only going to make a quick comment that Firestorm users won't be able to set this to True without doing some finagling with command line parameters outside the viewer. The Library is needed to build the FS Bridge, which is used for script count, radar accuracy at long distances, some aspects of double-click tp in locations with landing points, and a couple of optional things, so it reverts to "False" on relog and, yeah, annoys people who want to get a more accurate inventory count. (The Library currently contains exactly 2210 items, in case anyone was wondering.)

Then I noticed that on the blog post that inspired this one, it is included under "Performance"-related debug settings, so I thought I'd do a bit more rambling.

Inventory size can affect certain aspects of inworld experience, such as login time, and when you do an inventory search or open a new inventory window, having more items in there will cause the search to consume more memory. But it won't affect the factors that we usually refer to as relating to "performance": lag, freezing, and crashing. When you're not interacting with your inventory, it's basically inert, so if you're concerned about performance, hiding your Library probably doesn't belong at the top of your to do list.

As painful as it sometimes is to hear, lowering your graphics settings will make the biggest difference when it comes to improving minute-to-minute performance. Settings like those mentioned earlier. Lower MeshMax may correlate with higher performance. Lower LOD may correlate with higher performance. Even RenderUnloadedAvatar is more likely to affect performance than hiding your Library: a fully rendered (albeit partially loaded) avatar is more demanding to draw, client-side, than a particle cloud, which can itself be made even less demanding by reducing particles to zero and rendering it as an "egg."

So although hiding your Library has some use, it's pretty limited. As a side note, if you ever use Character Test, don't hide your Library, as it will not work if the viewer can't access the Library's Girl Next Door and Boy Next Door avatar parts.

To close, I'm going to acknowledge that the recommendations I give, both personally and on behalf of the Phoenix/Firestorm Support Team, are given primarily with troubleshooting and the prevention of future problems in mind. That may not be everyone's strongest priority. People run on a huge variety of machines in Second Life and they do at least as many different things on the grid. 

All settings changes should be approached as a matter of preference, with both the pros and the cons made as explicit as they can be. What's good for one person's graphics could be crippling for someone else's performance. What I would like to see is not necessarily that recommendations like these not be circulated but that there be more contextualization of them, as well as more of an awareness of how there are drawbacks to nearly any graphics-related settings and how circumstances and needs differ among SL users. I am a fan of experimentation and finding what works best for you, while learning what it is that the different settings are designed for.