On Saturday May 17th 2014, the Firestorm team hosted another of their Q and A sessions to discuss Firestorm and Second Life, and to address users’ questions. Unfortunately, no public video for the meeting is available. The following transcript is therefore provided from a personal audio recording made by myself.
For those who wish to listen to the audio, and for ease of reference, it has been broken down into a number of files, each of which precedes the text to which it relates
When reading, 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 audio, 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, repetition, questions to others etc,, these are indicated by the use of “…”
Questions / comments were made in chat while speakers were talking. This inevitably meant that replies to questions would lag well behind when they were originally asked. To provide context between questions and answers, questions in the transcript are given (in italics) at the point at which each is addressed by a member of the Firestorm team, either in voice or via chat
This transcript is provided for informational purposes only. I am not an official member of the Firestorm team, and technical or support issues relating to Firestorm cannot be addressed through these pages. Such requests for assistance should be made through the in-world Firestorm Support groups or at the Firestorm support region.
Firestormers Assemble: Takoda, Tonya, Jessica and Ed settle-in for another Firestorm Q&A session
Firestorm 4.6.5 and the Release Cycle
00:00 Jessica Lyon (JL): So we released 4.6.5 two months early – surprise! It’s been a more-or-less, pretty much across-the-board, a really good release for folks, with few problems and lots of improvements, although it is primarily just bug fixes which are in it anyways. So that was sort-of to be expected and hoped.
00:25 JL: It was a bit of an experiment, because we’ve had a lot of people complain about how long our releases take, including some of our own developers and even some support people. So it was a bit of an experiment in some ways just to see what happens if we do a release in half the time. And the results are interesting.
00:48 JL: Adoption – the rate at which people upgrade from whatever older version they’re on, has been very slow compared to other releases; although that’s not to say it’s non-existent. We have … 85,000 people on 4.6.5 now, and that’s not quite in a full week [since release]. So that’s no slouchy number; but in a typical release, we’re usually up around 140,000, so almost twice that.
01:28 JL: It’s easier for support, certainly, because fewer people are updating all at the same time, so I guess that stretches out the support load. [It's] easer for QA, that’s good to know. But that doesn’t mean we’ll be able to do releases in that two-month time frame all the time.
01:56 JL: For example, our next task is going to be project interesting, which I’m sure most of you are aware of, Linden Lab just finally released it, and it’s apparently really, really good. Things rez much faster, and we can’t wait to get … to the point after we’ve merged it … [there's a description of the interest list work, as per the blog post linked to above].
The interest list updates provide more predictable and faster scene rendering, such as large objects and those closest to you appearing first, rather than at random. More use is also made of the viewer’s cache (so the warning for not clearing cache as a first action in “fixing” issues becomes even more important)
04:45 JL: Anyway, we’re looking forward to having it in a release state; we’re not looking forward to trying to merge it … because it’s a ridiculous amount of code … and trying to merge that in is going to be really tough. It touches thousands of files.
05:10 JL: So don’t expect us to be releasing that in a two-month period. It’s going to take some time to merge it; it’s going to take some time to work out the bugs, of which we’re going to have plenty, because any time we merge, our code is far enough away from the Linden code that any kind of merge causes all kinds of problems, especially a merge that touches almost every file that we have …
05:56 JL: So the way the process works [is]: we do a merge, and then we have builds internally, which is just support and developers have it. And we find obvious things. If we put that out to the beta testers, when there’s obvious things, they’re going to be reporting things that we already know about …
06:14 JL: So we do internal testing first, and as we’re doing internal testing, support or developers will notice things, and those things get fixed. We try to get it to a state where there are no more painfully obvious issues; and that’s when it goes out to the Quality Assurance team, the beta testers. And they hammer it and find all the stuff that’s not obvious. Because everyone uses the viewer differently, you find more issues as people use different things differently … And QA find things and report them, and then developers go at it again and try to fix these bugs.
06:58 JL: And then we’ll do another build to QA; one every week or every two weeks, and they find more bugs, and it’s a process until we’re not finding any more major bugs. Then we get to a point where we say, “OK. we’re going to go into a release cycle.” And we go into a release mode, and the way that works is we take our main LGPL repository, or main branch, and make a copy of it. And the release branch is going to be that copy. In this way, developers can continue to do their thing in the main repository without anything new landing in the release repository.
07:45 JL: So we make another build with that, and get that out to beta testers. New fixes than land in the main repo, and if they’re chosen to go into the release, then we’ll copy them over to the release branch. And eventually we get it to a point where we think it’s ready, and then it goes out to the preview group for a couple of days. Again, more people, more hands on it, more eyes using the viewer in ways we’d never imagine someone would use the viewer, and then we release.
08:16 JL: So it’s not just a thing where we say, “OK, let’s just cut it here and let’s release this.” We don’t do it that way …
08:29 Ed Merryman (EM): Just to make the next release more interesting, it’s not just going to be project interesting … I’m going to be jumping up and down and insisting we get the group ban code it as well. So it’s actually two merges which need to be done.
08:51 JL: The interesting thing about group ban is that chances are it’ll be released by Linden Lab by the time we get to a release … and we’ll be able to use it on our internal builds, because there’s a lot of server-side work involved. So even if there are people on viewers which don’t have group ban, we can still ban you. but anyway group ban is a big priority because that’s huge.
[There is at this point a note about the SL scheduled maintenance with will see grid log-ins suspended for around an hour on Thursday May 2nd - see the Grid Status Page for more details.]
Tonya, Jessica and Ed
Firestorm Crash Rates and What Next for 64-bit Versions
00:04 JL: We got some early stats from Oz [Linden] … some interesting things … with 4.6.5. The 32-bit version of 4.6.5 has a crash rate of 10.6%. The 64-bit version of 4.6.5 has a crash rate of 6.5%, nearly half.
00:34 JL: It’s not because the 64-bit is more stable than the 32-bit … well, it is in a way … they’re exactly the same, code-wise; There’s not changes in the code. It’s just that 64-bit operating systems handle memory better, handle the viewer better, and if you have a 64-bit operating system on Windows, I highly recommend that you use the 64-bit Firestorm version.
01:07 JL: This seems to be the same for Singularity, which also has a 64-bit version as well. Their crash-rate on the 64-bit is way lower than on the 32-bit. And again, it’s not necessarily that [the 64-bit] version of the viewer is better, it’s just that the operating system handles it better. most likely that’s what we think it is, anyway.
01:32 Tonya Souther (TS): Have we got any indication from Oz about a 64-bit Havok [library, which is used with the mesh uploader, and pathfinding's navmesh]?
01:40 JL: No. And someone mentioned before the meeting that they’re still waiting for their 64-bit version, which would be Mac … So Linden Lab is interested in doing 64-bit. They see our stats … our crash rates between 32- and 64-bit, and its usually beneficial for people if we could offer a 64-bit build for all of our operating systems …
02:19 JL: In order to do that, Linden Lab will have to issue a 64-bit compiled library for Havok … Once that happens, then our Second Life version of the viewer will be Second Life only; in other words the Havok version of Firestorm will have a 64-bit a well, which it doesn’t currently, because we don’t have a 64-bit Havok [library] because that’s a closed library, we can’t see it, we can’t do anything with it. But Linden Lab aren’t making any promises on time; there’s nobody currently working on it at this moment, as far as I’ve been told; but it’s on the “do want to do” list.
On a 64-bit Mac Build and Third-party Libraries
03:15 TS: Can I growl for a minute about the Mac stuff? We know that we would all dearly love to see a 64-bit Mac OS X version of Firestorm; me as much or more than anybody else. And quite frankly, folks, right now, I’m the hold-up.
03:42 TS: The problem is that to build a 64-bit distributable version of Firestorm, we have to rebuild all the libraries as 64-bit libraries. and Cinder did almost all of that work. There are two libraries that still need to be rebuilt, and one of them is called Boost, and Boost is … working on Phoenix and then Firestorm has taught me to thoroughly, deeply and passionately hate C++, and I consider the existence and necessity of Boost to be a major indictment of the language. Unfortunately, we’re stuck with it …
04:33 TS: Not only have I not been able to build the version of Boost we need, but we cannot use the current version of Boost, because they’ve made incompatible changes to their programming interface, and we have to use the version from before that change. So I have to get an older version of Boost built, and that means backporting a couple of fixes from versions after the programming interface change … Remember the old Chinese curse, “May you live in interesting times”1? Project interesting fits that, but Boost is even more interesting than project interesting!
05:16 TS: So it’s not that we don’t want to do a 64-bit OS X, we would dearly love to, I would dearly love to … unfortunately, until I can get over that hurdle, it’s not going to happen … I’m working on it as my time and real life schedule permits, but I’m not even going to try to make any promises as to when. You’ll see it when it gets announced, and unfortunately not any sooner than that.
05:59 JL: So it boils down to that it isn’t that we did Windows 64-bit bit because there’s more people on Windows … we did Windows 64-bit because it’s easier. 64-bit on Mac for the viewer is exponentially harder … And take note, nobody has done it yet … it’s not been done by any third-party viewer ever in history. It’s not because there’s not a want for it … it’s because it’s really hard to do.
06:52 JL: How many people know what devs are talking about when they say “libraries”? I’ll try to put it into layman’s terms. So, [in] Encyclopaedia Britannica there’s different books for different things. When they’re all together, it makes a collection. We’ll call that collection the viewer. But if you don’t have one of those books, you don’t have a collection, you just have a bunch of books …
Part of the list of 3rd party libraries used in viewer builds (LL) – click to go to the list in the SL wiki
07:32 JL: The viewer doesn’t just run everything by itself. there are a lot of other little applications, you can call them, that in themselves don’t do anything, but when tied into the code, or when the code calls on them, they do stuff. And that’s kind-of like what a library is when you hear developers talk about libraries.
07:55 JL: So there’s the viewer code, and then there’s Quicktime, for example, these are all kind-of like modules that are required at the time you compile the viewer. So when you guys get the viewer, it’s all in one package. But when you’re compiling the viewer, there are all of these other little packages that the compiler looks into to link that functionality from each of the libraries into the viewer.
08:26 JL: Boost is a huge one, and it’s really convoluted and complicated and big, messy and ugly … so I like to think of it as Encyclopaedia Britannica set, and if you’re missing one of those books, it’s just not going to work …
9:18 JL: Anyway, Mac 64 is coming … It’s inevitable, it will happen. Be patient, I can’t tell you when it’s going to happen … We all want it … Asking for it every day is not going to make it come any faster. It’s not because we don’t want to work on it, it’s just because it’s not easy … And that’s a point with Linden Lab as well. Linden Lab really wants the 64-bit; but it’s a matter of resources and time. They don’t have an infinite number of developers they can take off something and assign to something else; so it’s time on the calendar.
[At this point Ed gives his usual promotion for the Firestorm Classes, which are held at the Phoenix Firestorm Support region classroom and at Junkyard University. Class times are scheduled throughout the week at different times to meet the needs of different time zones, and recordings of classes can also be obtained on the Firestorm YouTube channel. There is also the help area on the Support region where assistance can be sought.]
Q & A Session
00:09: Is there a problem with alphas being stuck on but not showing and won’t come off until I go back to the default character? For example, shoes.
00:54 JL: It doesn’t sound like it’s a well-known issue for support … Sometimes people will post a question in our support group repeatedly and they don’t get an answer. Quite often it means that the people who happen to be there at the time, support people, don’t know the answer … When the comes into the case, file a JIRA. Because once we have a JIRA, that’s something that is stationary, it’s static, it’s going to stay there and we can link. We can have our developers look at it and we can have the rest of the support team look at it until somebody has an idea and we can also communicate back and forth through the JIRA.
JL: A lot of people don’t file JIRAs because they think it gets lost and never seen again; I can promise you, Whirly will see it, and she will assign it somewhere and make sure it’s looked at.
02:02 TS: Let me add another couple of items to Jess’ comment … If you send support questions by e-mail to admin@phoenixviewer.org, it’s not going to help. That goes to Jess and me and one other person, and none of us do support, so we have to forward it to the support group … and it takes a while, so it doesn’t help to do that.
TS: And especially, please don’t ask support questions and comments on our blog …
03:46: What about alphas not reappearing after setting them to invisible then trying to make them visible again (in script) they remain invisible Sometimes it doesn’t happen at ground level. Sometimes a higher LOD helps. Sometimes zooming out and back in helps but at other times nothing helps.
JL: I don’t know, but I’ll bet there’s a bug report about that, and it probably is … an across the board issue.
04:22: Is the Nvidia driver problem still around?
04:26 JL: Which one? … There’s plenty.
04:43 TS: We’re pretty heavily dependent on the driver makers to get things right, and they all have their issues. Nvidia’s got problems, ATi/AMD’s got problems …
05:10 JL: Any computer that has built-in on-board graphics is not going to do well in Second Life most of the time … Right now, we’ve just released 4.6.5, and let’s say next week Nvidia releases a new driver. We can’t test the viewer against that driver, because the viewer is already out. And quite often when video card companies come out with new versions, sometimes it fixes problems and sometimes it doesn’t. Rolling back drivers is sometimes something you’re just going to have to get used to doing, especially for Second Life. And that’s not just for us, it’s Second Life viewers in general.
JL: If you’re on Nvidia … and it comes with this Experience, and it scans my computer for games and tries to choose default setting for whatever games, because they have this database of games. I can promise you that SL is not in the database. They are not worrying if their graphics drivers are going to work for SL. So when there’s updates, it could cause problems.
06:36 JL: On the bright side, we now have the ability to … there’s a text file that comes with the viewer, if you look in the install directory, it’s called the GPU Table. It basically lists instructions for the viewer on how to handle different video drivers and video cards. We recently … made a change to that; we can actually update that table on the fly. So just like you get an update when we do a message of the day, and just like the viewer takes a look at our server to see if it’s allowed to be logged-in to [SL] … the viewer now also checks the GPU table that we have on the server versus the one you have in the installation and if there’s a new one, it will automatically download it.
JL: So, if a new video card driver comes out and we discover problems with it and you report it – we can’t do anything unless you report it – if you file a JIRA on it, saying this driver has got this problem, Tankmaster [Finesmith] is going to get hold of you through that JIRA, he’s going to take a look at the driver you’re using, he’s going to make changes to the GPU table on our server, and when you start the viewer, it will download those changes which make the viewer compatible with those drivers when we can do it.
08:37 Some merchants send out a note card saying to change your LOD to 4, like when wearing shoes.
09:19 EM: We generally recommend people leave their LOD settings at the defaults … the default changes depending on your graphics level, and the ideal is anywhere between 2 and 4, depending on your system … Even going just to 4, some people experience that necklaces and things just don’t rez because the level of details is too high for the small nanoprims to render. And there is no solid answer here. Generally, sculpties need to be created with a reasonable, sensible, level of detail.
12:02 JL: If you turn-up your LOD, you’re going to see things really nice … it’s also more complex because your video card is rendering more things … So if you want to take really nice pictures in SL, crank up your LOD; but it’s going to have an effect on the performance of your viewer.
12:55 JL: So what a lot of content creators do – and if you’re one of the content creators that do this, yes I’m pointing at you … is they want their stuff to look really good, so they’ll have their LOD cranked up really high …. and then they’re making their necklace or their shoes … and it looks really great to them, it looks really perfect and they package it up and they send it out. And people who don’t have their LOD cranked up, get that item and it looks like crap. And then the content creators says, “Oh, it’s because you have your LOD down too low; turn up your LOD and it’ll look fine.”
13:40 JL: Let me tell you something. If you’re that content creator, if you’re that person, you are doing it wrong. You make your content at a low LOD, and you make it look good at a low LOD level, and it is guaranteed to look good at a higher level … That’s the way to do it, because that’s how you make sure it looks good for everybody. not be making it to settings most people can’t use … you make your content based on a low LOD level, and that makes sure it’s going to look good on a low LOD level and on a high LOD level.
JL: Don’t tell people to turn their LOD up … it’s not good for them … because they forget they’ve turned it up and then they have really bad performance because they go to a region full of all kinds of prims and avatars with mesh and all these things, and their viewer performance is just utterly crap And they come to us and say, “Firestorm is a piece of crap. I just ran Singularity in the same situation and Singularity runs really well in the same situation!” But it’s not the same situation, because the LOD isn’t turned-up on Singularity …
JL: And that’s very common. People will compare one viewer with another viewer, not realising that they’ve changed a setting in one viewer that they haven’t in the other, and that setting has a huge impact on performance … Just leave the LOD alone in the viewer.
15:36 EM: The ideal setting for most people is between 2 and 4, which is why our LOD slider only goes to 4.
15;44 TS: And in fact, LOD is restricted in the viewer, there is an upper bound above which, no matter how high you set it, won’t make any difference anyway. My fuzzy memory tells me that number is four, but i could easily be wrong. i haven’t looked at that chunk of code in quite some time.
16:03 JL: If you want to do pictures, go into Preferences and crank-up your LOD. But when you’re done taking pictures, bring it back down again. Or just jiggle the graphics slider, because the LOD is affected by what setting you have in the performance slider. So if you choose low, it’ll have a lower LOD, and if you choose Ultra it will have the highest LOD that we would possibly recommend. But for content creators, drop your LOD when you make your content, make it look good on a low LOD and you’re going to be putting out a really good product.
16:57 TS: Which is why the defaults are good choice, because they’ve been tweaked pretty well … for most systems.
17:38 JS: Just generally speaking, we have had arguments, big arguments, internally on the team on what we should make default LODs. We try to follow along with Linden Lab, although seldom do we agree with Linden Lab’s defaults. We’ve spent a lot of time trying to choose what we feel are the safest LOD levels for each quality setting on the slider.
16:13 TS: Linden Lab has a lot more tolerance for low frame rates than we do and what our users tend to do.
18:21 JL: Firestorm is not the fastest viewer out there. Singularity is faster for most people from what I understand. The Linden Viewer is pretty quick, Catznip viewer is really quick, apparently. Firestorm is not a high performance Ferrari. It’s more like an RV, with all the bells and whistles and stuff …
00:00 Voice on Firestorm breaks badly and every word cuts off. Why?
00:04 EM: I wish I had an answer for you … I wish we could fix it, but those files come from Linden Lab, and we have no real control over them.
01:02 Would you guys be willing to share some insights and future plans (if any) for the projector feature? Specifically, how about a quick on / off preference setting applicable to a region perhaps that optimises them without groping around for fine tuning advantages, in order to make it a more “public” friendly feature?
01:29 JL: How many people know that there’s a [lighting] projector feature in the viewer? … it is the coolest thing ever …
[There follows a brief demonstration of enabling projected light sources and creating a simple spotlight - a detailed tutorial on projects can be found in my blog for details]
Using a transparent projector to cast as spotlight
04:44 JL: So, in answer to your question… the problem is that it is basically the highest graphic setting you have to have enabled in order to be able to see it. You crank everything up, and that is the tip of the mountain of biggest load that you can put on a graphics card. and in a busy place, it causes a lot of people to crash. just enabling shadows can cause a lot of people to crash.
05:36 JL: The problem is, you can’t just enable projectors. You have to have all these other things enabled first, because projectors requires Advanced Lighting, Shadows and all these other things. So it would be like us forcing on the highest graphics settings for people, even if their graphics cards are just going to overheat and melt, and we just can’t do it …
07:33 JL: There will come a time … when everyone has a computer that can handle graphics like projectors and shadows and stuff, and when that comes, we might have this discussion again and might consider enabling something like that. At the moment, we won’t.
You can use projectors to project a texture
08:15 JL: Remember earlier I said we don’t agree with Linden Lab’s defaults all the time? … Materials requires Advanced Lighting Model in order to see the materials stuff … Unfortunately, ALM has bugs and it does, on some systems, have an significant impact on the graphics card … so we don’t even turn that on in Ultra, I think … so we don’t necessarily agree with [LL] … And Linden Lab wanted us to make that a default for materials … and the argument was made to Linden Lab, more-or-less, fix the bugs with ALM, and we’ll be happy to make it a default.
10:26 JL: And ALM has a different impact on different systems. There are people on lower-end systems that will enable an option that has virtually no [negative] effect on them whatsoever, whereas if someone on a high-end system enables it, it will have a huge impact. Most of the time, we just can’t explain that. When we say it varies from system to system, I mean it really varies, and there’s not necessarily any logical behind how it varies.
11:00 TS: There is no set of “go fast” settings that you can just turn on. Let me rephrase that: there is – and it’s different for every system. The only way to find it is to start poking.
11:52 JL: Linden Lab get criticised a lot, and recently I got criticised recently for praising Linden Lab a lot, but I believe in criticising where criticising is due and crediting where credit is due, and Linden Lab has been doing a lot of good stuff lately, so they’ve been get kudos from me.
JL: Shadows is one of those things Linden Lab did early-on, and they did a fantastic job on it. Any of you who have used shadows, aside from the performance hit … and that’s just because shadows is way more graphics intensive. it’s just absolutely fantastic. You can get very real looking images out of SL if you’re able to crank-up all your settings.
12:45 I first experienced shadows with Kirsten’s viewer
12:47 JL: I’m glad you brought that up … You’ve heard me complain about Linden Lab working on stuff secretly, and they don’t even let us know, and they suddenly drop a whole load of code, “Surprise! We’re releasing this, and you got to try to get this out as well, as soon as you can!” So I criticise them a lot for working in secret. But there’s a reason why they do it, and it’s a learned thing.
JL: … Shadows is something they weren’t working [on] entirely in secret, they had a public repository for it … Some of you may remember Kirsten’s viewer, cutting edge kind-of viewer, always had the latest shiny, even if it wasn’t stable, released it first. He took the code and released it, whether intentional or not, he was widely regarded as the person who “invented” shadows.
JL: So Linden Lab, who had invested probably tens of thousands, may be hundreds of thousands, of dollars on developing shadows, get absolutely no credit or recognition or acknowledgement for having done that epic work for the community. So in some ways, can you blame Linden Lab for working in secret? It’s unfortunate, but it’s a learned thing … And I’ll continue to criticise them for doing it, but by the same token, I fully, totally understand why they do it.
14:48 Could you explain how streaming audio is handled in the signal chain? Does the viewer actually “touch” or optimise (dumb down) and audio source or simply hand it off to QuickTime?
14:50 EM: When you’re listening to an audio stream, you’re actually listening to it direct. It doesn’t really pass through SL … There are a few things that do not actually come through SL, and the big thing that people don’t realise is, they do not respect the bandwidth throttle in the viewer. For example: voice, video, as well as music, do not respect the bandwidth throttle.
16:30 EM: So if you have your bandwidth set higher than you should have, you’re going to have problems with them because there’s not enough bandwidth left over. And that’s even if you’ve got a great 100Mbit per second connection. The viewer can only handle so much, your hardware can only handle so much …
TS: The server can only handle so much.
17:01 EM: Realistically, if people start having music that cuts out or voice that cuts out and comes back, one of the first things we tell people to do is lower the bandwidth in the viewer, and see if that helps.
17:22 TS: If you’re setting your bandwidth over 1500, you’re doing it wrong; if you’re setting it over 1,000, you’re probably doing it wrong.
17:40 So the thinking that SL compresses streaming audio is a myth?
17:44 EM: The viewer does nothing with the audio streams. In-world sounds, yes. Audio, no.
17:56 With each new version of Firestorm, I have to hunt line-by-line through the new Preferences to find which ones are global and which ones vary by account. With 3 accounts across 3 computers, this takes as long as it used to before settings could be backed-up. I would advocate for two main preferences tabs; Viewer Prefs & Account Prefs.
18:41 JL: You remember Phoenix? … Phoenix Preferences were just horrible … you couldn’t find a bloody thing. So when we started Firestorm, we all agreed unanimously that we must ensure that we don’t make that mess with Firestorm. We inherited Phoenix from Emerald, and the Preferences were what they were … we didn’t copy / paste anything from Phoenix into Firestorm. we took the idea for a feature that was in Phoenix and re-wrote it from scratch to be much better, to be more efficient, to be more cleanly written, more responsible, more efficient performance-wise. Everything in Firestorm, we made great efforts to do it better than the way it was done in Phoenix, because Phoenix was a mess … [and] you could never find anything in the Preferences.
With over 40 tabs and sub-tabs, many containing a mix of options which might apply on a per account basis or globally or possibly both, refactoring Firestorm Preferences is no easy matter
JL: So we said with Firestorm, let’s not make that mistake again. Let’s make a plan for Preferences so that we don’t mess-up. Let’s keep things categorised and keep them in the right category … That is a lot easier said than done when it comes to a viewer that is as bloated as Firestorm is … I hate the fact that Firestorm Preferences have somehow turned into the same Preferences mess that Phoenix had, despite our efforts … So to address your question, can we separate them…
21:47 EM: You know what’s going to happen? We’ll decide, “Yeah, great idea, let’s refactor Preferences so that these are all per account, these are all global.” You’re going to have to go to two different places to adjust this or that or the other thing, because the Preferences will be related … However, that’s not the biggest problem.
EM: The biggest problem … is that Tonya thinks this particular preference should go here, Jess thinks it should go there, I’m sure it should go here instead … Let’s use the WASD keys for example. Should they be on by default, or off by default? Simple question, right? … It was a two week … heated discussion, internally, as to whether it should be on or off by default. And now you want us to refactor Preferences so that these are per account and these are global? …
24:10 JL: Preferences is a can of worms. There are some options that belong on more than one category, depending on how it’s used … There are options that will fit in to Preferencec > Chat or into Preferences > Firestorm > Command Line … and it all depends on how you plan to use it. Some options can be used in different ways, and depending on how you use it will determine what category it should probably fall into. So choosing where to put a preference becomes really hard … Everybody’s got a different opinion on where it should be. Not just developers and support people, but also users.
JL: We have made efforts in the past …[to] … reorganise it and structure it better and put things where they should be. I think we’ve done it twice actually; I’ll speak to at least the one time we’ve done it. When we release the update, if you think everything is hard to find now, wait until we’ve moved everything around for you. Ever had someone come into your room and put your stuff away, and then you can’t find anything? It’s that.
JL: The reason we sat down at the beginning and said let’s not mess-up Preferences is because once it’s established, we can’t just move stuff around. Once we’ve got it there, moving stuff around, it’s a disaster for the user experience because people can’t find anything … We’ve done that at least once … and the public reaction was bad.
26:51 JL: So we have public reaction to the way Preferences is right now, which is not a positive reaction, not even from me … But then we weight that out with changing them around, and the reaction is way worse. So we have to look at how to improve the user experience, that’s our mandate. Is moving Preferences the way it is improving the user experience? No. Is moving Preferences around going to improve the user experience much more? No …
28:15 EM: The big thing is, we all use the viewer differently … It’s like people saying “I wish you’d build a “Firestorm Light” which only has the basic features in it.” Well, the basic features for you are not going to be the basic features for me. So how do you decide?
00:00 Talking about Viewer updates… Has the team yet agreed on a particular time scale that you would ideally like to be able to roll out viewer updates?
00:01 JL: Ideally, I’d like to aim for every three months, and that’s more-or-less what that team has agreed on. We all agree four months, which is what we’ve been doing in the last two years … it just happens to fall into that way … is too long between releases … Except for support, who would be happy with a release once every 10 years, and then there are some developers who would like a release every day or every week, every month, every two months … and then there’s QA.
JL: So like I told you, the process we have [is] we don’t just say, “Hey! Let’s just release what we have right now!” and throw it out there. There’s a process involved. I have to give time for QA to find bugs. so we do the branch and we make a copy of our code base and that’s going to be the release. Then we start stabilising that; no more features. We call it a feature freeze, and it’s supposed to be no new features …
JL: Sometimes, something comes along that is a new feature in a feature freeze, but it has very low risk, in other words there’s nothing really that can go wrong with it, and it’s a pretty valuable thing. So it’s a pretty cool feature that we’d like to get out with this release. So a feature freeze is never black-and-white; there’s always some grey areas.
01:35 JL: So when we go into release mode in a feature freeze, I become the release manager, and I determine what else goes into that release branch … what comes new into our main repository, I decide what goes in [to the release]. So when we call it a feature freeze, it means no new features, just bug fixes.
JL: And when I say bug fixes, I don’t mean fixes that fix bugs in our main repository, I mean bug fixes specifically to the release branch. So the beta testers find a bug, a developer fixes it, I’ll pull that bug fix into the release branch, and that’ll be part of the release.
JL: So there’s a process involved, that QA gets it, they find bugs … we pull those bug fixes in, QA gets another build with those bug fixes to test the bug fixes themselves, as well as whatever else they come across. So QA needs to have it for a period of time. Internally, we have to have it for a period of time, then QA gets it for a period of time, and then eventually we throw it out to the preview group for a couple of days. If nothing comes up, it goes out. It’s difficult to do that in a short period of time, so I’m hoping we can do every three months; that’s the aim.
03:06 EM: the other thing that Jess didn’t mention is that with every new release, the wiki needs to be updated, the class notes need to be updated, and that can’t happen until we actually have a final version of the release. So if there’s a feature freeze, and a change gets made after we’ve started working on the documentation, we have to go back and change the documentation again. It’s a far bigger job than a lot of people seem to realise …
04:10 TS: And let me point-out also that 3-to-4 months is about as far away from a hard-and-fast number as you can get … and the reason it will vary from one release to the next is just with the size of the code change that we’re making. This next cycle is probably going to take quite a bit longer than average, because of all the heavy lifting involved in getting [project] interesting and getting some of the other changes merged-in to the code base. So don’t expect the next release any time soon, folks …
04:56 EM: The other part of that is, we got this one out in two months. Why did we get it out in two months? Well, because there’s not a whole bunch of new features and most of it is bug fixes. So this one came out in two months; the next might be four or five. Three is a good compromise … But I’m willing to bet you’re not going to see another release from us – barring some emergency that comes up – for at least another four months … That’s the thing. Some users want it updated every day, some people don’t want it updated at all.
EM: We’ve got so many changes from the Linden Lab code … the Linden Lab code is the closest of any viewer to what we have, but we’re miles away in things that they touch that our devs need to untouch them … It’s a nightmare …
[07:09 - end of audio pertion: There then follows a conversation on the internal discussions the Firestorm team has relating to releases, the disagreements which can occur, etc., all as a natural part of working as a team on a large, complex project. This can be heard in the audio, but for ease of reading is not reproduced here.]
00:00 Does Firestorm really have to be so option heavy?
00:16 JL: Out of all the requests we get, one of the most popular is, “can’t you make a ‘light’ version of Firestorm?” And Ed talked about this earlier … just a version with just the basic settings … I’ll tell you what, we’ve got around 300,000 users, somewhere around there … every single one of you has a different opinion on what those “light” settings should be.
JL: So the only way we could do that, the only way it could be done, is if it were done modularly. And people have asked for that type of thing for ever as well, a viewer where it’s just the Linden v3 viewer with no other options in it, maybe even not even v3 options; it just logs-in to SL and that’s it. Then you can download plug-ins for the different options that you want to use. In theory, that sounds fantastic, it really does. I would love that.
JL: Try, first of all supporting that. You just can’t support it … Second of all … it’s been done … LordGregGreg had … par plugins? … years ago … Greg had plug-ins that would plug into most viewers and give you some extra options. There’s a reason that never went anywhere … it’s just not really doable.
02:23 JL: It’s impossible to give you a “light” version, because it’ll never have the options you, yourself, want. You’ll say, “well, this is great, but I really want this option, and I really want this option,” and there will be 300,000 other people who will say, “well, this is great but I want that, and I want that…” and suddenly, you end-up with Firestorm again, which is where we are, which caters to everybofy … as much as possible.
03:03 I’m an advocate for USER definable prefs presets in the form of a transferable “thingie” You could make your own personal “FS light”
03:06 EM: You can. Learn how to compile. Learn how to do merges and back-out commits. You can have your own, personal viewer.
03:22 TS: About plug-ins and that kind-of thing. There’s a word programmers like to throw around, and it applies here. And the word is “re-architect”, and what it means is to take the basic design of the viewer, take a chainsaw to it, cut it up into little pieces, rebuild it, and then re-arrange the viewer on top of the new design. We could do that with Firestorm – but you wouldn’t see the results for about five years.
04;00 Back to nerve hitting…. Can current FS prefs stay as-is, but a new panel be added for Account Prefs only?
04:04 JL: We don’t know what we’re doing with Preferences. It’s a subject we don’t even want to think about any more … It’s going to come up, we’re going to have to deal with it again … and we’ll try to decide what to do about it.
Quick Preferences was updated to allow users to gain customisable, quick access to their preferred viewer preferences
04:31 JL: One of the things we came out with was Quick Prefs. And the reason we came out with Quick Prefs is because it kind-of falls into the “Firerstorm Light” – I just want the options I like. Quick Prefs sort-of gives you that, and it’s kind-of where it came from; to give you the options you want to change most frequently. And it’s customisable and you can take stuff out and put stuff in, of the Preferences that you want.
JL: Perhaps we could expand that an little bit. But it doesn’t remove the functionality from the viewer. There’s also the option that we could give you a blank Preferences panel and give you the debug settings and a little checkbox in the debug settings and you go through and decide, “I want to have this preference, I want to have this preference…” and it pops-up in your preference panel, and nothing else. But it’s still not going to be “Firestorm Light”, it’s still going to have a lot of features. All we’re doing there is hiding stuff in the UI.
05:31 EM: And as for another tab in your Preferences, for just per-account settings, for example, you’re going to have more duplication, and you’re going to have more people saying, “why should I have to go to a class to learn how to use the viewer and the Preferences?”
EM: We presently have a minimum of 44 tabs of preferences. Minimum. That’s on the Havok-only build, the SL-only build…
08:17 TS: An idea just struck me about the user preferences. How about we keep Preferences as they are, but add some kind of indication to each one, a visual way of separating the existing preferences as viewer-wide or per account? That might be doable.
08:42 EM: We actually have something close to that now. If you look at your preferences on the Back-up tab, the majority of the per-account settings are on the per-account tab … They’re not all listed, but most of them are.
Preferences > Backup provies a means of identifying groups of global and per-account settings
07:15 JL: So what about the idea of an expanded Quick Preferences?
EM: That and Tonya’s suggestion of a “G” or a “P” …
JL: You know, a panel where you can add as many or as little options as you want and you can customise and drop them in there … It’s not “Firestorm Light”, but it’s going to let you put the preferences that you individually use into one spot.
07:55 EM: Remember, you will have duplication. More so than we already do have.
08:02 JL: And if you come to support and say, “The option in Quick Preferences …”, they’re going to pop their heads off, because they’re going to say they don’t know what’s on your Preferences panel. Support will tell you to go to Preferences, the main Preferences. But it’s doable, that’s something that could be done.
JL: I’m not saying we’re going to do it, I can’t make a promise. It’ll need to have some thought put through it and we’ll need to consider how it can be done. One of the dangers of doing something like this is – and this came up when we were doing the Quick Preferences option – debug settings are dangerous.
08:45 JL: I don’t mean it’s going to blow-up your computer dangerous. I just mean debug settings … are quite often unexplained, or not explained well. There is so many of them, they’re not necessarily labelled to a layman’s term or something that you would understand or even a developer would understand. There’s plenty of times when a developers come across a debug setting and said, “What the hell does this do?” And I’ll just tell you, debugs are not ours. Well, some of them are [but most are from Linden Lab].
09:35 JL: So we generally don’t want people in the debug settings. Neither does Linden Lab [LL regard many debug settings as unsupported features]. That’s why the Develop and Advanced menus are hidden by default … We’ve got a feature in theire so you can search debug settings now, but it’s not because we want you to go in there, we really don’t want you in there, we even mess-up our own viewers playing with debug settings. So that would be one of the cons of … giving you such an expanded Preferences panel that’s just blank and you can add whatever you want … is that people would be adding things when they don’t necessarily know what it does, and then mess their computer up.
JL: And if we were to do that feature, and you came to support and said, “I’ve got this problem…” The first thing support is going to be telling you to do is wipe your settings, because that’s the only way they’re going to be able to start you from scratch to figure out what’s wrong. And probably I can almost guarantee you, every time you clear your settings, your problem will go away, because you’re playing with debug settings.
10:57 JL: When I say it doesn’t mean we’re going to do it, it means that we’re going to end up having an discussion internally about the whole concept of encouraging … you to play with your debug settings . We’ll have a discussion on the ramifications of making such a feature. Support will be less in favour of it than perhaps developers will … users will think its a great idea, support will look at how it will affect users in a negative way, and probably not be in favour of it. But … we’ll look into it …
12:23 JL: … It could also be one of those features we put a lot of work into, and they nobody uses. We have some of those, Linden Lab has some of those … Features that we expected would be really popular, that people have asked for ages for it. Contact Sets is a good example. For years people asked, “I want to have the ability to sort my contacts into categories …” … and LordGregGreg went and wrote it up, and it’s been re-written by Cinder, and you have Contact Sets, and it’s a little-known feature …
JL: And Linden Lab has done a few features like that, which have been highly requested, and they did it right … Linden Lab has made things that people have asked for, and ended-up nobody used it.
14:34 TS: I would argue that avatar physics is something they did get right … except the fact that they don’t get the credit is telling all by itself.
14:46 JL: Well, avatar physics is an example I’ve used with Linden Lab for argument’s sake, as one of those things whereTPVs drive innovation. Linden Lab came out with the shared experience policy, and some of my arguments were … Breast physics, which is what it was called in Emerald, which came out with it originally, was … a complete, hard-core violation of what would have been at the time, a shared experience policy. but it drove Linden Lab to do it properly.
JL: It was a hack back then, but by going out there and being popular, and by the fact a lot of people were seeing it and others weren’t, Linden Lab realised maybe they should be doing it. So it drove Linden Lab to innovate and do it properly.
15:44 JL: Because sometimes, TPVs can’t do it properly, we have to hack because we don’t have server access. Multi-attachments is another example. Emerald came out with secondary attachments, and it was a horribly ugly hack, and if you were on a viewer that didn’t have it, you saw people with stuff floating around their avatars and it looked ridiculous, it was terrible … and again, that would have been a shared experience, and one the te reasons by Linden Lab actually came out with the shared experience rule. But if it hadn’t been for that, we wouldn’t have the 38 attachments we have now, multi-attachments from Linden Lab … [They] did it properly, because they can, they have the server access.
JL: So some of my objections to the shared experience policy when it came out was, “what you’re saying is, then we can’t come up with a new idea and release it, in order to prove to you that users will love this feature. You’re taking away our ability, even if it’s hackish … to do a proof-of-concept. To demonstrate that something is worthwhile doing and worth the financial investment Linden Lab would have to make for it to happen properly.” So I was disappointed with that in that way.
17:21 JL: So LL’s argument to that is, “write it in the Linden viewer, do the feature in the Linden viewer, and contribute it to us.” Which in theory sounds all fine and dandy, and it sounds like you’re going to write it up and put it on the Linden JIRA and they’re going to take it and then it’ll be throughout SL. Unfortunately, it doesn’t work that way.
17:56 TS: And in fact, that is how the materials project happened. And it worked that way for quite a while, in most of the [viewer] development, then the Lindens had to pick it up and ended-up doing a lot of additional development and bug fixing … It turned-out pretty well, and it’s a good example of how the process actually works now … It’s certainly not an argument for never again doing it that way, but by the same token, it’s a bit of a cautionary tale.
18:41 JL: Well not only that. In some ways the materials project was a proof of concept to demonstrate to upper management that working with TPVs, together, on a common goal, on a common feature, can actually benefit everybody equally at the same time, as opposed to working alone. And LL has come quite a way even since then, even before that, in … allowing us to work with them for testing things, for example. We were able to help them with testing avatar appearance changes … the Vivox changes … various things. So progress is being made in the area of cooperating. We’ve always advocated that Linden Lab working privately on their own on a feature without include us, is less beneficial to Linden Lab than working on a featuring including us and letting us help them with it. Let us test it, letting us help them with the viewer code while they do the server code, anything like that is actually beneficial to everybody.
JL: By doing that, it also allows us to provide feedback to Linden Lab from a user’s perspective before it’s on paper. Once it’s released, once Linden Lab has the code out there, and it’s public, it’s unlikely that they’re going to change it. So if Linden Lab does something, and we understand what SL is, because we’re residents … and they won’t necessarily use the feature the way we will. So working with TPVs is beneficial … the criticism we want to try to provide is, “this really nice, but as a resident, it would be even better if it did this…and we can help you with that.”
28:59 JL: