Thursday, September 27, 2012

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.

Tuesday, September 18, 2012

Heard That One Before 5: So You Want an Oompa Loompa


This is the latest in a series of posts about common (and not so common) comments that members of the Phoenix Firestorm Support team hear from people who seem to think that such statements will help them in fixing problems. Start here if you'd like to read from the beginning. This one addresses:

5) "I would pay to have this work for me."

Fortunately, I don't actually hear this one a lot, and most of the times I've heard it, it was meant merely as a compliment, as in, "I can't believe this is free!" which of course is totally fine and totally inoffensive. Only occasionally have I heard someone say this in a context that caused me to believe they meant they actually thought that paying for the viewer would bring them better support, and that's where it becomes sticky and not a bit useful.

So let's talk about what the team's volunteer status means and doesn't mean.

It means that when someone is helping you, they're doing it because they want to and not because they're required to for a paycheck. It means they're hopefully not doing it at a time when they'd rather be doing something else. It means we all help in the style we're most comfortable with, and we don't have any arbitrary goals, like having to close X number of tickets or suffer through a nasty day and subject others to our tired, cranky mood for three more hours.

It means the person helping you has their own set of strengths and weaknesses and isn't expected to know everything, but what they know, they know from inworld experience or from helping in support, rather than from working off of an IT checklist that you don't get to see (though they may go through the very same suggestions that are listed in our publicly available wiki).

It also means, however, that you're not going to get your ass kissed. Like, ever. We expect to handle some degree of frustration, aggravation, and even anger. But if you're being abusive, then you can just talk to the autoresponse. Yeah, buh-bye.

It's not just about out-and-out abuse, though. It's about that theme I brought up in the previous point: entitlement. In a consumerist culture, it's taken for granted that if you're the customer, then you're entitled not only to the product you're paying for but to some level of acquiescence on the part of those who represent the company. When people don't receive what they want from a free service like ours, they occasionally seem to conclude that if they were paying for it, they'd suddenly get the response they're used to as paying customers… or in any event feel more justified to complain if they don't.

And so on at least one occasion, the person who said to me, "I would pay for this to work," seemed to be implying that if she were paying our devs, they'd be able to work faster, and if she were paying me, I'd give her answers that presumably I was holding back or that were above my salary (being nil as it is).

Something tells me, as well, she was thinking on a Second Life monetary scale (a few thousand L$ here or there) and not on the scale of offering competitive real life salaries that would entice busy developers to leave stable jobs with benefits. And so, no, paying support or devs or the organization on the whole would not make timeframe miracles happen. It would not entitle you to special treatment or prioritization. And it would not result in the creation of a better product.

The only thing it would do at the users' end is allow a handful of people to feel like they'd deserve to have their asses kissed.

Let's note also how the company we are all subject to -- Linden Lab -- does stratify its users via basic and premium accounts, each with its own allowances and privileges. That's reasonable for a company. But a lot of what the Phoenix Firestorm team does is clean up after the shortcomings of that system. If we were to follow suit, we would merely be replicating that stratification.

As soon as money enters the equation, certain things are likely to become formalized: what that money buys you and what it doesn't, what is expected of those receiving a slice and how much that slice is going to be. Everything that makes our team internally effective -- its flexibility, its ability to retain team members' attention by allowing them to work if and when and on what they want to, its place as a labor of love for most of those involved -- would be compromised by the introduction of a formal financial structure.

Second Life has a thriving freebie culture in conjunction with its culture of entitlement. But offering to pay for something that you know most people will expect for free, far from being a gesture of generosity, can sometimes be just the opposite. It has the potential to feed into the same "I want an oompa loompa and I want it now!" mentality. And so I'm very happy volunteering for an organization that doesn't accept donations, thankyouverymuch.

Enjoy the fact that the viewer and the support for it come totally free of charge to you, but please understand as well that it means we work differently from what you're used to as a customer. Some of those differences may not benefit you, but we hope the majority of them do.

Wednesday, September 5, 2012

Heard That One Before, Part 4: Making the Diva Grade


Welcome to the next in a series of posts on lines we hear all the time in Phoenix/Firestorm support that just aren't as useful as the speakers who speak them seem to expect. In some cases, they actually create hindrances to support. In other cases, like today's, they're mostly just annoying. But they arise from misunderstandings and preconceived notions that are worth addressing.

If you'd like to start from the beginning, head on over hereOtherwise, read on and find out what we have to say when someone tells us:

4) "Fine then, I'll just use a different viewer."

Um, ok. Go right ahead and do that.

Seriously. Neither my lack-of-payrate nor my self-esteem will be bruised if you do.

What are you still doing in my IM window? I thought you were gonna try that other viewer. Go on, shoo. You don't even have to let me know how it goes.

Some people want to believe that Third Party Viewers are in a cutthroat competition with each other and with Linden Lab. Sure, there is some informal sense of competition, but none of us receives any material gain from working on a popular viewer, so the idea that the competition is cutthroat is vaguely laughable. There are times when we tell people to test on different viewers in order to narrow down the possible sources of issues. 

What's more than vaguely laughable is the idea that we'll hear "I'll use a different viewer" as a threat and that it will make a difference in what kind of support we can give to people. That's why this one is in this blog series, you see. Because I'm not talking about people who simply decide to shop around for a new viewer.

I'm talking about those who, in the middle of a frustrating troubleshooting session, get upset about their lack of progress, throw up their hands, and cry, "Fine! I'll just take my business elsewhere!" seemingly expecting their support person to grovel and say, "Oh, I'm sorry, let me pull this über-special fix out of my ass that we only share with people who act like entitled divas! Just please don't leave us!"

If we haven't been able to fix your problem, then telling us you'll use a different viewer is not magically going to make us capable of doing so. Though I'd love to be able to pull fixes -- diva grade or otherwise -- out of my ass, it's just not in my repertoire of Seriously Awesome Talents yet.

In consumer culture, there is a strong mentality of "the customer is always right," which ends up shaping a sense of entitlement. "I'll take my business elsewhere" becomes a code phrase for "You aren't kissing my ass enough." Maybe this is appropriate for the consumerist sphere (barely), but what does it say about everyday culture when it becomes a habit of mind, when folks follow up on kneejerk impulses to play presumed competitors against each other?

I wouldn't do support if I didn't like helping people, and I've helped tons of cool users, but there are also the handful who ruin your day. I have never heard "I'll just use a different viewer" spoken as a threat without breathing a sigh of relief and thinking, "Oh thank goodness I won't have to deal with that one again for a while."

I say "for a while" and not "ever" because this particular type is usually back after experiencing disappointing results on a different viewer (or two, or three) and never stopping to wonder if it's really the viewers that are the problem. In some cases -- when the statement was uttered for purely manipulative purposes -- the speaker never actually bothers to try a different viewer. A month or two later they're simply back with the same complaints or new ones and the same diva expectations.

So if my "job" isn't to keep people using Firestorm, then what is it? In the big sense, it's to improve the user experience. In the smaller sense, it's to do so by helping Firestorm and Phoenix users solve any problems that arise. Simple as that. Since the Phoenix Firestorm Project isn't a for-profit business, and our users aren't customers, you won't find us trying to sell anything to you: neither the viewer nor the privilege of receiving support. Having such a pressure-free support experience should be a plus, right?

We're happy when people use Firestorm. We think it's kinda neat that folks like it as much as we do and have as much of an appreciation for the amazing things our devs have been able to do. We're super-glad to share it, and we'll do what we can to make it work when there's a problem. Moreover, I'd rather know that the viewer is popular because it's good and well-supported than think it's because we felt we had to keep people away from the "competition." So au revoir, enjoy your trip. We'll be here if you decide to come back. And if you don't, we'll even offer you a full refund.

Speaking of which... come back next week for the closely related:
5) "I would pay to have this work for me."