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

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

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

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

Pffft. I wish.

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

Yeah…no.

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

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

How It Works

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

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

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

http://jira.phoenixviewer.com/

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

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

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

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

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

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

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

"Connections"

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

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

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

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

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

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

Making it Work for You

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

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

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

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

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

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

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

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

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

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

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

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

Heard That One Before, Part 8: Keeping Small Talk Small

This is the latest in a series of posts concerned with unproductive approaches to getting support from members of the Firestorm Viewer Support team. Today's is about opening lines.  But it's about so much more than that (which is why it ended up kinda long). It's about learning lessons from the introverted that allow us to broaden our perspective on effective communication. If you'd like to start from the beginning of this series, episode #1 is here.

But for now, the next unproductive thing to say when you first try to contact a support person is:

8) "Hi."

Dammit, Jim, I'm a support person, not a dentist.

If you need help from support, please be forthcoming and don't make us pull teeth to try to figure out what's wrong. We don't want to play twenty questions with you, we want to hear what your problem is and give you an answer. We're not identical across the board in terms of how we respond to IMs, however, so let's talk about what you can expect when you contact us.

This is a tricky issue to discuss without coming off as unfriendly, so I'd like to frame it within two particular themes. One is respect for people's time; the other is challenging the dominance of extrovert-oriented approaches in social interactions. Eek, I just got really academic-sounding on that second one. I promise it won't be so painful when I get to it. We'll also talk about the benefits of listening.

Keeping the Small Talk Small

Support team members are Second Life residents. We could be doing anything at all when you IM us: creating content or shopping for it, slexxing with partners or leaving our avies afk. We need to set limits for ourselves in order not to feel as if we are "on call" to the entire metaverse at all times. Each of us does this in different ways.

Some support team members don't respond to unsolicited IMs at all. That's a little extreme for me, but hey, if they need to do that to stay happy doing support, then it's all cool. Others are perfectly ok with small talk and will welcome chat before, during, or after the problem-solving process. 

I fall somewhere in between. I just want to know enough about your issue to know how to approach it before I answer. That means that instead of saying just "Hi" or "Are you there?" or even "Can you help?" I want you to tell me your actual problem. "Friendly" introductions like these place the burden on the support person to try and get you to the point. We won't always have the patience or the time.

The IMs I respond to most promptly are the full-paragraph questions that include lots of information and give me a good idea of whether I'm in for a two-minute or two-hour helping session. (Though of course I still can't answer if I'm afk, in the middle of a class, or hosting a trivia event.)

The trouble here is that when people say nothing but "Hi," they're not generally trying to irritate us. Some of them genuinely believe that a warm and social introduction will be appreciated more than a cold, hard question. And others just don't think of it at all -- they're just checking to make sure we're paying attention.

I have no sympathy for that last one and will always ignore "Lette?" and "Are you there?" The wonderful thing about text conversation is that it doesn't always have to take place in real time. If you ask your (direct and highly detailed) question now, I may answer it hours later, but I'll usually answer it. If you absolutely require an answer ASAP, you're best off asking the support group anyway. There isn't always someone immediately available with an answer, but it's a better bet than asking only one.

As for the "warm and social" type, I do sympathize… but there's another side to that. And this brings me to the second point I mentioned above, the one involving lots of long words.

Social Skills 201: Sometimes Less is More

Even in SL, where perhaps the majority of people I've met consider themselves to be introverts in RL, we (introverts, extroverts, and fence-sitters alike) still run the risk of being misunderstood as unfriendly or antisocial if we're not interested in investing energy in a conversation with someone we hardly know. 

I use the word "energy" on purpose, not because I find you, person reading this right now, personally draining, but because for introverts, social interaction usually means an expenditure of energy, while alone time means recharging. This doesn't mean introverts are all hermits, but it does mean that they're likely to be economical with their social time. If you're IMing an introvert like me for viewer help and start in with pleasantries, you're gonna wear us out before you even get to the hard part.

So how do you know if someone's an introvert or an extrovert before you contact them? You don't, unless there's something in their profile to indicate it. But nor does it matter. This isn't about individual styles, this is about what we can learn from the existence of different individual styles.

Let me put it this way: I don't think I've ever heard anyone say, "I wish these users would engage in more small talk before they got to the point. I mean, is it really so much trouble to say, 'Hi,' 'How are you?' and 'Can you help?' before they ask the actual question?"

My point, to put it directly, is that a lot of our habits and what we think of as "courtesy" come out of a culture where extroversion is the norm. Sometimes those habits aren't always the most appropriate, which means it's worth learning from the introvert's perspective what some of the alternatives are and when it's best to use them.

When it comes to IMing someone out of the blue for something, whether it's viewer help or customer support for a store or looking to buy or rent land, courtesy is less likely to mean leading with a few warmup phrases and more likely to mean respecting the other person's time by being direct and to-the-point.

Finally, let's talk about when the equivalent phenomenon hits the support group. There are some key differences in what we see there.

Attention!

It happens when a user unfamiliar with the group says, "Hello?" … "Anyone there?" And there may be fourteen streams of conversation going on around them. Questions, answers, support people caught up in the rhythm of shooting out info, links, and follow-up questions. The person starts to think that because no one is going out of their way to say, "What is it, User X? What can we do for you?" that it must mean they're being ignored. Ten minutes later, after maybe saying "Hello?" a couple more times, the person finally says passive-aggressively, "Fine, guess no one wants to help me."

Soon as they do that, a few people, usually our more regular users/non-mod helpers, will inevitably point out that the passive-aggressive person still hasn't asked a question, and then it devolves into an antagonistic spat about what the person should or shouldn't have done instead of focusing on what the person's goddamn problem was.

This isn't really a pleasantries thing. It's not really small talk. I think that usually, these poor folks just don't know the norms of our group and think they need to get someone's attention first in order to get their question answered. But what happens after the unanswered hellos is the important thing here.

Some will open with the intro phrases, notice what's going on in the group, and then figure out how it works. Those people will usually realize they just need to ask their question and will do so.

But others, the "Fine, guess no one wants to help me" people, don't catch on. Mostly, it seems they don't catch on because they aren't paying attention to any of the existing discussion. They aren't interested in observing the group's flow of communication; they just want the attention to be turned toward them. Now. Because only when they have the spotlight can their Very Important Question be enunciated.

The moral of this part of the story is: Observe. When you enter any new group or location. You don't have to lurk for days, just a few minutes. Spend more time reading than speaking, and you're likely to find your interactions going a lot more smoothly. In the support context, you'll also get your problems solved more quickly.

This is actually another lesson to be learned from prototypical introversion. Being the loudest might get you what you want eventually, but there are other ways of going about it that don't alienate other people from you before you have the chance to ask the question we want to answer.

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.