Firestorm meeting 10th August, 2013 – video and transcript

On Saturday 10th August, 2013, the Firestorm team hosted a question-and-answer session so they could outline the current status of the Firestorm viewer, the issues the team are facing, and outline plans for the future, as well as address questions from the audience.

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

The TL;DR Summary

The numbers in braces are timestamps which refer to the section of this transcript where more details can be read, and to the section of the video recording where the relevant comments can be heard.

• The next release of Firestorm in likely to appear some time in the next month to three months [08:04]
• It is hoped that when it comes out, it will have all the necessary CHUI updates [05:04], materials processing [10:14] and the final code polish from Linden Lab for server-side appearance [13:50]. It will also have other, smaller updates the Lab is releasing, such as FMODex [18:14] and Vivox [18:48], etc.
• The release will have bugs and issues (25:56 and 2:34:58]
• Once the next release is out, Firestorm will be limiting the number of versions which can connect to SL to three at any given time: the current version and the two releases previous to that. Versions older than these will be blocked [1:44:26]
  • Update:: following questions on whether this block applies to Phoenix or not, Jessica has provided an answer on the Firestorm blog, as has Kadah Coba in a comment here. In short: while no decision has been taken with Phoenix, blocking is unlikely unless there are still a significant number (thousands) of users still running it after SSA has been fully enabled on the grid.
• By its nature, Firestorm has additional complications when updating / merging large projects such as CHUI, where because of skinning the viewer, bugs can be more widespread [30:16]
• Please help support to help you: chiclets and defaults [37:16]; preferences and Firestorm classes [42:52]; keeping your viewer settings reasonable [56:45]. Also see Other Points of Note at the end of the transcript
• OTR is coming to Firestorm, but don’t believe your IMs were ever secure [1:32:37]
• Firestorm turns three on September 3rd. There will be a party, but numbers will be limited as the team only has the one region! [1:55:00]
• There will be regular Q&A sessions held twice a month, probably starting on Saturday September 14th (TBC), arranged to accommodate different time zones. A blog post will be made on this.

Member of the Firestorm team assemble for the meeting (l to r): Cinder Roxley, Whirly Fizzle, Lette Ponnier, Takoda, Jessica Lyon, Tonya Souther, Ed Merryman

04:32: Jessica Lyon (JL): Hey folks, welcome to a Q&A. We’re going to have many of these coming up, and we’ll talk about that shortly. Thank you for coming because the fact that you’re here tells me that you guys want to stay up-to-date and you guys are our favourite users, because there’s nothing worse than giving information and having people not interested in it, because the information is designed to help you guys understand what we’re doing – so kudos to you all!

CHUI

05:04 JL: So, the first item on the list is CHUI [the Communications Hub User Interface]. Some of you may remember hearing about CHUI, we blogged about it at some point a while back, so I’m going to try to break down what CHUI is.

05:20 JL: Linden Lab spent a little over a year … basically listening to the users and adjusting the changing their user interface. So they got rid of chiclets and did all kinds of different things with the user interface to try to improve things. Unfortunately, during that process they were also working on all kinds of other stuff, very important back-end code stuff which is, you know,  infrastructure, hard-core back-end stuff. So had they just dropped the CHUI code alone, by itself, we could have ignored it, because our interface is just fine, thank you very much and we’ll make whatever interface changes we need to as we need to, so we don’t really need that CHUI code.

06:31 JL: But because Linden Lab put all kinds of other stuff in that same repository of code [and] that we do need to have, we had to try to merge that code in with our code, and the problem is it all comes with interface stuff which conflicts like crazy with our code, our interface. We’ve been working on it, and Tankmaster, who most of you know as Tank, handled the majority of the merge, Ansariel Hiller did a lot of the preparation in Firestorm for that merge, and a lot of our developers, include Tonya [Souther], Cinder [Roxley] – a lot of our devs aren’t here unfortunately –  did a lot of work.

07:29 JL: We have merged CHUI into our main repository and there was a lot of stuff broken, and there’s still a lot of stuff broken. And it is going to take us some time to fix that stuff, but we’re working on it. Now, the next release that we push out is going to have some of this broken stuff. We’re not going to be able to fix everything, at least not in time for a timely release. We could spend for our five months trying to get everything fixed , and I don’t think we want to wait four or five months to get a release out because there is other stuff as well in here we want to get released as soon as possible.

08:14 JL: So, at some point soon, and by soon I mean maybe a month or two, maybe three, I’m purely guessing here,   we’re going to have another release out of Firestorm, and it’s going to have CHUI and you’re going to find some stuff looks different. In some cases it’s going to look different because we thought, “Hey, this is not bad actually, let’s keep that”, and then there’s some stuff that may look different because it’s a bug, a conflict in the merge from the Linden interface changes, it may be something that we’re going to fix when we get around to it. Needless to say, this merge has been a nightmare and it is the reason why we are behind in a lot of the new stuff that Linden Lab has been putting out.

09:13 JL: We’ve have people saying, “When are you going to get materials?” and “When are you going to get this?”, “When are you going to get that?” Well, the problem is, we have to get CHUI first, we have to do that first. That’s the bad news. The good news is that we’re making good progress …  where we are right now  is a lot further than I expected we would be in this time frame. So that’s actually a good thing.

Materials

10:14 JL: So, for those of you who don’t know what materials is, it’s really cool. First of all materials was one of the first real collaborative efforts between third-party viewers and Linden Lab. What that means is that Tonya from this project, Kitty Barnett from this project and Catznip, Geenz Spad from Exodus all worked with Linden Lab directly to put together this feature.

10:50 JL: So what it is, basically, is … you know when you wear, say, a dress shirt with buttons on it and it just looks like it’s a flat texture; it’s like a picture of buttons, they’re not really bumpy ; they don’t show as buttons … What materials does is makes it look real, it gives depth to textures in Second Life. Content creators have to go out of their way to make this stuff, it’s not quite the same as building regular things … it doesn’t work on avatars unless its mesh … it works on things like walls, floors, if you want to have like a laminate floor like you have in real life that’s not exactly perfectly smooth… you can do that will materials  … it gives a three-dimensional feel to it.

A katara showing detail created by the use of materials properties. You can see examples like this at Hippotropolis, but you will need to have a materials-enabled viewer, such as LL’s release viewer (Firestorm does not yet have materials support)

11:58 JL: There are some drawback to it you have to turn-on Advanced Lighting Model [Preferences > Graphics > General tab in Firestorm] …  it does have a bit of a performance impact in order to see it; Linden Lab is still working on improving that, and there’s still a lot of code we don’t have. But let me just say that we have materials in our local repository right now, and it looks great and I was playing with it the other day.

12:55 JL: A lot of people keep asking when will we have materials, well when we release the next release … first of all we hope to have most of the bugs  from CHUI merge [fixed] and hopefully you won’t notice a thing, or you won’t notice much,  and that will mean we’ve done a good job merging CHUI; [and] we should have materials.

Materials demonstrated in a pre-release, self-compiled version of Firestorm

Server-side Appearance

13:50 JL: Kudus to Linden Lab! Let me just say kudos to Linden Lab. I think people don’t realise, I think most people can’t even comprehend, the complexity of what Linden Lab has taken on, the risk that they have taken on with server-side appearance.

14:10 JL: This is no small task. Seriously, it’s a lot of core code they’ve made changes to that could break everything. So it’s not like Linden Lab releasing pathfinding or releasing mesh, where if they got it wrong, well you just wouldn’t be able to see mesh or you just wouldn’t be able to use pathfinding. If they did this wrong, you would not be able to use Second Life, and so it’s a pretty massive thing. In fact it’s the biggest thing I can think of in memory that they’ve taken a chance with, because of the potential for serious breakage.

114:55 JL: The other thing about it is that it is nearly impossible to test properly … to predict what is going to happen when they roll it out to the grid. And the reason for that is because it is very difficult to roll it out to a little bit, and it’s very difficult to just load test.  In fact the third-party viewers participated in some of the load tests, helping Linden Lab do the testing for it. And really, it was three or four regions, maybe fifty or sixty people at the very most that they were able to test this with. Now keep in mind that fifty or sixty people is nothing compared to the 50,000 people logged into Second Life at any given time.  So guessing how things will go when they roll out live to the grid, even on just release channel server versions, which is what they’ve been doing, has been a very risky proposition; and I can say that they’ve even surprised themselves how well this roll-out has gone out.

16:00 JL: And I have to say publicly on record, I predicted  it would take them at least three rollbacks, so they’d try to roll it out on a release candidate, and they would have to roll it back, try it again and roll it back and try it again. And I was wrong, because they rolled it out on the first release candidate [LeTigre], and it worked great, and now it’s also on Magnum, and its working great. It’s got a few little bugs, and they’re being very cautious in rolling it out, which is why it is only on those two server versions so far, but nothing like serious. If you land on a LeTigre region or a Magnum region and you look around [at] people, they’re already rezzed; it’s really fast.  So I have to give Linden Lab credit on server-side appearance; they’ve done an absolutely incredible job on something which is just a monumental task.

17:06 JL: It’s not finished yet, and that’s where the topic comes back in here. Server-side appearance is not finished yet; there’s still much to do. Linden Lab has quite a bit of code yet to be released to third-party viewers, which is what they’re calling polishing code  – kind-of like polishing it up  – and there’s no ETA on when that code is going to become available to us, but we’re hoping it will become available to us before we’re ready to release this next version, which will be 4.5.1. So we’re hoping that we’ll have the server-side appearance  finishing-up code as well.

What Will Hopefully be in the Next Release

17:54 JL: So, the next release should have:

• The CHUI merge, which hopefully you won’t notice
• Materials, which hopefully you’ll enjoy
• server-side appearance polishing code, so that there won’t be any more problems hopefully and fingers crossed
• 18:14 JL: FMODex … FMOD handles audio in Second Life, not voice; audio, and they’ve updated that and we’d adapted that … I believe there’s still some bugs … but hopefully they’ll be taken care of by the time we release.
• 18:48 JL: Vivox is another one. Vivox is what handles voice … Linden Lab have updated to a new version of that, and that should improve the reliability of voice … [19:39] A lot of people don’t know this [but] SL Voice does not go through Linden Lab. We curse Linden Lab, “stupid Voice, I wish they could get it right” – it’s actually not Linden Lab. SL Voice goes through another company called Vivox, so when there’s major problems with it Linden Lab has to contact Vivox and ask “can you fix this?” Just like you have to contact Linden Lab if you have a problem you need fixed.

Summing-up the Current of Status

25:56 JL: Here’s the unfortunate message I have to offer you guys … While the next release of Firestorm is going to have … lots of new stuff  – it will be a major release – it’s going to have some issues, because we’re not going to be able to find all the bugs and we’re not going to be able to fix all the bugs that we’ve incurred from CHUI. Although I’ve got to say, I’m running it right now and it works great for me, but I only use one particular skin. Keep in mind that CHUI has an effect on all of our different skins, so I may not be able to find a bug in the skin I’m using but that doesn’t mean there’s not bugs on the other skins, so we have to get into the QA process, which we’ve not started yet … I’m hoping we can get a build out to QA this weekend so we can start that process as well.

27:16 JL: The delay in putting it out to QA is that there are a lot of issues already that we know of, and sending it to QA is going to give us a whole lot more issues … and we become overwhelmed, so we’ve just been dealing with the issues that we have, that we’re aware of right now before we go to QA.

On Skins, Notifications, Bugs, Support and CHUI

See also: Firestorm wiki – Skins Tab

30:16 JL: So I suppose we can segue off-topic for a moment and just talk about skinning and Firestorm for a moment. Skinning in v1 … was generally kept to just colour theme sort-of changes, but the skins were still universally the same from one skin to another. I’m talking about Phoenix specifically; you know we had a whole bunch of different skins, but the buttons were all in the same place, the preferences were all in the same place, all the same defaults from one skin to the next skin.

30:52 JL: When it came to skinning Firestorm, Viewer 2 we’ll say. The way this viewer – and by “this viewer” I mean the Viewer 2 code base in general, not Firestorm specifically – came to us coded quite differently from Viewer 1. It is … times ten harder to skin this viewer than it was to skin Viewer 1.

31:28 JL: So we had the challenge of getting developers interested in even trying to bother with skinning because it really was a rage thing. We’d look at it and say, “Why the heck did they do that? Why doesn’t this work? Why can’t I do that?”

31:45 JL: People have been asking for chiclets to be killed for ages – we’ve been trying to kill chiclets for ages; it really is not that simple. It’s very deep and it goes back way deep in the code.

32:02: Kadah Coba (KC): It’s not just chiclets, it’s any form of notification … it assumes it works this one way, and unless you just completely subvert them, there’s no real way to change their behaviour. So you either have to completely rebuild the entire notification system at a certain point, or you live with how they are.

32:28 JL: So what started happening is that I would get one dev who would start working on a skin, and they come down to saying, “You know, I don’t like this viewer default” … “I don’t like the default location of the chat bar, I think it should be on the bottom left”, and another dev would say, “I like to have the chat bar different”, or “I want to have buttons different”, or “I want to have this different and that different”. And it boiled down to saying, “Look if you want me to make you a new skin, you’re going to have to let me do the skin how I want it.”

33:10 JL: And so you’ll notice that as you go from one skin to another skin, not only ware they visually different, but the defaults are different from one skin to another skin. In Vintage skin, for example, there are no chiclets.

33:58: Whirly Fizzle (WF): Chiclets are hidden by default on Phoenix mode, but you can turn them back on in Preferences, but I think in all other log-in modes they’re enabled by default, but you can also disable them in Preferences … I think you have to relog when you disable or enable them.

34:51 JL: So in Viewer 1, when we had a bug in one skin, we could fix it in that skin and it would be fixed in all of the skins, and that bug would exist on all the other skins because they all shared the same files.

35:02 JL: With the way skinning is done on Firestorm now, each skin has their own files, their own defaults, their own settings, their own preferences; so as far as maintenance is concerned, it’s a bloody nightmare. Because if we have a bug on one, we don’t know about it unless we use that skin. And so for example, the skin I’m using may look fine, but it doesn’t mean that the Vintage skin doesn’t have a bug, it doesn’t mean any of the other skins [don’t] have bugs … My point being that you may find bugs on some skins that don’t exist on others.

35:36 JL: There is also the support factor. So some things are in different places from one skin to another, and if a user comes to support for help, they have to sort-of guess what skin you’re on, they have to figure out what skin you’re using. Because, depending on what skin you’re using, it’s in a different location; and that’s why we have the option in the support groups to send your viewer type. What that does is it tells support what viewer you are using and it really helps support when you enable that when they try to answer questions for you. And that’s why earlier, Lette was sending someone to preferences rather than to a UI thing to fix a problem … because depending on what skin that user is on, it’s different.

36:27 JL: So that’s kind-of a fail for us. You guys kind-of benefit from it, because you get options and choices, but it is a major hit for us as far as maintenance and as far as support. And when we merge-in Linden Lab’s interface changes, it’ll affect some skins and it won’t affect others. So that’s why CHUI has been such a problem, and that’s why we’ve been so kind-of lagging behind with certain things that Linden Lab has released that we haven’t been able to yet because we have to get the infrastructure code that came with CHUI implemented in our viewer so that we can get all the other stuff.

Of Chiclets and Defaults

37:16 JL: Some people like chiclets, some people don’t. You guys remember the sidebar? … Remember how much screaming there was at the sidebar? … A lot of people hated it … and Linden Lab decided to listen to their users, kudos to them, and they got rid of the sidebar. And what happened when they got rid of the sidebar? They got screamed at by the people who liked the sidebar. So it’s a no-win situation, and people wonder why … it seems like Linden Lab doesn’t listen to their users; it’s not that they don’t listen to their users … they just know that they’re damned if they do and they’re damned if they don’t.

38:24 JL: Chiclets is the same thing. We’ve been trying to kill chiclets, but if we kill chiclets altogether people are probably going to rage that we’ve got rid of chiclets. And the same goes for everything else. I still have people asking me if we can bring back the sidebar … so it’s a bit of a conundrum for third-party viewers and for Linden Lab, that any change you make is going to piss-off some people and make some people happy. And if you change it back, you’re just going to get the opposite reaction. It’s pretty difficult to please everybody.

39:03 Ed Merryman (EM): Can I say something here … just as a slight extension? For all of you out there who say, “It should be THIS way as a default,” do you realise how many people we’re going to piss-off if we change the default to the way that you want it?

39:23 Lette Ponnier (LP): And that goes for just about every preference that you might want to change the default for. Every single one of them.

39:41 EM: Firestorm is not a simple viewer. If you want simple, you’re on the wrong viewer. You’ve got a tonne of preferences in there that you can change the way you want.  If you want a different default, sorry about your luck, but we’ve had team discussions about defaults in the past that turned into, to be totally blunt about it, heated arguments that went on for two weeks about a simple default. Sorry, folks, but it isn’t worth the headaches, not only within the team but also dealing with the drama afterwards, “Oh you changed my defaults on me!”

41:01 JL: Will the next release have no chiclets? Hopefully, that’ll be optional. at the moment I think it is semi-optional.  [They’re removed from CHUI but] we got them back again.

41:19: LP: Really, as long as there is something that shows-up on the screen that tells you there are IMs there, I think most people will be content. Although full chiclet optionality would be awesome.

41:33 JL: A lot of people don’t realise that chiclets were the replacement for notices. We got rid of chiclets with CHUI, but there’s still no notices, so the chiclets do serve a purpose.

41:50 Question from Tahiti Rae: Is the delay in the past year in seeing edits to terrain textures immediately (new textures and/or elevation changes) until terraforming over it again, an http fetching issue?

42:08 WF: No, it’s not an HTTP fetching bug, it’s something we picked-up from viewer three [see FIRE-8459].

On Preferences and Firestorm Classes

42:52: Comment from Zion Tristan: The best User Experience is to include every option possible

42:53 JL: Let’s talk a little be more about preferences to address Zion … Linden Lab chose the path that options are bad, and there is sound reason and sound logical behind that. The more options you give the user, the more tools you’re putting in their hands to screw-up their viewer. Then they come to support because they are having all these problems … and of course the other problem is, the more options you have, the more difficult it is to support the viewer, to support the user. And we have that problem.

43:41 JL: Our outlook on it is this: give the users an many options as you can, within reason – and that’s the key there, “within reason” – and be able to support it by having a dedicated, kick-butt support team, host classes to educate people.

44:01 JL: You know, I’ve heard the argument “we shouldn’t have to go to class just to learn the viewer”. Firestorm is a power user viewer, and if you want to use it efficiently, and you want to have a good experience with it and you want to know how to fix the problems you come across, go to the bloody classes. That’s what they’re there for. Firestorm is not a basic viewer; it is a very advanced and complicated viewer, and it is very difficult for us to support it because it is becoming more and more complicated with more and more features and options we put into in.

45:03 JL: I can tell you one thing about preferences. It’s a disaster. When I get to the point where I’m looking for something … notifying you when you’re entering a different server version … that was in a preference panel which had absolutely nothing to do with what it was, and I have no idea why it’s there. It’s completely illogical.

45:49 JL: When we started Firestorm, you guys remember preferences in Phoenix was just a complete mess [and you] couldn’t find anything have the time? When we started Firestorm we said, “Whatever we do, let’s not let the preferences become like Phoenix. Whatever we do.” And we even sat down and we worked-out a plan for preferences and all that stuff. And if you guys could see preferences right now on the internal build that I’m running right now, unreleased, it’s a complete disaster; you can’t find a bloody thing. And I’m hoping upon hope [that] we can refactor the preferences before we release. What that means, though, is that it’s going to be really confusing for you guys, because you’re not going to be able to find stuff; it’s going to get moved around into what should be more logical locations. So again, is having lots of options good? Well, you end-up with problems like there where you can’t even find the options because you have so many of them.

46:55 Tonya Souther (TS): Never mind the users not being able to find them, half the developers can’t find them!

47:04 LP: Here’s a secret about our classes. Although it’s a lot more interactive than reading the wiki, most of the material for most of the classes comes directly from the wiki. So if you are unable to come to the classes, whenever there is a preference you have a question about, find the little question mark in the upper right-hand corner of that preferences tab and click it. It will open a media browser for you containing the wiki page for that preferences tab, and you’ll get an explanation of what those things do.

Getting help with preference tabs

47:57 LP: There are some videos on our YouTube video channel as well, and some of our classes are recorded, but they’re getting pretty old. I think they’re a year old now, so the only one that are probably still mostly valid are the contact sets and AO classes and most of the menus. So you can check the wiki on that. Also, keep an eye on the class schedule, the scheduling takes place anywhere between 08:00 SLT and 19:00 SLT any day of the week and it get switched around every single time we reschedule the classes. So if a class doesn’t work out for you the first time it’s offered, check back a couple of weeks later and it will probably be held on a different day and a different time.

49:05 Question from Amberjack Kidd: What can be done to get double-click movement / teleport back to where you can use them without major surgery? The problem is toggling back and forth … is practically impossible because you can’t change it without going thru menus”

49:09 WF:  [The] problem is to change between the double-click movement and double-click teleport [means going] into too many preferences, it’s buried to deeply [for Amberjack]. She can actually add those preferences to her Quick Prefs so they’ll be available with just a couple of clicks.

49:39 JL: We’ve got a feature I completely forgot about … Quick Preferences, where you can put whatever preferences you want into this little preferences panel and you can just click-click enable it, disable it, do whatever, and you can actually go in and find it. And there’s a video on it.

50:17 Question from  55aaa Danick: who designs inventory? Any possibility Inventory might be revamped or updated?…or is that a dumb question? 

50:21 JL: There’s no such thing as dumb questions, only dumb answers! Inventory is incredibly complicated, and it’s doubly complicated in our case because of RLVa. And Kitty [Barnett] – who is in no way responsible for any bugs in inventory – does a lot of inventory work for us, she’s quite familiar with it. But there are a lot of bugs in inventory and there are new bugs now because we’ve merged from CHUI. In fact, just about any time we merge with Linden Lab we get some bugs with our inventory because we’ve done things differently with inventory.

51:06 JL: Actually a few people recently, and I’m not sure if it is coincidence, asked for the ability to “lock” items in your inventory, just like [the Firestorm] bridge can be locked and stay attached, so even if you do a Detach All, the bridge will stay attached. I’ve had a few e-mails and a few IMs from people asking for that, but that is not a new idea, that came up a long time ago, some of our devs may not even remember it, but we discussed it and if I remember correctly, we said, “no” to that because it would cause all kinds of issues with RLVa. I could be wrong, but I’m pretty sure that’s why we don’t have it.

52:04 KC: Speaking of RLVa, you could do just exactly that with RLVa.

52:10 Question from  55aaa Danick: so who is responsible for inventory?

52:12 JL: Let’s say … Rodvik! Everybody send your e-mails to Rodvik! (laughs). But the majority of the code comes from Linden Lab. Firestorm is 98% Linden code. When we do a merge, we’re merging a lot of their code into a little bit of our code. A lot of people say that we “invented” the Firestorm viewer – actually, Linden Lab did. We’ve just modified it a lot.

52:51 TS: I in fact wrote a blog entry about this. There are other viewers out there that spend a lot of time and effort out there re-inventing wheels. We choose instead to embrace the Linden code base, warts and all. Each approach has its pluses and its minuses; we happen to think the way we go about it is superior, but that’s a matter of opinion as much as everything else. What it does mean is that when Linden Lab messes-up things, we inherit the mess and have to fix it.

53:32 JL: And things like CHUI remove the ability for us to kind-of pick and choose. Quite often what we’ve done in the past where Linden Lab has pushed something out, is we’ll just sort-of cherry-pick bits of what they did. And it would have been great  – and we certainly looked at this as an option – cherry-picking out the stuff we need and leaving the interface changes that Linden Lab did alone, but there was just so much stuff and it was just so intertwined that we had to take everything, break Firestorm completely in that process and then spend a whole lot of time trying to unbreak it. That’s where we are right now.

54:20 KC: They kind-of touched on absolutely everything involving chat at every point in the viewer. Which kind-of messes with everything, since anything that touches chat in any fashion, which is a lot of stuff, had to be done in some fashion.

54:44 Question from 55aaa Danick: are there any advances in reducing ram issues with the update viewers or is everything becoming more ram intensive?

54:56 JL: I don’t know of a viewer release every, from anybody, which didn’t have some memory leaks. A memory leak is … when you enter a region and there’s all kinds of avatars, and all those avatars get loaded into RAM, and then you leave that region and what should happen is that all those avatars then get removed from RAM, but don’t. So then you go to the next region and more avatars get added to RAM, and you end up with your memory [usage] building up higher and higher. That’s in layman’s terms.

55:43 JL: We’re constantly fixing memory leaks as we find them, and with every release of the viewer we have more memory leaks; it’s a cat-and-mouse game. It’s a constant thing, and there’s no real end in sight. They just happen in any software. Also, memory leaks are extremely difficult to trace.

56:45 EM: We see a lot of problems in Second Life that are related to your settings – maybe not yours in particular -but in general , users like to ramp the settings up. They want their graphics to be up really high, they want their draw distance at 512 metres, they clear their cache; so let’s talk about sane settings for Second Life for a minute.

57:13 EM: Do you really need to have your draw distance at 1024 metres? Do you realise how many regions you can see on mainland if your draw distance is set at 1024 metres? Do you realise how many objects you’re rendering? Do you even understand exactly how draw distance works?

57:38 EM: If you double your draw distance, for example, from 32 metres to 64 metres, you are not doubling the amount of area that you’re seeing. It is up to eight times as much area! So you’re grabbing that many more textures if there are things around you. And you’re stressing your machine. That’s your computer that has to do all the work!

58:11 EM: Another one: you ramp-up your bandwidth because 3,000Kbps on the bandwidth slider is more reasonable for you, right? Wrong! That’s not the way it works! You’re generally going to have fewer problems if you keep your bandwidth lower. Sorry folks, if you come to me with a problem and you’ve got your bandwidth ramped-up to 3,000Kbps and your draw distance at 1,000 metres, I’m going to tell you to turn them down! And if you’re not going to accommodate me, I’m simply going to say, “Well, sorry, good luck, have fun, can’t help you.”

58:51 EM: There are a tonne of things that do not respect the bandwidth throttle in the viewer. Voice works outside of it. Music works outside of it. Media works outside of it.

59:20 LP: I was just going to add a bit of context to this same rant, actually … First off, if you are not experiencing any problems with the settings as they are right now, we can’t really tell you to change come of them, and we’re not going to. You can have your settings however the heck you want to have them if you’re not experiencing problems with them.

59:45 LP: However, the difficult comes in when people come in with an issue and say, “I’ve having this problem and these are my settings”, and we recommend changing those settings and they stick to them really hard and they won’t change them for one second, because they say, “Oh, I didn’t used to have to change them”, or “Well, it worked in Phoenix” or whatever it happened to be.  Well, viewers change, your needs change, Second Life changes, the landscape changes, everything that you’re rendering changes. Two years ago, you weren’t rending mesh, now there may be mesh requests going on that have to do with what you’re rendering. A variety of different components may change for you.

1:00:33 LP: And while we’re talking about network related things, such as bandwidth, it’s going to change. Networks change. You network is not the same today was it was yesterday, not identical, anyway.  So, if you are not experiencing problems, then you can just relax and not worry about everything that I’ve just said. However, if you are experiencing problems, the very first thing, particularly if it is a performance issue and your draw distance is 1,000 metres, just cut it in half at least. The fact that, if I’m not mistaken, the default draw distance for Ultra graphics is 256 metres still should be an indication of what SL considers to be a high draw distance.

1:01:25 LP: Listen to your computer; don’t tell it want you need it to do, listen to how it is responding to your settings and your activities and don’t be afraid to make any adjustments. There’s nothing golden about any particular setting that you tend to use.

1:01:51 JL: So just to add some context to the support rants. Support has Ed, especially, and Lette, and actually all of you guys here who have been doing it for about three years … but three years of support  – and I’ll tell you what, support is the single hardest bloody thing that you can do; I have all of the respect for our developers who work their arses off, no argument, but support is a hard, hard, harder job. I mean way harder job. People IM me and say, “Oh, you’re the project manager, you know everything.” No, actually, I don’t.  I do know that I suck at support, and these guys have the most amount of patience and deal with the most amount of angry people, and so there might be a reason why there might be a little bit of tension in their voices when talking about this particular topic, because they see it all the time.

1:03:28 Question from FreshFrenchAngel174: is there in CHUI future version still the choice to save chat log differently than the IM one? 

1:03:35 JL: Yes, that’ll still be the same.

1:03:39 JL: So to be clear with CHUI, we call it “CHUI” because it’s been the bane of our existence for a little while and will still be for a while yet, because you know it was all this code, so we just call it CHUI. But we’re not going to call it the “CHUI release”; it’s going to be 4.5.1, but you may hear us refer to is as “CHUI”, just because like I say, it’s been “fun”, it’s been interesting working out this code drop from Linden Lab.

1:11:21 Question from Nathan Adored: what about the issue where linked objects like levers and doors don’t show as changed position when they move until you look away and back? is that close to being fixed yet?

1:11:23 WF: The door issue is, I think fixed after this last merge. We got all the Linden Lab fixes in. It still needs to be checked, but in a lot of the repro objects the bug isn’t reproducing. I think Pantera still has a door that reproduces it, so I need to go and look at that and also compare it to see if it’s still broken on Viewer 3; but hopefully this next release should have most of those rotating and sliding door issues fixed.

1:13:43 Question from Nathan Adored: what about the issue with manually-created folders in the Garments  folder in inventory not showing up in the Appearances pane?

1:14:11 JL: You mean the Outfits folder? Nobody is actually supposed to create folders or put content in the outfits folder, it’s a system folder. Lots of issues have occurred from people doing that, especially saving objects in that folder. It’s supposed to only be for links, and content that goes in the folder should only be there from creating or editing your appearance, and any other behaviour in there is not supported. I do know other people who have created subfolders in the Outfits Folder to put other outfits into, and that should work.

1:15:12 JL: But as far as inventory is concerned again, that’s 99.999% Linden Lab code, including the Outfits Folder, and not really code that we can do much about because inventory is a whole lot of server-side stuff … and so we can’t make many changes … we can change something in the way it works on the viewer, but if there’s no support for it on the server-side, it’s not going to work.

1:16:04 Question from 55aaa Danick: any possibility of introducing a screen share [letting someone else see what is on your screen] within SL?

1:16:06 JL: Somebody said, “over my dead body” and I’ll just reiterate that. We’re not going to be doing screen sharing in Second Life. There’s a lot of reasons for it. Just way too much possibility for abuse … That’s a pathway we’re just not going to venture down … Let me give you a hypothetical: George says to Tara, “here, take a look at my screen,” and Tara looks at it, and then the next day George’s account gets hacked. And then George goes to Linden Lab saying, “Tara hacked my account through Firestorm”. So you can get an idea of where that’s going.

1:17:11 EM: Linden Lab would probably shut us down if we put something like that in; it’s an invasion of privacy.

1:17:19: Question from Zion Tristan: What about a release date for Firestorm Mobile for Android? 😛

1:17:21 JL: Ohm I’d love to do that, I really would! I have an Android ‘phone!

Franklyn Watanabe(via text): Zion – next February 30th!

1:17:25 JL: But yeah – No.

1:17:32 TS: I’ll put in a plug here for Lumiya on Android. It works pretty good, it’s fantastic, the developer is very responsive and it’s actually very usable on my Nexus 7.

Lumiya (l) offers almost a full in-world experience on Android devices and includes RLVa and mesh support. This picture shows a partial mesh house rendered in Lumiya and (r) on a regular viewer. Inset of the same house on a non-mesh viewer

1:17:44 JL: Lumiya is fantastic … You know, I said on a blog post after that April fool’s joke that Lumiya and Pocket Metaverse were as good as it gets. That wasn’t due as a poke or a negative thing towards them. That was to say they’re really good, and that is as good as you’re going to get because making an app for Second Life for a phone is incredibly difficult … what you guys have available to you with those apps is absolutely stunning work; really good work. And I can guarantee you, we couldn’t do better. We could not do better because we don’t have anybody on the team with the expertise for those operating systems and how to do anything on them as far as making apps is concerned. I don’t think anyone on this project has made an app for a phone.

1:18:44 LP: Since we’ve talked about screen sharing and we’ve talked about mobile apps, let me give you a quick tip. If you install a remote access app on your Android or iPad, iPhone, etc., and leave your computer on at home and then access it from your mobile device, you could use Firestorm remotely in that way. It’s not an elegant an option as if you actually had Second Life on your mobile device but if you really, really, really want to take SL with you … it would be an option … You would need to leave to computer on when you leave the house but you’d be able to do anything that the remote access application allows you to do. I haven’t used one, but I believe you’ll be able to access your desktop and click on your Firestorm icon.

1:27:21 JL: How many of you use OpenSim at all? Because the compatibility in Firestorm with OpenSim is almost entirely due to Cinder Roxley’s efforts. And if you guys have any OpenSim questions, that’s why she’s here. And some of you may in fact know that there is an OpenSim conference coming up [on] September 7th and 8th … Cinder and I are on a panel [on September 8th], along with somebody from Kokua, somebody from Singularity. It’s basically a panel discussion about OpenSim from third-party viewer developers … So for those of you who want to, or who are interested in coming to the conference, I’ll post some information up on our blog as we get closer and as I get more information about it.

[Note: in-world attendance at the OpenSimulator Community Conference is fully booked. However, there are still places available to receive the events streamed to your computer – you can register to receive the streaming here. There is also an in-world exhibition centre and numerous social events taking place, none of which are subject to pre-registration.]

On Secure SL Communications

1:32:37 Comment from Tahiti Rae: Just to throw this out there … I release voice [is] being improved but there seems to be the possibility of privacy breach … was a fluke I guess. In a very laggy club with live stream I suddenly heard a VERY private voice conversation that no-one else heard. What was scary was I had voice disabled. Has that happened to anyone else?

1:32:50 EM: I’ll tell you a story about that. Jessica and I were sitting around in my skybox one night with my SL son, Mabon … and we were sitting around and having a chat and he decided he was going to go off shopping so that Jess and I could talk shop. He went to three different regions, and he was talking to us on all three regions. Voice does that on occasion. We’ve have people come out to our classes, who have left our classes and got to partake in the entire after class Q&A session while they were … thousands and thousands of metres away from us in SL. So yeah, voice doesn’t always connect properly or disconnect properly. It’s a rather strained animal.

1:34:05 JL: So to expand a little bit on that … That bug has been around since forever, along with a lot of other bugs and there are people who have taken advantage of that bug to be able to connect to voice while not even being in the region you’re in, but they can connect to the voice channel in the region you’re in and they can listen to you and they will not show-up on your who’s talking or who’s speaking list; they will not show up on radar; they will not show up. And as far as you’re concerned, you’re having a private voice conversation with your friend right next to you; but there’s somebody there and they could even be recording it. And I’ve had this happen to me plenty of times. Do not ever, ever take for granted that you’re just on voice with your friend and nobody else can hear because they can. There are griefers with the technology which is not that advanced who can do that.

1:35:00 JL: Voice has always had security holes in it and they are not the fault of Linden Lab. Like I said before, voice is owned by Vivox and run by Vivox, and it’s up to Vivox to fix these kinds of issues. But whether or not those are fixed in this new version of Vivox, that is yet to be seen. I don’t know yet.

1:35:27 Question from Cybix Topaz: does this include IM voice?

1:35:29 EM: Yes, Cybix, it does.

1:35:32 JL: This is specifically voice.

1:34:34 EM: There is no such thing as privacy in Second Life. If you think there is, you’re fooling yourself. There just is no such thing as privacy in Second Life.

1:36:05 KC: Don’t trust Vivox as secure in any fashion whatsoever. Use Skype or something.

1:36:30: Comment from Serith Haefnir: I have some [users] keep asking about OTR.

1:36:31 JL: OTR. OK, let’s talk about OTR [off-the-record messaging, an optional form of encrypted messaging used in Phoenix for IMs] … So the thing with OTR is that we have relatively good reason to believe that Linden Lab cracked OTR before we even forked Phoenix, before Phoenix was even started. In fact, if you’re have OTR conversations and think Linden Lab can’t see it, fact is, probably they can. We don’t know this for sure.

1:37:32 Cinder Roxley (in text): Phoenix’s OTR implementation is vulnerable to at least 4 different attacks.

1:37:39 JL: So right from Cinder, OTR has apparently never been secure. And I’m just going to say for the record – we didn’t do it – ORT was implemented back in Emerald … and when we did the fork of the Emerald code base we took OTR and we thought for the longest time that it was secure. Now looking back, we don’t think it actually was.

Cinder Roxley (in text): Cryptography is perilous because you get no feedback when you mess up. For the average developer, one block of random base 64 encoded bytes is as good as any other.

1:41:40 JL: In layman’s terms the OTR implementation that was … put into Emerald originally and that Phoenix had, was not actually keeping anybody secure.  We’ve had a lot of people asking if we’re going to put it into Firestorm, when will we put it in Firestorm. The answers are yes, yes. We’re going to put it in Firestorm at some point … but if we’re going to do it, we’d better make sure it works, because otherwise we’re giving people a false sense of security.

1:42:18 JL: So Cinder has being sort-of working on that as a … lower priority project, but it’s in the works.

Cinder Roxley (in text): I’m working on a much stronger secure IM protocol. But it takes a long time because it has to be done correctly.

Version Control

1:44:26 JL: Some of you may recall or have read somewhere Oz Linden saying there was something like 1665 viewer channels,  different version of viewer out there. Firestorm and Phoenix weren’t a minority of them out there … there’s a lot of Phoenix versions out there and there’s still quite a few Firestorm version out there. But that number is diminishing as people are updating as people are updating [because of] server-side appearance  because they have to at this point. But we don’t want that to happen again.

1:45:00 JL: In the past … I haven’t wanted to force people to update. And it’s because we have people on older systems who just can’t update to the newer stuff. We’re at a point now where if you haven’t been able to update then you’re just out of luck, and that is beyond our control. Server-side appearance is here, it’s not in Phoenix, it’s not going to be in Phoenix, and we can’t magically put it in old versions of Firestorm. So if you can’t update, I’m sorry; I really feel bad for the folks who have old PCs.

1:45:45 JL: But now that we’re here, now that all of our old versions are being eliminated from use, we’re going to start a new process. As you know, we have the ability to block Firestorm; we have the same ability for Phoenix, we can block specific viewer releases if we need to. We’ve only done it when we’ve needed to, mainly because it’s a huge inconvenience to you guys, especially if you’ve got a show to do in five minutes or 20 minutes and suddenly your viewer is blocked and you can’t log-in and there’s the time it takes to go and download a new version and get into it and get to understand it and stuff – it’s a real inconvenience for you guys. And that was another reason I didn’t want to force updates on people. But that’s going to change.

 1:46:38 JL: The plan is this: we’re going to allow three versions on the grid at any given time. So let’s say “Version 1”, then let’s say we’ve got “Version 2”, and then we release a “Version 3”. When we release “Version 4”, we are blocking “Version 1”. And when we release “Version 5”, we are blocking “Version 2”.

1:47:02 JL: So at any given time, there will only be allowed to have three versions on the grid and not only will the other ones not be supported, but they’re blocked, they’re gone. And if you are on an old version it’s to your advantage to stay up-to-date, it really is.

1:47:21 JL: And there’s a lot more reasons than just support that we’re doing this. Linden Lab is pushing a lot of advances in Second Life. Server-side appearance is a biggie, materials is another one, there’s a lot of really cool stuff coming, a lot of stuff that’s still in the works that’s coming. And in order for these things to be adopted, we need to have everybody on these viewers.

1:47:43 JL: We get content creators saying “I’m creating this content, but so many people can’t see it”, and that’s because they’re on older versions, older viewers. We’ve got to keep up and unfortunately with the advancement of technology and improvements to Second Life come higher system requirements … and that is just a reality of technology. It’s not us, it’s not Linden Lab, you can’t blame anybody. It’s just going to happen … and it always has happened that way

1:49:08 JL: So the moral is, we’re going to stay up-to-date with Linden Lab, and we’re going to try to do it quicker and we’re going to try to get releases out quicker … We’ve been doing releases on average once every four months; I really want to try to improve that to two months, once we get caught-up with this next release that is coming – 4.5.1.

1:49:58: Question from Serith Haefnir: will there be a warning thing before a viewer is blocked?

1:50:02 JL: Kind-of. The warning is going to be the message of the day [which] will come up saying we’ve got a new viewer release, and that should be your indication to update to that new viewer release.   That’s kind-of your warning … The other thing we do is when we block a viewer is it gives us the ability to provide a custom message. so when you go to log-in, you get an error message, “you can’t log-in because…” you know, we’ve got a new release out, this one is being retired. Please update, here’s a link. And that’s about as good as you’re going to get.

1:50:40 JL: It’s not as aggressive as Linden Lab, keep in mind. Linden Lab by default, I believe … forces you to update when there’s an update, that minute; you’ve got to do it. We’re not really big on that … We might do like a two or three day grace after release number 4 before we block number 1 … So we’re just going to keep older viewers out of Second Life.

1:54:20 JL: The last thing on my list … September 3rd. Does anyone know what September 3rd is? … September 3rd is rather and important day for this project … [it’s] our third anniversary … So yeah, that’s our third year running and so what are we going to do about it? Well, we’ll probably have a little party, as we do and have done in the past. And we’ll have a post about it somewhere. We won’t do a message of the day, as we’ve only got the resources of one region and if we do message of the say that goes out to 250,000 people, and we can’t accommodate that many people in one region. So if you want to attend, just keep it in mind.

1:58:45-2:10:15; 2:12:39-2:13:45; 2:15:02-2:16:14: Extensive conversation on why bug reports need to be filed using the JIRA, and simply trying to get the attention of a Firestorm developer or team leader won’t result in real progress, why it may appear that things take a “long time” to resolve; why some issues cannot be fixed by Firestorm (e.g. render pipe issues)  and must be referred back to LL await fixes from their end. References to blog posts Lette Ponnier on why FS users should use the FS JIRA from 2012 and in 2013.

2:10:15 Question from Zion Tristan: Referring to “Show Look At”. Firestorm has removed the lines connecting agent heads to their coloured crosshairs. Is there any plans to bring that back, even as a developer option?

2:10:20 EM: Not likely. Quite frankly, the Show LookAt is a drama feature. It really doesn’t show where people are looking, it shows where the camera is focused … If it’s possible, file a JIRA. Maybe it’ll get looked at, maybe not … I’m not a big fan of the LookAt feature, quite honestly.

2:10:57 JL: Linden Lab tried removing that … and discovered that those beacons are actually necessary in order for our avatars heads to move around and for our eyes to move around. That’s what those beacons are, and you can’t remove them. If you remove the beacons, like in our viewer we can choose to see them or not see them, and when we’re not seeing them, we’re still seeing them, it’s just that the viewer’s not rendering it. But if you remove those beacons then everybody looks like zombies in Second Life. So they have to be there, but for most part, they are a bit of a drama feature.

2:13:52 JL:  I’m not sure what you mean by “connecting lines” … I don’t think we ever had anything like connecting lines [from the avatar to their LookAt crosshairs] … we’ve never had that.

2:14:12 KC: I think that’s only something that happen only in Exodus now.

2:16:15 Question from Cubizh: Do you see any changes coming in the way the Height Offset setting is handled (in the foreseeable future) by Linden Labs, or do you think the current way to deal with this issue is here to stay?

2:16:17 JL: You know, I’ve got to give Nyx Linden credit, because Nyx sort-of set a precedent that has never happened at Linden Lab before … Where Linden Lab was developing something that inadvertently broke a third-party viewer feature that they weren’t even aware of, that certainly wasn’t supported, and Linden Lab actually decided to take some time to try to provide an alternative. It’s never happened before. Nyx took it upon himself and as far as I know, on his own time, to provide a hover offset in the Linden viewer which we obviously adopted. And like I say, that’s never happened. I mean, Nyx has a heart of gold. Nyx Linden  – he rocks!

The hover slider in Edit Appearance: a partial solution for the loss of the z-offset function from TPVs

2:17:11 JL: Don’t expect that to ever happen again, where Linden Lab will inadvertently break a feature they weren’t aware of and which they did not support, and then spend time fixing it … It happened this time, and chances are it will never happen again … well, I guess there are a few things where it could happen, but minor in comparison to avatar offset.

2:17:44 KK: Well, if it is easy to fix, it’s easier to get them to fix it.

2:1812 JL: This happens a lot … and it’s become kind of a saying … “this is why we can’t have nice things” … There’s so many times where we’ll have an idea for a feature that would be so cool, it would be so beneficial to the users; but because it could potentially be used to abuse other users, we can’t do it … and so in Second Life, it’s a consequence we have to weigh every time we have something cool to do.

2:19:45 Question from Kara Enchanted: Temporary uploads: They still exist… for now. This is the next TPV feature to sit on death row, as it will be broken when Server-Side Appearance goes into effect in a couple of weeks. That’s in your blog. They’re doing away with it?

2:19:50 LP: Yes it is. And currently, if you go to a server-side appearance sim, you are not going to be able to use temporary uploads. It’s already gone on server-side appearance regions. Instead of using temporary uploads, use the local texture picker (see here also). There’s a link in the blog to how you use that. It does most of what temporary uploads did .. although depending on what you use temporary uploads for, you may or may not find it to be an improvement; but for some people it is an improvement.

Local textures: a way to preview object and clothing textures prior to upload

2:20:34 JL: Temporary uploads is not only a feature that was not supported by Linden Lab, Linden lab was not aware of it for the longest time, and I believe only really became aware of it two years ago, maybe, with Phoenix … And they had a different opinion about temp uploads than what we had of it. Because the way they see that … is a third-party viewer creating a capability to circumvent the Linden uploading system, to circumvent them getting L$10 a texture. It was a loss of revenue and they were pissed. But they also had the issue of how many third-party viewers have temp uploads, and had they known about it back in the Greenlife days … before it was renamed to Emerald … they probably would have put their foot down … So that’s not a thing of Linden Lab inadvertently breaking it, they wanted to break it. They didn’t go out of their way to break it, but server-side appearance as it turns out, breaks it, and they were very happy that it does.

2:21:51 EM: Can I say something possibly controversial here? The fact that server-side appearance would break the temporary uploads is probably one of the reasons that server-side appearance got the go-head as a project …

2:22:20 JL: Server-side appearance really is a major re-write of major amounts of core code and is a huge risk and expense for a company to take on. It wouldn’t surprise me if that was one of the contributing factors for why they decided to go ahead with it.

2:22:54 KC: It’s more likely that the reason was why we don’t have both simultaneously. There’s no backwards compatibility. Killing temp upload is more likely the reason why we don’t have legacy support still.

2:23:33 JL: It was Vaalith [Jinn] who developed the local bitmap browser. It was in Emerald, I believe, near the end, Phoenix has it for the longest time but people didn’t use it very much, it is a fantastically useful feature. Vaalith developed it and gave it to Linden Lab, we then of course adopted it  – in fact Linden Lab insisted they release it before we do, as we have a gentlemen’s agreement that we offer out to all the other viewers … if we see you dump something into your repository of your code like some cool feature, we promise we won’t go in there and take it and put on our viewer and then release it before you do … and please, in return extend us the same courtesy … So Linden Lab released that and we put it into Firestorm. And as far as Linden Lab is concerned, that is a perfectly suitable alternative to temp textures.

2:24:38 JL: There are arguments that suggest it isn’t … there are legitimate arguments for temp textures, and Linden Lab has not denied that there are legitimate arguments for temp textures. But they’re not going to bring that back.

2:24:58 EM: The big plus about the local textures is … you can update it on your local machine and have it applied to the prim in-world and you can see the update right away.  There’s not more having to do another temp upload, and another temp upload, it will constantly update every time you update it on your computer.

2:26:21 JL: One of the arguments for temp textures is … for collaborative work. If you and a couple of other people are working on the same item, you can drag the texture on the item – you’re not paying money for it to bring it into Second Life – you can drag it on the texture and those around you can see it, and then you can collaborate … Linden Lab’s argument to that is, go to the beta grid … Everything you upload on Aditi is free because its kind-of like a sandbox grid … So if you want to collaborate on something, you and whoever you’re collaborating with can log into the beta grid and you can do that from Firestorm or from the Linden viewer, and you can collaborate there.

2:26:12 KC: You need to get access to Aditi first, though’.

2:27:24 JL: So there’s a lot of features that third-party viewers have that Linden Lab may not necessarily be aware of; make no mistake, Linden Lab does keep a very close eye on our repositories, but they can’t catch everything. There are a lot more self-compilers and users who keep an eye on our, and all the other third-party viewer, repositories, and I can assure you they will catch something; but if it’s something cool for them, they’re not going to say anything about it, like temp textures. But at some point it will get broke.

2:28:22 JL: It’s not just third-party viewers that are responsible for having things in-world that Linden Lab is not aware of or does not support that may get broken by Linden Lab either intentionally or unintentionally. There are a lot of content creators – and I’m not going to go into a lot of detail on this; I thought about it and I decided against going into too much detail. But, there are content creators who are using hacks to create really cool content. And then they tell their friends, other content creator friends, or they put tutorial videos … and then other content creators start going in and they start using these hacks to make this really cool content despite linden Lab having told them “this is not supported, it is a hack and it will most likely get broken at some point in the future”.

2:29:19 JL: And what’s going to happen then, in the future, say six months from now or three months from now, my jeans will just explode and not work anymore. And although there may be some guys happy about that, I won’t be, and neither will be the thousands of people who have purchased the same jeans, for example.

2:29:40 JL: So just to say it isn’t only third-party viewers that come up with ways of making things or doing things that end-up getting broken.

2:31:45 Question from Tahiti Rae: will the known bug of friend notifications taking you back to top of inventory be fixed in 4.5.1?

2:31:45 JL: I have around 2,000 friends on my friends list. I probably know about one percent of them.  But believe me, that bug of your inventory scrolling to the top when a friend comes on-line drive me insane. And that is a good example of even the project manager doesn’t get to dictate what gets fixed first, second third and whatnot. Even when it drives her bonkers.

2:32:55 KC: It’s probably triggering something like and inventory update, and it’s reflowing the whole inventory panel.

2:33:01 JL: That has been fixed many times. We have released with that bug many times and we have released fixes many times … And that’s what we call a regression, folks. When you fix something and then suddenly the bug is there again, and you can’t explain how it got back or you didn’t notice that it was back and you released it. That’s a regression. And that’s a really common regression bug that keeps coming back.

2:33:33 KC: I’m one of the few people who has dug into this, ever, but the whole friend cards concept that happens is just bizarre … a friend card is not a calling card.

2:33:50 KC: A friend card is a copy of your own calling card that uses description fields set to the friend’s UUID, and then from there it changes the name of the card to show theirs. It’s kept in a separate folder to the calling cards and it was being used by Viewer 2 to populate the Friends List in various views … Does it make any sense? And it’s more complicated than this, because you can’t read inventory reliably.

2:34:44 JL: Yeah lots of “why doesn’t this do this?”, “Why doesn’t it do that?” Chances are that if it bugs you, it bugs us to. And it’s just a matter of shifting through what we already have on our priority list.

2:34:58 JL: With every release that we do, I have to sit down – and I love Whirly to bits, don’t get me wrong; I love her like you can’t believe. She is the heart and soul of this project and we would be lost without Whirly. But every time we get close to a release, when we go to go into a release mode, I have to sit down with Whirly … and triage all of the bugs that we have and decide which bugs get fixed for release and which bugs don’t get fixed for release. And we have to go through each JIRA … and we read through the comments, we will often try to reproduce it ourselves, and we will spend hours and hours on a Skype call just going through triage … Sometimes it take more than a day, sometimes it’s spread over two or three days … I would rather jam bamboo stick under my fingernails than do triage … I love Whirly, but I hate triage …

2:36:08 JL: What makes it so difficult is that everything that’s there needs to be fixed. They’re all important bugs; it’s trying decide which ones are we going to release with. And I hate that, because I want to release a viewer that has no bugs. I want to release a viewer that’s perfectly stable, I want to improve your user experience. And knowing that I have to ignore this bug and release with it because there are other bugs that are just worse, even though this bug is really bad, it really sucks. And it actually gets a bit depressing, because it goes out and then I see people complaining about this bug. And … I know that it’s there, I wish we could’ve fixed it.

2:37:14 JL: Anyway, with every release we have to choose to release with bugs, and there are lots and lots of bugs … keep in mind that when we do the triage, these are the biggest bugs, the biggest impact bugs that are existing right now. Because Whirly does most of the triaging, actually. She starts triaging weeks before that, and she cuts down like a thousand issues down to something more manageable like two hundred issues or a hundred issues, and then she drags me into triaging those. And she loves it. She loves triage. I don’t know how you do it.

2:38:00 JL: Anyway, we do release with bugs … we will often say “that’s a known issue”, and quite frequently it’s because we couldn’t get around to fixing it. If I could find more developers, if you guys want to go pick-up some books on C++ and learn developing, I will be happy to bring you on the team once you’re able to do it. I’m serious. We need more developers. If I had as many developer as we have support people, we could fix things.

2:39:50 JL: We’re going on nearly three hours. This is going to be a really long YouTube video. I think we shall call this one closed … As Ed mentioned [see Other Points of Note, below], we’re going to do more frequent Q&As starting when Ed?

2:40:16: EM: I’m looking at the second Saturday in September [14th September] as a start.

2:40:40 JL: So the beginning of our bi-monthly Q&As will begin September 14th. So we’ll do this more often, try to keep you guys more up-to-date. Sometimes we won’t have a lot of stuff to talk about … and maybe we can get it live streamed if we do end-up discovering that there’s too many people showing-up and not everybody can get in … if everybody can fit, then that’s what we’ll do and just record them.

2:41:27 JL: Thank you all for coming. Really. Big thank you for wanting to be informed and taking steps to be informed. You are our favourite kind of user … and with that, I’m going to call this to a close and stop the recording.

Other Points of Note

• 27:46 – 30:15: Kadah Coba is working on a fork of the Vintage skin which he feels has slightly more of a Phoenix-like default setting profile as well as some different UI behaviours, such as the volume controls at the bottom of the screen popping-up as a panel, rather than as a floater. He’s hoping to do more work to add further v1-style behaviours, code allowing.
• 21:33: Kara Enchanted asked whether a repeated refresh problem she was experiencing with avatars was related to SSA. Jessica, Whirly Fizzle, Ed and members of the Firestorm support team also responded in voice and chat, as summarised here. This is not thought to be a problem with SSA per se, but is a problem in Firestorm and other viewers, and is under active investigation. It can be caused by a number of different things: wearing certain HUDs (Some Tiny Empires HUDs are known to cause it), or wearing certain mesh clothing items, for example. Removing the HUD / item of clothing has been known to stop the issue. It’s also been reported when Windows Vista or Windows 7 users who are running their viewer in XP compatibility mode have the problem, and turning off the compatibility mode has resolved it. Disabling HTTP texture fetch (Preferences > Graphics > Rendering > Use HTTP Textures) may also help in some cases.
• 1:04:58 – 1:06:39: in responding to a comment that Firestorm support could always remotely access users’ computers to provide support, Ed Merryman and Jessica Lyon pointed out that the team did used to do this using the Teamviewer software. However, the problem arose that if, subsequent to doing so, the user found another issue on their computer outside of Second Life (such as missing files, etc.), the tendency was to blame the Firestorm team for the issue. Therefore the practice of remote access has been largely discontinued; if there is a need remotely access a user’s computer, the team might consider doing so, but preferably only a text waiver has been returned by the user absolving the support team member and Firestorm from blame should anything untoward happen during or following an attempt to diagnose and fix Firestorm-related issues.
• 1:06:40 – 1:10:33: It is often forgotten that the support team, as with everyone in the Firestorm project, are all volunteers, and that Firestorm has an extremely large user base. This means that it can take time to receive an answer to a question for a variety of reasons: the number of support team members actually on line and monitoring the support groups, how busy they are dealing with other questions and issues, how well the request for assistance is phrased, how well they actually understand the question, whether they feel they have the confidence to deal with an issue themselves, and so on. As such, acts of rudeness, aggressive use of upper-case text, “kicking and screaming” are often not the most positive ways to gain their time and attention.
• 1:21:41 – 1:25:10: Ed Merryman asked for feedback on the Q&A sessions and whether people would like to see them happen more often. The feedback was overwhelmingly positive and Ed revealed that the team were considering holding two a month, possibly one at the start / middle of the month and one towards the middle / end of the month, with one starting at perhaps 08:00 SLT and the other at around 13:00 or 14:00 SLT in order to reach the widest possible audience across both. Meetings are liable to take place at weekends. If it can be arranged, the next meeting will take place in the first or second weekend in September.
• 1:28:27 – 1:31:50: There is a discussion about Open Simulator (OpenSim):  what it is, etc. Topics covered include the server-side development being open-source, the variety of grids available (walled gardens such as InWorldz and Avination), more open grids such as OSGrid, the status of economies, Hypergridding to teleport between grids which support it, etc.. There are one or two misconceptions within the discussion when comparing OpenSim with SL.

Related Links

• Meeting video on YouTube
• Firestorm blog
• Firestorm classes