Firestorm meeting 14th September, 2013 – video and transcript

On Saturday 14th September 2013, the Firestorm team hosted another informal question-and-answer session. While the meeting was recorded, the Firestorm team are aware that many of their users have hearing difficulties, and / or prefer to read text. It is because of this that this transcript has been provided. When reading it, please remember:

• This is not a word-for-word transcript of the entire meeting. While all quotes given are as they are spoken in the video, to assist in readability and maintain the flow of conversation, not all asides, jokes, interruptions, etc., have been included in the text presented here
• If there are any sizeable gaps in comments from a speaker which resulted from asides, questions to other etc,, these are indicated by the use of “…”
• Timestamps are provided as guidance should anyone wish to hear the comments in full from any speaker on the video
• Questions were asked in chat while speakers were talking. This inevitably meant that replies to questions would lag well behind when they were originally asked. Therefore, to provide context between questions and answers, questions in the transcript are time stamped at the point at which each is addressed by a member of the Firestorm team
• Some questions were asked and answered purely in text. These have been excluded for one of two reasons. Either a) they lacked context with the voice conversation, or b) the seating arrangements in the auditorium meant there were some questions or answers which didn’t appear in my local chat window.

Please note: This transcript is provided for informational purposes only. As such, questions on technical issues relating to Firestorm and  / or project-specific questions cannot be answered here unless one of the Firestorm team drops by.

Video courtesy of Northspring

0:00:15 Ed Merryman (EM): First I want to thank you all for coming out. It’s very encouraging to see this many people come out just to hear us babble and ask questions of us. I want to thanks the devs who have come out and all the support people who have come out. We’ll see how much fun we have here …

0:01:11 EM: Anyhow, there’s a couple of things I want to bring up here … I want to talk about sane settings for Second Life.

0:01:35 EM: Most of you are on the Firestorm support groups of one language or another; I’m sure you see lots of questions in there, and a lot of times people get asked “what’s your bandwidth set to? What’s your draw distance set to?” when they’re having issues. They get told to turn it down and their problems go away. Have you noticed that folks?

0:02:04 EM: Second Life is not static. It’s not like any other game. It’s not like an MMO. It’s very data intensive. There’s a lot of data going both ways, from the service to you and … the thing is, most people don’t realise the impact your settings have not only on your performance but [also] on the service in some cases as well. So lower, in most cases, is generally better. OK, I want to make this perfectly clear: lower is generally better.  with one exception; that’s your cache size.

0:03:11 Jessica Lyon (JL): But wait, because I had an e-mail from a user the other day who said that she has this brand-new computer with a ten zillion terabyte hard drive and a billion gigs of RAM and she turns all the settings, everything on the viewer up to full – and crashes, and she shouldn’t.

0:03:33 EM: Well, yeah, I know. I’ll tell you, I worked with a gentleman from England a while back who basically built himself a super computer for Second Life. Seriously. He spent a lot of money; over five thousand pounds he spent on this computer. He showed me the specs on it, and trust me, he had five times the computer he needed for Second Life. Problem was, he was having an issue when he was logging-in. The problem wasn’t his computer; the problem was his Internet and the amount of data coming in on his log-in was the problem. He had his draw distance ramped up to something like 700 metres. But he was having this problem on log-in. I got him to drop his draw distance down to 128 metres and relog, and the problem went away. Because he wasn’t trying to pull so much information all at once.

0:05:02 EM: And when you log in, and when you TP into a new region, that’s when you get hit with the most amount of bandwidth being used. So keep your bandwidth on the low side. You’ve seen our wiki page? We recommend maximums of 500 for any sort of wireless, a thousand for hard-wired DSL, 1500 for anything faster, again hardwired. Did you note that one word, though? “Maximums”? I don’t run at the maximum; I’ve got a great Internet connection. I get 25 megs down and 5.5 to 6 up to the Dallas servers when I do a speed test. Doing the calculations I should be able to run at 1500; mine’s at a thousand or less.

0:06:08 EM: So keep your bandwidth down; keep your draw distance down. It doesn’t mean it has to stay there. You can put your draw distance up when you need to; but adapt your graphics settings to what you’re doing. Please. Let’s think about some sanity.

0:06:47 Lette Ponnier (LP):  I usually refer to it as being a computer whisperer. In other words, rather than telling your computer what you think it’s supposed to do, you should be listening to your computer tell you what it is capable of doing … Also not to be surprised when a certain viewer or even a certain version of the same viewer doesn’t work for you the same way as a previous one. They’re not identical; you can’t force them to be identical; you can’t sit there using different viewers and say, “why aren’t you working for me the exact same way” when they’re not the same viewer or not the same version.

0:07:47 Comment from Knotso Slippery: Trouble is, my computer is female, and keeps changing her mind 🙂

0:07:54 LP: Well that’s exactly why it’s important to become familiar with how different settings and how different behaviours can be changed. One issue is that a lot of people think that there is going to be one specific set of ideal settings that they’ll just set, and they’ll never, ever have to change them again. Some people with completely awesome computers can do that, but the vast majority of us in the middle, that’s not practical and it’s not making the best use of wither your computer or your viewer. Most people are going to find that if you adapt your settings according to your needs, then you’re going to have a much happier time

0:09:04 LP: It’s that the more that you know about the individual settings, the more capable you’re going to be with doing that, as opposed to looking at them and going, “Oh my goodness, I have no idea what you’re doing!”

0:09:20 JL: So remarkably, considering I really suck at support, I get a lot of e-mail from people asking me to help them with their computer or with the viewer, that they need support. And something I frequently see, and I’m sure support see it all the time, is “yesterday the viewer was fine, and today the viewer’s not behaving properly. so there must be something wrong with the viewer.”

0:09:47 JL: I think more often than not, the viewer hasn’t changed. In fact, we don’t have any capability of changing the viewer remotely. We can’t change anything. So if the viewer is working one day and then something’s wrong the next day, you should probably consider what has changed on your computer during that time. Have you changed the settings, have you installed some other program, have you uninstalled a program, have you made any kind of change at all to your system, because generally speaking if it works one day but not the next, it’s not the viewer that’s changed, it’s something else.

0:10:54 EM: That’s going to lead-in to something else I wanted to talk about, and that’s classes. I see a lot of names that I recognise from our classes. Has anybody here not come out to some of our classes? For those of you who have not come out to our classes, I want to highly recommend them. for those of you who have come out to our classes, do us a favour – keep coming out to our classes and encourage others to come out to our classes.

0:11:43 EM: Now that said, we had an internal discussion the other day, and Lette had a wonderful thought, and I sort-of stole it; well I borrowed it. If you are only going to get somebody to only come out to a certain number of classes, what classes are the ones that would have the most impact for you as a user.

Responses to this focus on lag and preferences.

 0:12:33 EM: Well, there’s four preferences classes; we’re trying to limit this, and we tried to limit it to just three or four, and now the list is up to five … so now I think we’ve gotten to a point where we have roughly five classes that we would recommend as the classes that everyone in Second Life should attend. The ones that Lette proposed, to start with, Preferences-2 being one of the most important classes that we actually give. That’s the one that covers your graphics settings and your network & cache tab, which covers your bandwidth and your cache. A lot of people walk away from that particular class with a new respect for some of what this stuff does and a much better understanding of how to reduce the effects of lag.

0:14:58 EM: Our Quick Prefs and Lag class is a good one. You all know lag is very misunderstood … reporting bugs and requesting features is big, because it explains the JIRA to you and how to request things. Out JIRA is very important. And the troubleshooting class; our basic troubleshooting class. It’s got a little bit of insight into how a couple of things work, like we do talk a little bit about the statistics bar and what to look for in there as far as when you’re troubleshooting. We give you ideas on how to try to figure out where your problems are coming from.

0:17:02 LP: So this works kind-of like a preview to the blog post that I’ve been writing on this and it just needs some illustration. I just need to take some relevant snapshots for it and it’ll be ready. But the way I’ve organised it is actually to introduce Prefs-2 and then basic troubleshooting and then reporting bugs, and I think of it this way: Prefs-2’s theme is “prevention is the best cure”, because if you know how best to set your settings, especially in those critical tabs of graphics and network & cache, then you are less likely to have issues to begin with.

0:17:46 LP: The second section on basic troubleshooting I sort-of dubbed “home remedies”. This is knowing how to fix yourself if the fix is within your power; and even just the process of troubleshooting will let you narrow down the problems so that you can determine whether it’s the viewer or not. In most cases it isn’t, and that’s actually something you want to be the case, because if the problem is the viewer, then sorry, it’s not going to be fixed until the next version at a minimum. Whereas if it’s a problem at your end, it can be fixed right away, most likely. All you need to do is figure out what it is.

0:18:2 LP: And third comes RBRF [reporting bugs and requesting features] because that’s sort-of your last resort; to report it as a bug. But a lot of people don’t want to do that for one reason or another, and our class on that will work through the most common reasons people have to not want to use the JIRA because it look to intimidating, they think it doesn’t work  – well it works a lot better than not reporting a bug at all, I’ll tell you that – or you’re just not familiar with the process. So I sort-of called that section “by prescription only”.

0:19:02 LP: And then finally I did tag lag on at the end as a bonus to the big three, as it’s a mini-class, but it is important.

0:19:15 Tonya Souther (TS): Let me jump in here and talk for a moment about reporting bugs, because there are people out there who just absolutely will not, for whatever reason, go to the JIRA and report a genuine bug. I’ll get people who contact me directly despite the auto-reply which says if you’re having problems, ask the support people, as they know more about it than I do, I’m just a developer. But people will get with me and I’ll trying to help them through, and half the time I have to go to the support folks and ask them “OK. what’s going on with this?” But if it turns out to be a genuine bug, then I will ask them to file a JIRA; and some folks just adamantly refuse to do that. I don’t get it myself, because I’ve got lots of things going on, not just with Firestorm but with real life work and everything else, so if you tell me about a bug, well OK, I may notice it, I may take a look at it, but something else will come along and I’ll forget about it. If you file the bug on the JIRA, then it doesn’t fall through the cracks. We may not actually do anything with it for a while, and that’s a common complaint, but it does not get ignored. If you just tell me about it, I’ll probably forget about it, and it’s lost and somebody has to put up with it for another six months until somebody else reports it. So people need to file bugs; without that, there’s no guarantee it’ll get fixed.

0:21:33 EM: It comes right back down to this. People know all sorts of things in Second Life; 90% of that is wrong. 90% of what people in Second Life know is wrong. How many of you for years thought that clearing your cache would make your lag go away? My hand’s up, I thought it, because I’d been told by people who’d been around for a while. Thus, we do our classes. We’re trying to give you the best information we can; we’re trying to change the way people in Second Life think and act, and hopefully improve everybody’s SL.

0:22:31 Comment from Neal Hernandoz: Yeah, but clearing cache can clear certain issues though, can’t it?

0:22:39 EM: As far as fixing issues, it can fix texture issues and it can fix inventory-related issues. There are some other minor things that it can fix as well. but for the most part, they’re the only two things that it really fixes. It’s not going to make your lag go away. It’s not going to help you teleport. It’s not going to help Voice.

0:23:22 LP: Trying to get cache cleared to fix an issue that is unrelated to cache is like taking your car to get an oil change because you think that’s a good way to fix your flat tyre. If the cache has nothing to do with what the problem is, then clearing it is going to do what? So learning what the cache is, what it actually does, what’s saved in there and what isn’t, makes that whole when to clear cache and when not to clear cache thing make a whole lot more sense.

0:24:01 LP: And since Ed didn’t mention it, don’t clear it for maintenance purposes either.  It’s not going to make any difference if you’re not having a problem. So, you’ve got a bag of trash in your kitchen and then you’ve got a bag of groceries you’ve just brought home. If the stuff in the bag of trash is obviously trash, you’re going to need to clear it; it’s just stinking up your kitchen. But clearing your cache when there isn’t a problem is like taking that big bag of groceries you just brought home, and throwing that out instead. I mean yes, it is possible that eventually something in that bag is going to go bad, but it hasn’t yet, so why would you just junk it?

0:25:38 LP: Under normal circumstances, there is no reason to clear cache. Cache should be cleared under the following circumstances only:

• When you are doing a clean install
• When you have a texture problem you can’t clear any other way
• When you have an inventory problem that you can’t fix any other way.

Other than that, it’s best just to leave your cache alone.

0:26:00 TS: And a texture problem you can’t fix any other way used to involve bake fail. But with server-side appearance, even that doesn’t do it anymore.

0:26:30 LP: Cache is self-purging. So some folks have made the assumption that if you let your cache fill up then it gets to a point where you’re just storing useless stuff in there, and for that reason you should be clearing it because you can’t cache the stuff that’s important right now. That’s incorrect, because when your cache does fill-up, then when you come in contact with a new texture or something else that needs to be cached, it will cache it and it will purge whatever is the last thing in there which has not been used, that has not been needed to be accessed. So a full cache is a happy cache.

0:27:23 comment from Mollie Tison: Ed has always taught us the first line of action is to relog to any problem.

0:27:24: EM: Almost any issue. Unless you know what the actual issue is, for example you’ve logged in and you know that you have to change this setting in order for that to work. You log-in and something strange happens, re-log and see if it goes away. Re-log on a different region. A re-log fixes so many things.

0:28:05 Question in voice from Sweetcheeks54 Timeless: I’ve had a problem where every so often I keep getting this error when I log-in that voice has been totally disconnected from all areas. Is that normal?

0:28:15 EM: That depends on whether the voice servers are having maintenance or they’re broken at the moment, which has happened three times in the past two weeks. I think they’ve been doing maintenance or down three times in the past two weeks.

0:28:22 Comment in voice from Sweetcheeks54 Timeless: Because I’ve got my bandwidths are good, because they’re for the broadband; I keep it right around 1100, but other than that, I get that error, but if I re-log, it goes away, and I get my Voice back.

0:28:48 EM: In that case  don’t worry about it, that’s a Vivox error. Voice has very little to do with the viewer itself. Really, very little.

0:29:17 EM: So you all get the idea that we want people to come out to our classes and tell your friends – tell you enemies – bring as many people out to our classes as you can.

0:29:38 Question from Knotso Slippery: Just on voice. Is there a way of normalising voice volume?

0:29:39 EM: Not simply. You can adjust your input at your end, or your output at your end, your mic volume, both on your computer and in the viewer and you can adjust other people’s volumes to a degree in the active speakers. That’s about it. Normalising it? No, not going to happen., not unless Vivox does something.

0:30:10 Comment from Knotso Slippery: I mean sound, is there something other than avi or cam position?

0:30:20 JL: I think what Knotso’s talking about is the fall-off, depending on whether you have it set from your avatar’s position or your camera position. And there was some efforts made to normalise that by us, but also some other third-party viewer projects have made efforts to make it possible to normalise that sound so that you don’t get that fall-off when you move your camera around, for example. And there’s a lot of good use cases for that, like classes; when you’re in a classroom environment and you have different people speaking, depending on your position to that speaker will alter the volume. and we’ve also looked into making it so that you can have Voice be the same volume, say, within 40 metres, or say 50 metres. But you can’t really do it region-wide as then it’s going to affect people on other regions. I really can’t remember what the outcome of that was. I can’t remember if that was through Vivox or Mumble, which is frequently used on OpenSim. Mumble is an open-source application for transmitting voice; it’s like an alternative to Vivox. There were efforts made, and I don’t think there were any successes.

0:33:58 comment from Softpurrs Moriguchi: You said five classes, no? I’ve only got: Preferences 2, Lag, Reporting Bugs & Requesting Features, Basic Troubleshooting.

0:32:05 EM: That’s four classes. The other one, my personal one, my number 5, would be the introduction to Firestorm in the wiki. Which is perfect timing for that question, because it leads into something I did want to talk about. And that’s how to get help.

0:32:34: EM: You all know we’ve got a wiki. How many of you actually use it on a regular basis? I can tell you right now, everybody on the support team is going to say, “I do!”.  We use it as a resource.

0:33:04 TS: Most of the time when I ask questions of the support team, they send me a link to the wiki.

0:33:19 EM: People complain all the time, “why do you send me to a wiki link? Why couldn’t you just explain it?” Have you looked at some of those pages? … However, that’s not the big thing that I wanted to talk about.

0:34:16 EM: You all watch the support group, right? How many times have you seen this scenario: user X says, “hi!”, user Y says, “hello”; user X says, “is there anybody here?”; user Y says, “no, we all left!”; user X comes back with, “I have a problem”, user Y says, “We’ve all got problems, now you want us to deal with yours?” User X finally says, “I have a problem with voice.” You still don’t know what the problem is. You’ve gone on for four minutes, with chat lag maybe longer, and you still haven’t found out what the problem is … I want to encourage people politely to try to put everything into one simple little sentence. If you want help and you’re asking in the group, try to get it all in one short little paragraph … try to get it in as short, as concise yet clear, sentence as possible.

0:36:37 EM: I also want to talk about our JIRA. we have people who file JIRAs, we give them suggestions and they never let us know whether it’s helped or not. Or we ask for more information and we never hear back. So if you file a JIRA, please respond to it, keep up with it.

0:37:05 EM: And lastly, you all know we have open Q&A sessions after our classes; those of you who have been out to our classes have seen us deal with support issues  after the class.

0:38:44 comment from Knotso Slippery: To be fair, it’s hard to be critical of first time help group users.

0:38:45 LP: Knotso makes a good point, actually, because the first time you’re in a group, you don’t always know exactly how things work in the group. However, if you’ve been on the Internet for more than a couple of years you learn that it usually behoves you to lurk before you start to participate. Now I know that’s difficult when the context is a help group which you only joined because you need help, but sometimes we get the “hi” thing from people who have asked for help in there before, and hopefully at least some people are going to be lurking for at least a little while before they ask their question in there. So yes, you’re correct, but there’s a point where you’ve got to get rid of the introductory stuff and just get to your point and, trust us, someone will probably come to your aid.

0:40:20 Comment from Knotso Slippery: Just as annoying as the multiple “hi’s” are the multiple answers from the staff

0:40:28 LP: This one I need to respond to, because we’re actually instructed and instruct the support staff that it’s better to have four people answering the same thing at once than for nobody to answer it at all.  That’s something that Ed has been teaching us from the very moment we land on the team. It may be annoying on some level, but it’s at least productive … Now there are the kind of multiple answers where sometimes you’ll see one person getting answers from half-a-dozen people and another person who’s question seems to have gone unnoticed. And of course, that’s not a good thing and that’s something we all need to be aware of when it does happen.

0:41:32 LP: There are certain questions that we all enjoy answering, such as that one about clearing cache. Everyone has an answer for that one, and certainly there’s the potential to distract from other questions going on at that point in time, but that is something for us to be aware of; it’s not something we do on purpose. But if the complaint is well, one person asks and five people answer, that’s not something we’re going to be concerned about.

0:42:12 TS (in chat): The simple fact that we don’t know if anyone else is typing…

0:42:13 EM: I just want to add to that about the multiple answers to the same question. You know what our support team actually is, right? We’re a department of redundancy. That’s what we do, we repeat ourselves all the time. Lette told you the truth; I’ve told people right from day one, “I’d rather see six of you respond to the same question than nobody.” … I’ve seen a couple of occasions where multiple answers went out, where I have typed-in an answer as well. mine never went through, there were three answers to the initial question; by the time mine actually went through, the same question had been asked again so when mine did go through, it looked like it was totally separate.

0:44:02 Comment from Sweetcheeks54 Timeless: I’ve seen times when even non-support helps people.

0:44:20 LP: We love it when non-support helps, it gives us less work to do! No, we like it when non-support helps because that’s how all of us ended up here ourselves; by helping-out in the group, and sometimes folks fill in the gaps. You should never feel concerned about doing it. There’s someone usually half-paying attention to the group, even if they’re not actively answering questions. If I’m on-line I almost always have the group open, even if I’m only active in it probably about 5% of the time. But I will keep an eye on what is going on and if I see somebody answer wrongly, I will jump-in. And I’m sure everybody else on the team will do the same thing.  So as long as you’re answering correctly, we’re just going to let you go ahead and do so, because you’re awesome!

045:42 EM: One question I absolutely hate to see in the group is, “Is there a mod here I can talk to”?

0:45:48 LP: Or even, “Can a mod IM me?” If the question is sensitive in nature, like your private bits went missing or something, then asking for somebody to IM you directly may be appropriate, but most cases it’s going to be a lot more productive to ask the question in the chat itself because we all have different specialties.  We all have things we’re stronger to answer than others, and we’re going to be a little tentative about initiating an IM when we have no idea about what the question is going to be. So just ask it in the main group first, and you cast a much broader net that way. You’re more likely to be helped by the person who is best to help you.

0:49:59 JL: I want to talk a little bit about viewer wars. In the coming week I’ve going to be doing more talk about viewer wars and how much I wish they would end. So for example: Firestorm is better than Singularity;  Exodus is better than Firestorm; my viewer is better than your viewer. Can we stop doing that please? Because no viewer is any better than any other viewer. I can’t say Firestorm is any better than any other viewer. For me Firestorm is better than any other viewer, for me. , But that’s because Firestorm provides the needs that I like and I prefer this viewer. And the fact that I prefer this viewer makes it my opinion, and makes it subjective and therefore Firestorm can’t be better than any other viewer for anybody else. I can’t say to you that Singularity will be better for you than Firestorm would be; you have to try it.

0:51:08 JL: Early-on, when we started this project, we made some efforts to build some cooperation between the third-party viewers because really, all the third-party viewers are developing for the same goal, I think. Which is to improve the user experience; and I have to say that Linden Lab is as well. So in the same way that we’ve tried very hard to work with Linden Lab and we’ve made some improvements and we’ve made some headway there, and materials which is actually out and will be out in Firestorm soon, is an example of collaborating between third-party viewers and Linden Lab, and is an example of how much more you can accomplish when you cooperate.

0:51:54 JL: So early-on we tried forming a mailing list with the other third-party viewers and we made so efforts to try to bring us together. We may disagree with our way of doing things – and be “we” I mean the third-party viewers may disagree with each other. we may have differing opinions, we may disagree with how to improve the user experience; we all have our own opinions on how best to do that. Our viewers all have different niches. Firestorm is basically a who lot of everything. Singularity’s niche is viewer 1-style interface and design. Catznip viewer kind-of caters to the Linden viewer user who wants a little bit more but not a whole lot; Exodus’ niche is combat.

0:52:56 JL: So we all have our own niches, and that’s good, because that provides options for everybody. Because there may be people, for example, who do combat in Second Life and in that case, Exodus might be the best viewer for them. There are certainly a lot of people who prefer the V1 interface, and singularity might be the viewer for them. But who would I be to tell somebody that this viewer is better than that viewer.

0:53:29 JL: What that does is it creates an atmosphere of competition amongst the users which then bleeds into the developers and the viewer projects themselves. Because we see our viewers being really patriotic about our viewer and that makes us feel good, I can’t lie. It makes us thing we must be doing something right. But it also breeds an atmosphere of competition amongst the third-party viewers.

0:53:58 JL: So initially, we started trying to build this cooperation between the viewers, and it didn’t go very well as far as the third-party viewer cooperation is concerned.  And so in hindsight I’m thinking maybe we started on the wrong end of things. Maybe where we need to start is from the user end of things. We need to start with you guys. We need to eliminate the whole competition, the this viewer is better than the other viewer deal among the users first, and then maybe that atmosphere will bleed into the viewer project developers themselves.

0:54:41 JL: So in the next coming weeks I’ll be posting a blog post talking a little bit about what I’ve just said, and making so efforts to re-establish cooperation amongst third-party viewers. Singularity, specifically Latif and I, have been talking and Cinder, at this OpenSim conference last weekend, and we were talking about how much more we could accomplish for you, the users, how much more we could accomplish if we cooperated a little bit better. But it’s difficult to cooperate when we have our users, our own users saying this viewer is better than that viewer.

0:55:29 JL: For you guys, all you guys in the audience, if you see somebody saying this viewer is better than that viewer, I would like for you to – don’t become confrontational, that’s what we’re trying to avoid – but just maybe point out that it’s subjective.  It’s much better to suggest, “why don’t you try this viewer and that viewer? They’re all up on the third-party viewer directory. Give them a try, and then you can decide which one you like. which one is best for you”.

0:56:07 EM: I just want to add to that Jess did make the point that we’ve been doing this for quite some time. We started talking about this amongst ourselves, about cooperation between the different third-party viewer developers back when we first started the project. Over three years ago. That’ how long we have been working at this. Even before then, I believe back in the Emerald days, there was some talk about it.

0:56:42 JL: It never got anywhere because there is still this atmosphere – let’s use another example: how many of you remember when Linden Lab killed viewer tags?  Remember we used to be able to have our viewer name up above our names ? … Anyway, Linden Lab killed that and one of their reasons for killing that was that they had said … Phoenix users are griefing and trolling user of other viewer including the Linden viewer and causing drama. And I called BS on it. I didn’t believe that. And so I went undercover, I created an alt, and started going into groups and started going around on the Linden viewer, so it showed-up “Viewer 2” on my tag. and I actually had people IM’ing me out of nowhere, out of the blue, telling me how stupid I was to be on that viewer and I should be on the Phoenix viewer, because it’s the best viewer there is. And that made me very sad. Because first of all it demonstrated that in fact that kind of thing goes on, and it goes on in the user level of things.

0:58:15 JL: So while here we are, trying to build cooperation, here I see our own users … perhaps because there were more Phoenix users than any other, but it seemed Phoenix users were the worst about being so patriotic about the viewer, and we appreciate patriotism, I appreciate that you love the viewer, because that tells me that we’re doing something right. But don’t enforce that view on people. You can spread your opinion; be sure that when you say “Firestorm is the best viewer for me”, you say “it’s the best viewer for me, and that’s my opinion, and it’s not necessarily the best for you”.

0:59:36 EM: You know, Firestorm is not for everybody. It really isn’t. No single viewer is for everybody. We’ve all got our own tastes. Some people prefer simple. Some people prefer the v1- interface … We’ve all got different tastes, we all use the viewer differently in Second Life. Let’s be more cooperative. If we all cooperate with each other, we can all make Second Life a much more pleasant place for us all.

1:00:30 TS:  Part of the disagreement that we have as a team with some of the other viewers is about how they go about developing the viewer. That’s very much under the covers, though. That has nothing to do with how good the viewer is for the users; how good a user experience it provides, how it might fit a particular user’s needs. I’ve been accused of wishing other viewers would go away, and that’s not so. As far as I’m concerned, if Singularity does the job for you better than Firestorm, use it. Have fun, go forth and sin no more with my blessings! It’s great. There’s lots of choices out there, and choices are good. Two-thirds of Firestorm is about choices, so choices about viewers is good to …

1:02:10 EM: And from a support perspective, you’ve all seen it, when somebody comes into the group saying, “can somebody tell me how to do this on Singularity?” Well, if it is something that is standard, I’ll answer them; but if they are asking about a specific preference in Singularity that I know nothing about, because I don’t use it … I can’t help … but that doesn’t mean I think they are a bad viewer.

1:03:02 Comment in chat: I have bashed the Linden viewer. I think most of us have.

1:03:03 JL: I think we’ve all at some point or another bashed another viewer, and I’m sure I’m guilty of it to, although I make a conscious effort not to. I’ve been accused of not specifically naming viewer in blog posts, and what I’ll often do instead is I’ll just say, “there’s a list of third-party viewers on the Linden Lab third-party viewer list”. And I’ve been bashed for not specifically saying, “why don’t you try Singularity” or “why don’t you try Exodus” or “why don’t you try this or that viewer”. And the reason I won’t specifically name them in a blog post is because I’m responsible for this project, I’m responsible for this viewer, I can’t be responsible for the others. It doesn’t mean I don’t trust them, it doesn’t mean they’re not good. It just means I don’t want to promote them as safe viewers – call it the whole Emerald thing. I’m paranoid. But there are viewers on the third-party viewer directory. I’ll say in a chat or where we are right now, “Why don’t you try Singularity?”

1:04:16 JL: We get people saying, “Can you make a ‘lite’ version of  Firestorm? ‘Firestorm lite’?” No, because that’s the total opposite of what our objective is with Firestorm. And what would be ‘Firestorm lite’ for you would be different for ‘Firestorm lite’ for somebody else. Because if we make Firestorm “lite”, it has just the options that you want, just the features that you use. But the person next to you has a completely different list of features that they want. So we can’t really do ‘Firestorm lite’. But there are other viewers that are ‘lite’.

1:04:53 JL: We get people complaining about our vintage Phoenix skin in Firestorm isn’t quite the same as V1. Well, try Singularity. Try Cool VL viewer. They have the V1 interface, as close as it can possibly be to a V1 interface. Give it a try; it might be better for you.

1:05:16 JL: I just want to start fostering an atmosphere within our users of not competing with other users in regards to what viewer they are using.

1:05:38: Comment from Knotso Slippery: The other day someone asked a question in help and they were on a mobile device. the staff got their nose out of joint and the answer they got was specifically, hey, you’re on a mobile and not on Firestorm, and this is a Firestorm help group.

1:05:52 EM: Two comments about that. One is, how the hell am I going to help you on a viewer that I don’t know. Two is, we are [the Firestorm support group]. How many times have you seen questions get missed because somebody’s talking about this or that or the other thing?

1:06:18 Comment from Knotso Slippery: The question was just about the sound servers being down or not.

1:06:50 TS in chat: But that said, perhaps we could be a bit gentler about it …

1:06:51 EM: Perhaps we could, Tonya. The thing is, though, it’s really hard to be gentle why you have just asked the same question sixty-five times in the past hour and a half. Voice was down. You remember when voice was down? How many times did you see, “Is anybody else having a problem with voice?” How many times did you see that? Hundreds and hundreds of times in the space of an hour or two. So do you understand the frustration level that we get? I’m not using it as an excuse, I’m using it as “this is why it happens” … I’m not saying it’s right.

1:08:30 comment from Lily Densmith: Someone who has just logged-in with a problem may not know that a particular question has been asked multiple times already.

1:08:32 EM: We have weekly support meetings, and I say this every week. I’m sure some of the support staff are tired of me saying it, but I’m going to continue to say it every week. If you start to get frustrated, if you start to see yourself snapping at users or anything like that – walk away. Take a break; you’re not in the right frame of mind any more. If you continue to answer when you’re frustrated, you’re just going to get more frustrated, you’re going to wind-up burning out and we’re going to lose you. And we spend a lot of time picking these people to do support. We don’t pick people up at the drop of a hat. We’ve watched people for six months before we’ve asked them onto the support team. There are very valid reasons for everyone on our support team being there.

1:09:39 EM: However, the thing is you get frustrated, you just want to respond. You need to get it out. And that happens. And generally after there’s a blow-up like that, you’re going to notice there are a lot fewer support staff hanging around.

1:10:18 Comment from 55aaa Danick [in response to Jessica’s mention of Emerald]: Think Emerald made us all paranoid.

1:10:20 EM: Old story. Do  you know how many people on our team were actually on Emerald? On the Emerald team?

[replies vary from “lots” to “all of them”]

1:10:33 EM: Actually not. No.

1:10:36 JL: Quite the opposite.

1:10:40 EM: Less than a dozen – that’s developers and support – were involved with Emerald at all.

1:10:50 TS: An I think there are what? Two, three developers? Jess and I are the only two members of the Firestorm team who were members of the Emerald team when it imploded. And I had been a member of the Emerald team for exactly four days.

1:11:23 EM: I’ll be blunt about this. When the crap went down with Emerald, three people up on this stage were very unhappy about what was going down. And a certain person with ears and a tail had had mentioned they were considering doing a fork because they felt bad for all of the users who were going to be out of a viewer when Emerald got banned.

1:11:58 EM: Two other people on this stage encouraged Jess to do this …

1:12:12 TS: Encouraged? The proper verb to use, Ed, is “arm-twist”!

1:12:22 EM: Tonya and I were twisting Jess’s arm and tail and various other parts of her anatomy to actually start the team up. And it was just actually over 48 hours of hard work by our initial developers before we were actually ready to release Phoenix – but that was just a straight fork from Emerald with ripping out a bunch of stuff and making sure everything was clean.

1:13:00 JL: So we still unfortunately live with that stigma despite the fact there’s actually very few of us who were involved. In fact, when Emerald started to explode … a lot of the Emerald developers were gradually starting to say, “You know what? Eff this, I’m out of here,” And they’re gone, and they left.

1:13:31 JL: But when things blew up, they were still considered to have been on the team and had been a part of it. There were very few of us who did remain on the team in the hopes that we could save things. I kind-of hoped that I could save the viewer despite everything that was going on. And when that became clear, I got locked-out of everything and it became clear that the only way that we were going to be able to save the viewer was to create a fork of the viewer, and we decided to create Phoenix.

1:14:04 JL: And the reason for that is because I thought it was absolutely devastating that a couple of arseholes could ruin it for a lot of people. There were going to be a lot of people. There was going to be a lot of people who didn’t really have a decent alternative, aside from the Linden viewer 2.0, to switch to at that time. And so I decided we would fork and we would create a new viewer and we would call it Phoenix, and then I started thinking, “Oh my gosh, it’s going to be a lot of work!” and “I’m not so sure now that I want to take this on”. And then Tonya and Ed basically egged me, “You can do you, you’ll be fine; we can do you. You have to do it for the users”; and so we did. And here we are now.

1:14:52 JL: And a lot of the people that I pulled-in to this team were people who left Emerald before the final blow-up because they didn’t want their names tarnished. None of us did. Very few of us knew anything about what was going on.

1:15:11 TS: And in fact I had joined the Emerald team after the initial revelations, after the DDoS, after the steganographic user information hiding both in the belief that with all the bad stuff out, nobody would try anything and Linden Lab had set forth conditions that would restore everybody’s trust in the team, and Phox shot it in the head. Everybody else was going to do what the Lab insisted on, and Phox said, “No, I’m not leaving.”

1:15:50 TS: I don’t know if many of you are familiar with the song from Megaherz, Kopfschuss [“Headshot”], but one of the lines from the chorus, “Wie Phönix aus der Asche / Werd’ ich auferstehn!”, but that line, “Like a phoenix from the ashes / I’ll rise!” was the topic of the developer chat for months. So I knew when it came time to do this, that we were going to have to fight, that we were going to have to fork Emerald into a new viewer, we were going to have to do a lot of work regaining users’ trust. and for quite a long while there were quite a lot of people that wouldn’t have anything to do with us. Not because of anything we did, but because we had been tainted by association with Emerald. That annoyed me, but I’m happy to say the last vestiges of that have disappeared. We’ve done a lot of work, we’ve been very transparent specifically to help users regain their trust in the team and what we can do.

1:17:18 Question from Pieter Sayes: Why did Phoenix become Firestorm?

1:17:20 EM:  Basically, it was this. Phoenix was based on the V1-code. V2 was out at the time our developers realised in time we’d have to move to the V2 code base in order to keep up with things coming from Second Life, from Linden Lab. And why two names? Well, because we still had the Phoenix viewer when we brought out or V2 one, which is Firestorm, and that’s why the name change.

1:18:04 JL: So the Phoenix breathes fire, so the idea was that from the ashes came the Phoenix and from the Phoenix  came the Firestorm, and so that was the transition in viewer names.

1:18:26 Comment returning to the topic of support from Greatfox Snowpaw, relating to support volunteers and questions going unanswered: Six of them sitting in the group doing nothing. I’ve seen that a few times … I was just saying I saw it, that’s all.

1:18:45 JL: Just because they are there doesn’t mean that a) they’re paying attention, they could be doing other things. They could be, and most often are, actually in IMs … I’m not shooting down your subject, in fact I’m glad you brought it up…

1:19:11 JL: Quite often when I log in, I get all these windows open-up and they’re all support chat windows, mostly; I get a lot of IM windows from users as well. But I get the Spanish support group pop up, the English support group, the French support group, all these different support groups. And those will show me in the group. I can assure you I do not speak Russian, I do not speak German, I’m not able to pay attention to what those are and quite often I’ll try to close them when I can. But most of the other times I’ve got like a billion other IMs as well, so i work through them in progression. So it’ll show me in those groups, but I’m not really able to watch those groups. And that happens to support people as well.

1:19:59 JL: Lette for example, does trivia things. Like we do classes, she does trivia things. That group may be open for her and may show that she is in it, but it doesn’t mean that she’s watching it … There’s no rule that we have that says, “If you’re on-line you have to provide support.” Quite the opposite. We tell our support people, “If you don’t feel like doing support, don’t do support; if you’re not in the right frame of mind, don’t do it.”  Sometimes it’s very difficult to know if we’re in the right frame of mind; sometimes support people will be very snappy. I am very guilty of having been very snappy to people, and I don’t even realise until after I’ve done it. Then I realise, “Oh wow, I shouldn’t have done that, it’s wrong”. But often I IM that person and apologise to them and then I will either just close that chat or just not pay attention to it or I will log-out; I’ll put a stop to myself. But it’s difficult to realise you’ve been snappy until after you’ve been snappy.

1:21:04 JL: But as far as having support people in the chat but not responding, it doesn’t necessarily mean that they’re doing support actively; it doesn’t mean that they’re intentionally ignoring the question. There are also situations – and this has happened to me – where somebody will ask a question, and I don’t know the answer. I just don’t know the answer, and so what I’ll often do is hope that somebody else answers, and sometimes it doesn’t get answered. and if it doesn’t get answered in this situation, it means nobody in the support chat knows the answer, so we can’t answer it. It’s not that we’re ignoring you. We don’t pretend to have all the answers to everything, and sometimes questions come up that are completely, “no idea”. I haven’t got the slightest clue on where to even begin on how to answer it, or even how to diagnose or troubleshoot it. So it’s not that we’re ignoring people. Sometimes we just don’t know.

1:22:10 EM: I have a confession to make. I have a bigger confession to make. I sometimes ignore people. I get IMs coming out my wazoo. The majority of the groups that I’m in are either official Firestorm groups or related to them in some way, like the Second Life Beta Group. I’m in that, I’m in the viewer group, I’m in couple of other groups that are related to things that we do in the viewer. Plus I get IMs. I’ve got about 20 IM tabs sitting here at the moment … my SL family, who are very dear to me, get my auto-response. Sometimes I don’t respond; I’m sorry. I apologise for that. But I have to look after me first. And if I want to take some time to myself with my auto-response on, you’re going to get a reply which says please check on the wiki, because I may not be able to get back to you. We all need our own time, and I’m bluntly honest about this; I will ignore IMs when I need to. It’s one of the advantages to not being paid.

1:24:23 JL: If  this was a paid team, if I was the boss and I had a payroll, and I saw support people in support chat and I saw question going unanswered, I would put the hammer down. I’d be pissed off; I’d be, “What the hell are you doing? You should be working. You’re in support right now.” And I could do that because these are the people who are being paid at that moment, by the hour, to provide support and aren’t doing it. But they’re not being paid by the hour to provide support; they’ve been invited to be an official part of the team to provide support when they can and when it’s convenient for them, when they have time to volunteer.

1:25:10 JL: And that goes for the developers. That goes for Tonya and Cinder and Ed and even myself, and Nicky and Zi Ree and Kadah and everybody on the team. We do it when we can. Unfortunately, we don’t get paid for it, so we do have to work in real life. some of us make a living is Second Life; I don’t personally, but some do. Some of our support people make a living in Second Life, so they may be on-line making a living. Cinder, for example, has a job in Second Life and she’s on-line pretty much every night while she’s working, and the support chat may be open for her, but it doesn’t mean she’s paying attention to it, and certainly she’s not obligated by me or by the team to provide support.

1:25:53 JL: We try to provide support as a service towards our goal of improving the user experience. but because I don’t pay people, because we can’t pay people, I can’t insist that people provide support.

1:26:42 JL: So I’m going to go talk a little bit about voice issues … First of all, let me explain what voice issues are. Firestorm is the project that we develop, that we compile, we issue, we put up on our website to be downloaded, and you download Firestorm. Firestorm comes with two other programs. Inside the package you install is another program called SLvoice.exe. That is a program all by itself. There’s also SLplugin.exe; that is a program all by itself.

1:27:32 JL: SLvoice and SLplugin are both Linden programs which we cannot compile, we cannot edit, we cannot change, we can’t control. we can’t do much with. The way they interact with the viewer is that they kind-of link into each other.  So when you launch Firestorm, you’re also launching SLvoice and you’re also launching SLplugin.

1:27:57 JL: And SLplugin in used for media, media on a prim, the internal browser in the viewer, SLplugin is used to display the log-in screen, for example, profiles for web stuff. And basically when you right-click on somebody’s name and click Profile, the viewer is then communicating with SLplugin, saying, “please display this information”, and then SLplugin looks it up and sends it to the viewer.

1:2829 JL: It’s quite a bit similar with voice. Although the settings for SL voice are displayed in the viewer, the viewer actually doesn’t control SL voice. It links to it. It sends instructions to the SL voice application. So we can’t actually fix voice problems. And interestingly, neither  can Linden Lab. So if you’ve got a problem with SL voice and you’ve tried everything on our wiki and tried everything you can think of to fix it, then it’s somewhat beyond our control, and what we would have to suggest is try contacting Linden Lab.

1:29:31 JL: So the next thing is, log-in to their viewer and from their viewer, see if voice will work. If voice doesn’t work in their viewer, file a ticket with Linden Lab. Because it is Linden Lab’s application, not ours. And if we’ve tried to fix it and we can’t, we just can’t go any further. The only way to escalate that is to escalate it to linden Lab.

1:30:00 Question from 55aaa Danick: Users can deliberately glitch their voices. One can mute / block them, but that doesn’t fix that glitch … so is it proper to AR these users?

1:30:02 EM: If you can identify who it is, I would file an AR against that particular person. I’ve heard of this, I’ve actually seen it once; it’s where they’re glitching the voice so you can’t control it and they can use voice and it’s become more prevalent now because I believe it’s shown-up in a griefing viewer.

1:30:44 JL: Right, so there have been exploits in SL voice for many, many, many, many years. And some of the exploits are, for example, let’s say you are the griefer, you can listen-in on a conversation without actually being logged-in to Second Life at all, and you will not show in the speaker’s list and you can just listen-in and hear everything that the person is saying and connect to other people’s conversations, and those people won’t know that you’re there. There are exploits with voice where they can come in and cause all kind of weird noise and stuff that doesn’t show-up in the speaker list so you don’t know who it is, you can’t mute them, it’s completely disruptive and destroys our ability to do anything in voice. There’s all kinds of exploits with voice, and unfortunately, Linden Lab can’t fix those either. Because Vivox is a company in itself who Linden Lab has contracted who develops SL voice.exe.

1:31:52 JL: So when we had that big voice outage for a day or so during our anniversary, Linden Lab … had to contact their provider, and that’s a fact. It’s not even on their servers. Vivox doesn’t even go through Linden servers; it goes through the Vivox servers. And if there’s a problem, Linden Lab has to file a ticket, just like you have to file a ticket with them.

1:32:22 Question from 55aaa Danick: Didn’t Vivox just update their voice service?

1:32:23 JL: They just recently updated. In fact Linden Lab has just recently updated to a new version of Vivox, and we’ll be releasing that with the next Firestorm release as well. It was said that it might address some exploits, but I’m sure there are new ones. There will always be exploits.

1:32:48 JL: So often times – and we hate to do it – we’ll have a user come to us with a problem and we will try this and that and the other thing, and we’ll send you to the wiki page and you come back, and you’ve tried everything on the wiki page and still have the problem, and we’ll try other things and eventually we’ll say, “Can you download and install the Linden viewer and try it on the Linden viewer and tell us if it happens there?”   And I think often times users will say “What? But I don’t care about the Linden viewer. The problem is on Firestorm and I want it fixed.”

1:3324 JL: Well, the fact is sometimes we need to know if the problem actually is in our own code or if it is present in the Linden code. If it’s in the Linden code, we need to know this in order to try to find the problem developmentally, not just support-wise. If it’s got to beyond the point were support can fix it, then we’ve got to pull-in a developer or two to look at it. And it’s very helpful for them to know whether this is in Linden code, as in code that we’ve not touched, or whether it’s in Firestorm code which we have touched. In other words, is it our problem, did we create the problem, or is this a Linden problem.

1:34:03 JL: If it turns out that the problem still exists on the Linden viewer, then we’re going to go to the Linden JIRA, and we’re going to search to find out if it’s been reported on the Linden viewer. And sometimes we’ll find it’s been reported in the Linden viewer and Lindens will have a workaround that we didn’t know about, and we can come back and say, “OK, this is the problem, but if you do this and this and this, this will fix it for now.” And we may need to wait for Linden Lab to fix it, it may be over our heads. Believe it or not, we don’t know everything. And sometimes we can fix it. Cinder has been amazing, we’ve got Tonya, we’ve got quite a few devs who have been amazing fixing even Linden bugs. But there are some things that are beyond our knowledge or ability.

1:34:45 JL: So if you get somebody from support asking you to download and install the Linden viewer and let us know, please just comply. Because we can’t fix it otherwise. Especially if we can’t reproduce the problem.  So sometimes what we’ll do is we’ll see if we can reproduce it. So, for example a voice issue: we’ll try to reproduce it … but if I can’t reproduce the issue, I can’t trace the problem. It’s like working on cars. If you’ve got a funny noise in the car and you take it to a mechanic, as Murply’s Law would have it, that noise goes away until the mechanic gives it back to you. But id there’s no noise, we can’t find it, we don’t know where it’s coming from.

1:35:40 Comment from Aniya Bovarro: I’ve just seen a lot of exploits.

1:35:41 JL: There are exploits in everything. There really are exploits in everything. You have to use due diligence, but you also have to be reasonable about it. There are exploits with media. Should you never turn on media, never enjoy music in Second Life? Probably not. Should you be diligent and say, I’m in a region where I’m shopping and I don’t need to listen to media, so I’ll turn media off but suddenly I’m at this music venue, chances are I can turn on media because I want to listen to music, and it’s probably safe to turn on the media as long as you’re at the area.

1:37:00 EM: The big thing is, don’t let scripts play your media automatically. Don’t automatically play media.

1:37:11 JL: And turn on the media filter and pay attention to the URL when it tries to connect to something. So just use common sense; it’s not helping your user experience if you’re over-paranoid, digging a hole and building a bomb shelter. You’re not going to have a very good quality of life down there. It’s just good to keep in mind that exploits happen, they exist, they will always exist in every single thing you do in life, especially on the Internet. And the same is true in Second Life and web pages and you name it …

1:39:06 JL: I personally don’t have media on by default. If I go to a music venue, I will turn-on media. I will not have media on while I teleport around from region to region to region, but I’m not afraid to turn it on when I’m in a parcel where I know what the media stream is going to be. I also use media filter and play close attention to the URLs that are trying to play.

1:40:11 JL: I’ll tell you another trick, actually. As we’ve mentioned earlier, we’ve done a lot of effort to build cooperation and collaboration with Linden Lab, and that has been a two-way street. Linden Lab, Oz specifically and some other Lindens, have made efforts to try to improve that on the Linden side of things; to collaborate with and work with third-party viewers. Not just us, but third-party viewers in general. Especially when it comes to support.

1:40:41 JL: What used to be true was that someone on Firestorm or Phoenix would contact someone on Linden support, and regardless of the problem  – say they would say, “My region keeps crashing” – Linden support would see that you’re on a third-party viewer and they would say, “We can’t help you, you’re on a third-party viewer, you have to contact the third-party viewer support.” Which is ridiculous. If the region is crashing, it has nothing to do with the viewer.

1:41:15 JL: Now if you contact Linden support, it should be true that they will not bother with that question, they’ll not even bother looking at what viewer you’re using … But id it is a problem with the viewer, so if you’ve got a problem on Firestorm, don’t contact Linden support. If you’ve got a  problem on Firestorm and you can reproduce the problem on the Linden viewer and we’ve basically said we can’t fix it, you’ve got to go to Linden Lab or that it’s a Linden problem [contact Linden support].

1:41:48 JL: But we’ve not achieved the cooperation we’d like to achieve with Linden Lab, we’re still working on that. So Linden Lab has this system where they can see what viewer you last logged-in with, not what viewer you’re on right now. So what happens is, we’ve told you to try this and this and this on Firestorm, it’s still not there, OK, log-in to the Linden viewer and try it, and so they’ll log into the Linden viewer and the problem still exists there, and we’ll say, “OK, contract Linden support.”

1:42:25 JL: Linden support will see that you were last on Firestorm, and they may say, “You’re on Firestorm, it’s a Firestorm problem,” and they may not help you. So there’s a little workaround for this … log out of the Linden viewer and then log back in to it again, and then file a ticket with Linden Lab. That will then show that the last viewer you were on was the Linden viewer.

1:43:39 JL: We don’t see it now as much as we used to, where Linden Lab refused to help someone because they were on a third-party viewer. A lot of that has resolved, but it still happens. And quite often when it does happen, it’s a junior member of Linden support who isn’t fully trained and doesn’t understand all the things that are going on.

1:44:03 TS: We get along a lot better with Linden Lab these days.  I think they release we really are genuinely interested in helping the Second Life platform as a platform, and we’re not out to try to steal their users or corrupt people, or anything like that. And so we get along a lot better, and they work with us and we work with them. We still disagree, there’s always going to be that, but it’s a lot better than it has been.

1:44:40 JL: There’s still the whole competition thing; there are still some at Linden Lab who see third-party viewers as competition and as such, don’t want to help their users. But that’s gradually diminishing as well.

1:44:54 JL: Next release. When is our next release? Million dollar question … We have a lot of issues still. We’re still working on the merge issues that came up with our merge with CHUI. OMG! What is CHUI?! The last Q&A I got tonnes of e-mails because we used terms like “CHUI”. What is CHUI? We’ve merged-in CHUI.

1:45:46 TS: Communications Hub User Interface.

1:45:49 JL: So now you know what it is … and in more layman’s terms than that, it is Linden Lab’s effort to listen to the user feedback on their interface design and make changes to it. And so CHUI is basically Linden Lab’s effort to change their interface around to what they felt the users wanted. Unfortunately, they merged-in with that code, which we don’t need, by the way, because our interface is just fine, we don’t have that many complaints about it. But unfortunately they put in with that chunk of code all kinds of other stuff which we do need. And the only way to pull-in the code that we do need … we’ve had to take the whole thing and completely screw-up our interface to get that code in. Now we’re trying to un-break our interface, and all kinds of other problems.

1:47:02 JL: So that’s why we’re a little be delayed on our next release. So when is the next release going to happen?  That is a great question, which none of us can answer. I’m going to say – completely wild guess – maybe two months, and that’s being optimistic …

1:47:38 JL: Although in this case I don’t want to wait another six months to get a release out. And it may take us six to eight months or a year to get all the bugs out. So at some point, I’m going to put my foot down  and say, “You know what? We’ve got to get it out.” Because we’ve got to get materials out, we’ve got to get FMOD ex out, we’ve got a whole bunch of stuff that’s in our repo right now, and we’ve got to get this out to you guys. So at some point I’m going to have to draw a line in the sand and say it may not pass QA 100%, our beta testers don’t think it’s ready yet, but I’m going to have to put my foot down and say it’s going to have to go out, with some bugs, and these are going to be the bugs, and we will try to explain the bugs so that people know what to expect. But we can’t sit on the bugs forever; we can’t hold back materials and all these other things forever.

1:48:36 JL: And I say to months because in my mind, two months right now is my line in the sand. And I’ll probably be flamed by our developers and support.

1:48:50 TS: I can see why you want to get it out before Thanksgiving – and not the week before Thanksgiving, either – if we start pushing into the Thanksgiving season, then we start getting into the holiday season and they everybody’s schedule goes upside down. So we do need to go ahead and push out a release, and Linden Lab is very much interested in having us release with materials support. One thing they saw was that mesh didn’t really take off until Phoenix released with mesh support and materials is proving to be the same way. They really want to see materials take-off from the creators’ side, and there are creators out there that are beginning to make good use of it, but it won’t really take-off until a Firestorm comes out with materials support in it.

1:49:53 JL: So unfortunately one of the drawbacks to having such a large user share is that we become the company who hold things back from being adopted in Second Life. So until Firestorm releases materials, materials is simply not going to get much adoption. And that puts us in a kind-of pressure situation, because here we are with something that’s not stable enough for our quality standards; it’s not stable enough to release it. But we’re also being pressured by Linden Lab, but content creators, and rightfully so, to get materials out.

1:50:37 JL: So I’ve got to draw a line and so I’m going to say in a month, maybe two months. and I’ll tell you for sure, support is going to hate me, with a capital H-A-T-E. Because they’re going to have to support all the bugs.

1:50:47 EM: I want to take this a little step further. There are some other things that we would see in the release. There’s polish code coming up for server-side appearance that we want in. We’re very interested in finding out if the new Vivox code will be advantageous; things like that which we would love to see in a release from a support perspective. Then there’s the other side of the story. How many of you would like a release more often?

 1:5134 TS: I’m a fan of the open-source release early, release often mantra.

1:51:42 EM: A lot of our developers would like to see more frequent releases, and I can understand that. From my perspective, I’m of two minds about this … From a user perspective, I’d love to see a new release out every month or two. As a user. But due to my role in support, if there was a new release come out every month, we’d have no support team left. We’d literally have nobody left doing support.

1:52:33 JL: So I have to balance this. Right now we’re averaging a release once every four months, which is way too long. But part of the reason for this is that we set up goals which I don’t think are unrealistic. But we’re a volunteer team. Linden Lab is pushing out releases like two or three a week or whatever it is. They’re on this crazy release schedule. And they can do this because they have employees that are paid by the hour to work every day, they do eight hours a day, some of them do twelve hours a day or whatever it is that they work.  And they’re very productive. I don’t pay people on this team. Nobody gets paid here. So our devs have real life jobs and things, and they don’t get to work eight hours a day, steady, on the project. They can work a couple of hours at most a day.

1:53:25 JL: And so while most of our goals don’t seem to be unrealistic, the amount of time that our developers have to do this stuff is unrealistic in that time frame. What I would like to see, though, and what I’m going to start pushing for, is a release every two months instead of every four months.

1:53:45 EM: And I’m going to twist her arm and say, “No, it’s only going to be once every three.”

1:53:48 JL: So what’s going to happen with that is that is that I’m still under the same problem that our developers don’t have eight hours a day to put on it. And now I’m going to put a shorter release cycle of two months. And so what’s going to happen is I’m going to have to lower the bar a little on our quality standards. Because in order to get stuff out every two months, we’re going to have to have stuff going out that’s not finished or that has bugs that haven’t been completely fixed yet.

1:54:27 JL: There’s a bit of a necessity in doing this, a bi-monthly cycle. and that is that Linden Lab is pushing out two or three releases a week. We can’t keep up with that. So in order to at least try to keep up, we’re going to try to increase our release cycle to once every two months. Which, by the way, we already aim for. I’m already aiming for a release every two months, and have been forever. It just seems to work out that it takes four months to do what we expect would take two.

1:5502 TS: We are at two months since the release of Firestorm 4.4.1 and 4.4.2 now.

1:55:11 EM: And quite frankly, I’ll push for three months simply because of the amount of work we have to do when there is an update.

1:55:20 Question from Mollie Tison: Isn’t that what a beta is for?

1:55:23 JL: Yes it is what the beta is for. The problem with that is that then we’ll perpetually be in beta. Beta is OK if we can push something out in, let’s say, month 1, and we’ll call it beta, and then we’ll polish that up and we’ll call it a release in the second month. But that’s actually not what we’re doing because we’re trying to polish-up everything. And Linden Lab keeps dumping a whole lot of stuff on us. A lot of code.

1:55:53 JL: We’ve got still a whole bunch of code yet to come finishing-up on materials, there’s all kinds of bug which have yet to become public for us to merge in. Server-side appearance is not complete yet; there’s a whole lot of code still to come that’s going to hit us that we’re going to have to merge-in with. There’s interest list fixes from Linden Lab which a whole lot of stuff; there’s HTTP network changes which are coming which is a lot of code to merge with. And we’re still working on fixing the bugs we have right now.

1:56:29 JL: So any time we merge anything in, we get more bugs. So if I say two month, we try to release in two months, it’s still going to have some issues. What I’m hoping for is that we’re going to get all this new code, and that’s what we’re going to release, so we’ll be up-to-date.

1:56:44 JL: Once we can get up-to-date, I think it’ll be easier for us to stick to a two-month release cycle. It’s just that right now we’re behind because Linden Lab is pushing out so many big projects all at the same time.

1:56:59 TS: And it’s worth noting that CHUI was a big block for us, but it also was for Linden Lab. They had a lot of projects stacking up, waiting on CHUI to get built and released and debugged and everything else. So we’re in the position Linden Lab was several months back, and we’re just having to catch up.

1:57:27 JL: But Linden Lab has developers paid by the hour, so they can get through it faster.

1:57:32 TS: But even so, they only have so many developers paid by the hour, so they have projects stack-up as well. And a big glob of code gets released and it releases all the projects stacking-up behind it.

1:57:55 JL: It took Linden Lab over a year working on CHUI and various other things.

1:58:04 JL: So here’s the thing. If Linden Lab work in a transparent way, like we do – we work on our code and it’s the equivalent that we click on save and it’s visible to you. We’ve committed it to our repository and it’s visible to you. If you’re trying to keep up with us, it’s easy to keep up with us because you can pull-in every change we make as we make it.

1:58:27 JL: Linden Lab doesn’t work that way. They’re not transparent in the way they work. So what they’ll do is they’ll work a year on stuff; a year’s worth of work they’ll do in secret. Nobody can see that code the whole year. and then suddenly, “Surprise! Here it is!” and it’s this three thousand commits of changes and stuff to merge-in. That takes a long time for us to try to dump it into our repository.

1:58:56 Comment from Mollie Tison: That isn’t fair.

1:58:57 JL: Well, it is fair in a way. Firestorm is about 90% Linden code. It’s specifically Linden code. There’s so much code in a viewer, it’s insane. We’ve only changed maybe 10% of the code in Firestorm from wandering away from the Linden code base. And the more we change, the harder it is for us to merge-in their changes. Because sometimes they’ll make changes to stuff we’ve made changes to, and when we try to merge it in, it says, “No, no, no. This doesn’t work, I can’t merge.” You’re going to have to do it line for line to determine what goes in where. And so merging takes a long time.

1:59:46 JL: And it is fair because the original reason Linden Lab went open-source was that because they’d hoped that open-source developers would take that code, make stuff and give it to them. And that started happening initially, but Linden Lab turned down a lot of stuff. And so open-source coders said, “I like this feature. I’m going to make my own viewer then and put it in my viewer. and I’ll use it, and I’ll give it to my friends.” And before you know it, a third-party viewer is born. And so Linden Lab can be a little bit bitter about that.

2:00:25 JL: Also, the reason Linden Lab works in secret, in their defence – I don’t agree with it, but in their defence. They want to control the presentation of a feature. So for example, they’re working on a feature and it’s not finished yet. And we have to deal with this. We’ll be working on something and we’ll commit it to a repository and people will see it; self-compilers will see it, and they’ll compile it and they’ll complain because this isn’t working and that shouldn’t be like that … and that mostly is because we’re not finished yet. Don’t come yelling at us; let us finish it first, and they you can come an give us feedback about it.

2:01:12 JL: So if Linden Lab worked transparently, they would get nothing done because they would be constantly under attack by us, third-party viewer developers, because we’re looking at it and saying, “no, no, no. You shouldn’t do it that way.” They probably already know that, but we don’t know. So we’re giving them feedback on something that’s not finished.

2:01:32 JL: So they work non-transparently so that they can finish it and present it the way they want it presented, rather than having people making assumptions prior to it being complete.

2:01:43 TS: By the way, when I was working on the user interface code for the materials viewer, I was doing it in the Linden Lab code base and I was expected to keep it hush-hush for that reason; they wanted to it to appear fully-baked so that they didn’t have a lot of people trying to jump-in in the middle of having it developed. They have their own specifications, their own ideas about how things get done. I was working to a user interface design spec produced by Leonidas Linden, and that’s what I was coding towards. They had a guy who does user interfaces and a user interface standard.  Keeping it to myself was a mild annoyance; I understood the reasons behind it and I think the rest of the team did.

2:02:56 JL: So the reason I don’t agree with that methodology of Linden Lab’s in not working transparently is that, although it is a burden for us to be working on something and having people coming to us and telling us we’re doing it wrong when we’re not finished, it is important for us to also listen to that feedback before we’re finished, because otherwise what happens is that when we do present the finished product and people complain, we say, “You know what? This is the way we want it, we’re not going to go back and change it now.”

2:03:29 JL: And especially in Linden Lab’s case, they have a project manager who’s assigned a couple of developers who are assigned to do this; this is what they have written-out in their plans, this is the way it’s supposed to be finished, and when it’s finished and when they release it, they’re assigned to the next task. So by that point, when people come in and complain and say it shouldn’t be this way, it shouldn’t be that way, it’s too late to change it; it’s not going to get changed.

2:0353 JL: And how many times has this happened in Second Life, where Linden Lab has released something that wasn’t quite complete, and they didn’t go back and re-visit or try to fix it? It’s happened more times than I can count. And that’s why I don’t believe in that methodology.

2:04:16 EM: So unless you’ve got some more questions, I think we should wrap this up. We’re just over two hours in here.

2:08:27 Comment in chat from Aniya Bovarro: Honestly, I hate CHUI.

2:08:33 Comment in chat from Jessica Lyon: So do we, Aniya … FS will have very few if any of the CHUI interface changes.

2:04:29 comment in voice from Sweetcheeks54 Timeless: When we were talking about the voice earlier, I was finding out that if it doesn’t work on an SL viewer or Firestorm, it could possibly be your firewall.

2:04:43 EM: Yup. that’s one of the things on the voice issue wiki page, on our troubleshooting page.

2:04:50 comment in voice from Sweetcheeks54 Timeless: That’s what I was finding because I had that problem, and I had to go into my firewall and fix it.

2:05:00 EM: That’s the thing. [With] voice issues the most common issue is actually on the users’ computers. That and the servers.

2:06:17 EM: So I guess we’ll wrap this up. I want to thank you all for coming out. I want to thank you all for asking the questions that you’ve asked. We’ll be having another meeting on the last or forth Saturday in September, so the 28th. It’ll be in the afternoon [SLT], either 3:00 of 4:00pm. That hasn’t been actually decided yet.

[Meeting wraps with chit-chat.]

Related Links

• Meeting video on YouTube
• Firestorm blog
• Firestorm classes