On Saturday Devember 14th 2013, the Firestorm team hosted another informal question-and-answer session. While the meeting was recorded, the Firestorm team are aware that many of their users have hearing difficulties, and / or prefer to read text. It is because of this that this transcript has been provided.
When reading it, please remember:
This is not a word-for-word transcript of the entire meeting. While all quotes given are as they are spoken in the video, to assist in readability and maintain the flow of conversation, not all asides, jokes, interruptions, etc., have been included in the text presented here
If there are any sizeable gaps in comments from a speaker which resulted from asides, questions to other etc,, these are indicated by the use of “…”
Timestamps are provided as guidance should anyone wish to hear the comments in full from any speaker on the video
Questions /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.
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.
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.
Main Discussion:
The next release: will most likely be a stabilisation of the code currently in 4.5.1 rather than introducing major updates, although this is still to be determined. LL have a lot coming down the pipe, which Jessica was hoping would be ready for inclusion in the next release, but that is looking unlikely unless something significant happens to change things [0:00:25-0:02:48]
Response to the beta has been good, around 120,000 downloads, of which around 6,000 are for the Windows 64-bit version. A number of people have subsequently reverted back to the 4.4.2 release due to issues. There are significant issues with voice, Mac users have encountered issues arising from Cococa (Mac and Voice issues covered later as well).[0:02:48-0:06:03]
Reference is often made to “Linden Bugs”. This does not necessarily mean they are the Lab’s fault; it simply means that the SL viewer has the same issues [0:06:03-0:06:53]
Firestorm releases are currently roughly four months apart. Ideally this should be two months, which is a target, but needs to be balanced with the risk of overwhelming the support volunteers (who need to both learn and support new releases). Therefore, it might mean a compromise of a release every quarter [0:06:53-0:09:40]
Voice issues: Vivox problem, LL have it as well. Firestorm have a series of videos demonstrating the problem. If a user on FS 4.5.1 beta has the issue, the recommendation is to revert to the 4.4.2 release [0:09:53-0:10:46]
The FS Windows 64-bit has been well received and feedback has been positive. Most people are reporting imporved stability rather than improved performance compared to the 32-bit version [0:11:10-0:12:56]
Oculus Rift is coming to Second Life [0:13:10-0:15:27]
Leap Motion is coming to Second Life – and the Firestorm Team have taken a lead in the integration work with the viewer [0:15:27-0:22:49]
Firestorm 4.5.1 beta and Firestorm release numbering explained [0:23:02-0:26:35]
Why Firestorm block versions and why Phoenix isn’t currently blocked [0:52:02-0:58:41; 1::0036-1:02:56]
Firestorm Q&As qill be monthly from January, alternating between 08:00 SLT and 16:00 SLT month-by–month [1:12:03]
Q&A Session:
Would it be an option to have different branches for people to download …? – includes discussion on why FS does not have nightly builds and on joining the FS beta testers [0:27:56-0:37:32]
Can we hope for more tattoo layers? [0:37:35-0:39:19] – reply includes reference to Linden Lab User Group meetings, the forums in which such questions can be asked
Will the new version [of Firestorm] be in 64-bit, and is Fitted Mesh coming? [0:40:00-0:47:40]
Why is IM and local chat so laggy in the beta version of Firestorm? (Mac build) – known issue, with both Firestorm (FIRE-12172) and LL JIRAs raised against it [0:47:40-0:49:47]
Why will music streaming not work on 4.4.2 with the new Mac OS upgrade? – Mac OS X 10.9 Mavericks issue reported under FIRE-10630 There is also a list of Cocoa bugs specific to the Mac build [0:49:47-0:52:02]
Dealing with inventory “jump” issues and bug regressions [0:52:02-1:00:36]
Are older versions of Firestorm also blocked from OpenSim when they are blocked from SL? – any version prior to 4.4.2 will unfortunately be blocked from OpenSim when blocked from SL. All versions of FS from 4.4.2 onwards can be individually blocked from grids [1:02:56-1:04:13]
Has the FS team ever considered working on a mobile Firestorm product? – includes the FS April Fools from 2013, and accessing Firestorm remotely [1:04:16-1:10:17]
Has the FS team considered “drawing a line” on how far they’re veer from the LL codebase (e.g. additional feature input, etc.), in order to improve the release cycle and lessen the maintenance overheads? [1:13:20-1:21:01]
What drives the FS team to do what they do? [1:21:40]
0:00:00 Jessica Lyon (JL): Welcome to our last Q&A of 2013 … I don’t have a lot on the agenda … So I’ll just touch on some of the more common points. I hope you guys brought questions!
0:00:25 JL: So … what’s coming next? A lot of people are asking if we’re going to have out 4.5.1 beta out in a release soon, and the whole team is a little hung-up on that right now, as to what we’re going to do next. And in part, that’s my fault because what I want to do is not necessarily what the rest of the project wants to do.
0:00:50 JL: What I would like to do is get Linden Lab’s latest Server-side appearance changes and inventory changes into out next release. However, they’re taking quite a while to get this out. I also wanted to get all their other stuff, like the interest list work, group bans – they’ve got a whole bunch of stuff coming out – HTTP; I was hoping they’d have this all out in time for us to get it into a release, and that the beta would just hold you over for a month or two. But … it’s taken Linden Lab a little bit longer to do these things, and considering there’s a period of time from when they make these things public to the time when we can actually get that code merged-in to Firestorm … and then we’ve got to stabilise and fix; then usually while we’re in that process, Linden Lab finds lots of bugs and they start working on fixing those bugs, and those fixes are kept private until the last minute and then they release those. By then we’ve already released [Firestorm] … so it’s a convoluted, complicated pain in the butt.
0:02:15 JL: Since Linden Lab’s taking longer to get these things out, I think I’m going to end-up being overruled. We’ve got a dev meeting on the 4th of January, and I have a feeling I’m going to be overruled by the team in just trying to stabilise what we have in the 4.5.1 beta. And by “stabilising”, I mean not necessarily catch-up to Linden Lab, but just work on the biggest issues that showed-up in that beta that people complained about.
0:02:48 JL: Although it works really good for some people – it works great for me – there are a lot of people who can’t use it. There are quite a few who have gone back to 4.4.2, our official release, and we know this based on how many downloads we’ve had of the beta versus how many people are still on the beta now, given Linden Lab’s latest statistics …
0:03:32 JL: Firestorm beta: 112,000 and then another 6,000 on the 64-bit. So roughly 120,000 users are on the beta, but there’s more than that in downloads; so we know some people have gone back to 4.4.2.
0:03:53 JL: I know that [the] Mac [build] has some problems with the public beta, and that’s related to Cocoa; you Mac people might be familiar with that … there’s a bunch of stuff that came in from Linden Lab that we merged-in which we released in the beta which caused problems.
0:04:13 JL: Voice … the voice problem seems to be stuttering; some people have it, some people don’t, and we’ve brought it up to Linden Lab abd they’re interested in working with us to try to track that down. But I have a feeling that what’s going to happen is, we’re likely going to revert to the previous Vivox version, just because we know that worked, and the new Vivox version doesn’t seem to be any more secure or stable … we can’t see any improvements, anyway. So if an older version works, and the new version has no benefits over the old version, then we might just as well go back to the old version until the new one gets fixed. So we might revert that.
0:0522: JL: So the chances are, like I say, that I’m going to be overruled and it’s going to be decided that we’re going to fix-up the beta into an official release status. Timing on that, because everyone wants to know when that’s going to happen. Well, as soon as it happens.
0:05:34 Whirly Fizzle (WF) – via chat: Some rendering glitches that came with materials and the ribbon particle feature.
0:05:47 JL: Of course, the beta has the materials stuff in it; that is not without bugs.
0:05:55 Miro Collas (MC) – via chat: SLurls
0:05:58 WF: V3 has the same bugs though
0:06:03 JL: When I say, “They’re Linden bugs,” I don’t mean to say, “Linden Lab caused this problem! It’s all their fault!” I just mean that the Linden viewer has the bugs as well, and so we inherit those bugs; some [of those] bugs we can fix and send back to Linden Lab, and there are some bugs that are over our head; they fly over in the stratosphere, and we’re not able to fix those.
0:06:29 JL: Usually when you come across a bug that stays there for three or four versions, three of four releases – and with our schedule, that’s like over a year – and you’ve had the same bug, usually that’s up in the stratosphere and way beyond our capability to fix, and Linden Lab is a bit busy and not able to fix the issue.
0:06:53 JL: As far as when the next release is going to happen: your guess is as good as mine. What I’d like to do is have more frequent releases, I’ve said this a billion times; it’s difficult for us sometimes to get more frequent releases out. Right now we’re averaging four months, a release every four months, which is horrible; even though our goal every time is two months. I’m hoping for 2014 we can change that, [but] there are a few problems.
0:07:24 JL: When you have a support team, putting out more frequent releases becomes a problem for them, because releases are support nightmares. We get hammered wit, “Do I have to do a clean install?”; “How do I do this?”; “How do I do that?” Quite often during an update, something changes or isn’t working quite right, and it’s the busiest time for our support when we do a release.
0:07:52 JL: So we have to find a compromise somewhere. Four months is too long, two months is maybe too quick, too short; support is interested in doing a release every three months, but the reality could be two.
0:08:23 JL: The other thing is we have users who would like to have a release every day, and then we have users who prefer to update once every ten years; I think a lot of our users prefer not to update. And that’s evident in that we had to block a whole bunch of our previous versions that were so old, they didn’t even render mesh or avatars or anything, and there were still a lot of people running them. We have users who just don’t want to update, ever, at all, never; even if it means Second Life is completely broken for them.
0:09:09 JL: So every two months would be nice from a development standpoint, but might be too frequent for most of our users; every four months, our current rate, is way too slow. Every three months? That might be the compromise.
0:09:27 JL: So our first [team] meeting of 2014 is January 4th. We’ll discuss things there, and then we’ll have a Q&A at some point after that to which I can give you some idea of what our plans are from there.
Audience comment: The voice stuttering is a major problem for me. the stutter is often so bad that you can’t understand
0:09:53 Ed Merryman (EM): Revert to the 4.2.2 release. That’s what I’ve had to do.
0:09:57 JL: 4.2.2 is still the official release. So while we encourage people to use the beta, if it doesn’t work for you, go back to the 4.4.2.
0:10:07 EM: We actually did a video, Whirly and I, showing on her end and on my end what happens with the difference between the old voice files and the new voice files, and people now understand why the new voice files are just unusable for me, because half the time you just can’t understand what’s being said. I’ve reverted to 4.4.2 and that’s what I’m recommending people do.
Videos demonstrating the audio break-up issue using the Second Life viewer and Vivox 4.5.0009
0:10:38 JL: If you have voice issues.
0:10:40 EM: Yeah, if you have the issue. If you don’t have the issue, don’t sweat it.
0:10:46 JL: If the beta’s working for you, more power to you. 64-bit: everyone seems to love it. We’ve had lots of feedback, I apologise that I haven’t put all that feedback into a public document yet, but I will soon, probably over the next week, and I’ll do a blog post so that you folks know where that is.
0:11:10 JL: We’ve had a few people say performance is better, but most people … if I had to throw together a consensus on the results of the feedback … is that it might be a little bit faster than the 32-bit; maybe a little bit. It’s certainly more stable. So for the people running the 64-bit, they’re pretty much all agreeing that stability-wise, it’s better. So it would seem to me that the advantage of the 64-bit is stability, not performance.
0:12:56 JL: So, that’s where we are with our next release … we’ll start working on that and making decisions in the new year.
0:13:10 JL: As some of you know, Linden Lab has been working on the Oculus Rift … and there’s actually a viewer out there already called CtrlAltStudio, which is based off of Firestorm, and He’s working on providing Oculus Rift support. No, I don’t know if Linden Lab has used contributions or not from that viewer … So I understand that Linden Lab is working on Oculus Rift … so you can put on a pair of goggles and you can see Second Life from a 3D perspective through the goggles, which sounds pretty cool.
0:14:32 JL: There are some problems with that, perhaps the more obvious being the user interface has to change. Also, how are you going to click on something when you can’t see your keyboard or your mouse? So you’re reaching around for your mouse, that kind of thing.
0:14:48 JL: So Oculus Rift support is coming. That doesn’t mean you need one, but if you want one you can buy one.
[Currently the Oculus Rift isn't available as a commercial package; units currently available are the developer version, costing $300 plus local taxes, and which includes a software development kit. The commercial version will be available in 2014.]
0:15:25 WF: LL’s rift viewer is coming soon from what they have said. Soon after new year probably [see my reports here and here on the upcoming viewer release]
Firestorm are taking a lead on Leap Motion integration
0:15:27 JL: That ties-in to another thing .. There’s a thing call Leap Motion, which is fundamentally a little camera facing up, and it watches your hands … I’m also told they’re making a keyboard that has the camera built-in to it … they came to Linden Lab, and they said, “We’ll give you a couple of controllers if you can integrate Leap Motion into Second Life”. To which Linden Lab said, “Hey, that’s pretty cool stuff, but we don’t have any developers to work on that. However, we know of a few third-party viewer teams who might be able to. And not the last meeting but the one before, with Linden Lab and a few third-party developers, to which the Leap Motion people came and did a sort-of a pitch, and long story short … we’re going to be integrating Leap Motion into Second Life.
0:17:21 JL: Cinder is going to be in charge of that integration; Ansariel will be working on it, Tank will be working on it; Whirly and Lassie are QA … So Cinder’s going to be working on that leap Motion control …
Simon Linden first demonstrated the potential for Leap Motion gesture control in Second Life in February 2012
0:19:52 JL: We can set it up to trigger gestures which can in turn make your avatar do animations and various things. Object interaction is probably the most potential thing … where you can virtually hold a cube kind-of in your hand, and you can move that prim, that linkset around and maybe even edit and build and do things with your hands. That would be really neat. And LSL interactions and camera controls.
0:20:20 JL: Lassie already has a Leap Motion controller, and if you see him flying into walls and bumping into things, it’s because he’s experimenting and finding that certain hand movements can cause you to bump into walls and fly into things.
[Region mass disconnect #1]
0:21:08 JL: So Leap Motion is coming, or Leap Motion support is definitely coming … and the idea behind that is that we’ll do the integration, and then we’ll contribute that back to Linden Lab so that it makes it into the mainstream of Second Life with the hope that all viewers will pick it up. So leap Motion is definitely coming. Oculus Rift is coming because Linden Lab is working on that, and so that will be in the mainstream soon.
0:21:45 JL: We have a JIRA in regards to Leap Motion. There’s a chance the some of you may have some other ideas for integration; things that Leap motion can do, or that we can make Leap Motion do. So if you have some ideas, feel free to leave a comment on that JIRA, and we’ll be able to tell you if it is a good idea or a bad idea, can work / can’t work; there are limitations to what can be done.
0:22:49 JL: Do we have anything else before I get to questions?
0:23:02 Lette Ponnier (LP): There’s a different side of something you brought-up really early-on which was asked by somebody to be raised at the Q&A … You talked about plans for the next release, and here’s a support angle on the question which often comes up, “When is this beta going to be not a beta?” … There’s often a misconception that a specific build of the viewer, after being released as a beta will somehow stop being a beta at some point and transform itself into a full release, and some people may be… waiting for that confirmation that, “Oh, it’s not a beta any more, it’s an actual release.”
0:24:15 LP: That doesn’t work in the way that betas and full releases happen in this team. So for those who are waiting for a full release that has the features and the fixes that 4.5.1 has, but not the bugs, you’re going to be waiting for an actual new release before that happens. The 4.5.1 will only ever be the 4.5.1 [beta]. The devs do the work, and then a new build gets put out, and then the devs do more work, and a new build gets put out, and that’s the way it works … and the 4.5.1 that is currently available for download is not suddenly going to have different code in it.
0:25:21 JL: In fact if we magically turn 4.5.1 into a release, it would be 4.5.2, or 4.5.3, and our naming scheme is somewhat dependent on how much code goes into something in between releases. So if we have just a little bit of fixes in our next release from 4.5.1, it’ll be a 4.5.2. But if we merged-up, for example, Linden Lab’s Server-side Appearance changes, we’d probably call it 4.5.8 or even 4.6 or something along those lines. And it’s somewhat random.
025:10 Mister Acacia (via chat): If memory serves, we did change one from beta to release, but that was very early on in the project.
0:25:14 JL: I vaguely remember that as well. I think that in that case what happened was the version was released as a beat because we weren’t really sure how it was going to do, and it turned out it was just fine; in this case, 4.5.1 is not just fine, so that isn’t going to happen here.
0:26:32 JL: The thing is, we didn’t do a lot of QA on 4.5.1 … I overruled Lassie and said I’d like to get something out before Christmas. And it seemed to be fairly good for most of us, so we got the beta out. And it’s not terrible; I mean we do have 120,000 people running it every week … we could have called it a release, and you guys would have seen it as maybe not as good a release as 4.4.2 was.
[Region mass disconnect #2]
Questions and Answer Session
0:27:56: Would it be an option to have different branches for people to download, like debian stable, debian unstable testing, and support only has to support the stable release?
0:28:08 JL: There’s a couple of variations to the answer on that; there’s actually a couple of questions in there. First of all, when we say we’re not supporting a version, it doesn’t change a thing. If we say “we’re not supporting this anymore,” it does not stop people coming to support and asking for help, and pretending they’re on a version that they’re not really on … Let’s say we stop supporting version 4.4.0 – we’re not – let’s just say hypothetically that we’ve stopped support and we’ve made this public and we’re no longer supporting it. People will turn off the version identifier in their viewer before they come to our support group and they’ll ask for support, and they’ll try to say that they’re not on that version. Also, and for those who don’t, and who are actually honest, they’ll come in and we’ll see they’re on 4.4.0 and they’ll ask a question, and quite often, we’ll be able to answer that question and it may not even be 4.4.0-specific problem
0:29:25 JL: So it’s difficult for us to not help that person; we just feel morally obliged to help them. So there’s the whole moral issue; it’s very difficult to say to somebody, “I have the answer, but I’m sorry I can’t help you because you’re on a version you’re not supposed to be on.” … It’s a lot easier to say we’re not going to support something than it is to actually not support it.
0:29:52 JL: Also, let’s assume we have no empathy for people, and assume we have no concern about other people, and let’s say we stick to our guns, and all these people on 4.4.0 come in for help, it takes just about as long to type “I’m sorry we can’t help you because you’re not on the right version,” as it would to type the answer to their question. So as far as that part of the question, there’s that problem.
0:30:29 JL: The other problem is that we don’t do branches. We do sometimes put out our public betas, sometimes it’ll be a release candidate … that last one was a beta as we didn’t think it was good enough for a release candidate … And then there’s the notion of nightlies. And there are some people on the team who would like for us to have nightlies, which are public builds based on whatever we have done up to that day. There’s a couple of problems with that.
0:31:44 JL: First of all, quite often our developers will commit code that isn’t finished, and a nightly could be horribly, horribly broken.
0:31:54 JL: Secondly, although we can say we don’t support people on nightlies, I’ve already pointed-out the problem with that.
0:32:00 JL: Thirdly, we have a support team … so we have to weigh-out what we do from a development point-of-view and what we can do from a support point-of-view. We have to work out how one department is going to affect the other department. So if my developers want to push out nightlies, I have to consider how that is going to impact my support team. And if it means my support team are all going to get up and go on strike or rage quit, then probably doing public nightlies is not a good idea … nightlies are not the best thing for us .. so that’s why we don’t do that.
0:33:54 JL: What we do have is a QA team. We’re not using our users as unintended beta testers, we prefer to have a team of beta testers and a management team to manage those beta testers and to manage the results and to compile and work out what’s working, what’s not working, to determine whether or not something is safe to put out to the public that is not going to destroy our support department.
0:34:32 JL: So we’ve got three main departments. We’ve got support, we’ve got development and we’ve got QA. And departmentalising, I think, works quite well. If you’re interested in getting untested stuff … there’s information on where to apply to be a beta tester. And I will give you a heads-up warning: it’s not all fun-and-games. If you’re one of those people who doesn’t like to do a clean install and clear your settings and stuff, beta testing’s not going to be for you. If you’re one of those people who thinks beta testing is just installing a new viewer and running around Second Life with it, beta testing might not be for you.
0:35:20 JL: Beta testing involves answering what we call “smoke tests”, which is basically a test page where you have to reproduce and do things. You have to follow instructions, you have to test something using a set of guidelines, that kind of thing. And you have to report back on your findings. But if you’re up for that, join it.
0:35:48 JL: You don’t have to be an expert technical person to be a beta tester. In fact, we like to have a variety. We like to have people who are completely non-technical and we like to have people who are very technical, because that gives us the full spectrum of what we have in Second Life. so having non-technical people in there is useful for introducing a new feature and we won’t tell the beta testers how it works; we want to see how the technical and non-technical minded react to that feature, to that interface, to that design, to that layout, and that gives us an idea if we should make changes.
0:36:28 Tonya Souther (TS): Oftentimes the best bug reports we get and the best testing we get are from the non-technical, because technical people have an idea of how things are supposed to work and they tend to use things in those ways. Non-technical people, on the other hand, will just dig-in and poke at it and try it and just generally try to do things in ways that we don’t expect, and that is very useful for uncovering bugs that nobody on the team even thought about.
0:37:35: Can we hope for more tattoo layers?
0:37:37 JL: that’s not a question I can answer. that’s a question for Linden Lab. I would expect not, though … simply because Linden Lab is doing a whole lot of stuff right now …
0:39:19 JL: I hear a lot of people say, “I’ve never met a Linden before.” there’s no reason for you not to have met a Linden. They have User Groups, which used to be called office hours, and the public is invited to these things; that’s why the hold them. They want your feedback. And so for people who say Linden Lab never listen, actually they do. Sometimes they don’t act on what they hear, but they do listen. And the chance to have them listen is to go to their user groups.
0:40:00: Will the new version [of Firestorm] be in 64-bit, and is Fitted Mesh coming?
0:40:11 JL: We will have a 64-bit [version] with our next release, and I think it will be supported, just like the release. We only used “Alpha” for that because it was completely untested. We gave it to the beta testers for two days or something; it was brief … two days is not enough time to beta test it. Basically, they had time to install it and tell us if the installer worked; that was about it! So it went out as an alpha. And also, we didn’t know if it would be faster, slower, stable, unstable…
0:41:15 JL: I guess I should mention the stability aspect of it … I can tell you the 64-bit has a 4.5% crash rate, which is the most amazing crash rate ever – except that it’s not right … it’s not reporting to Linden Lab all of the crashes. Which was a real disappointment, because we were really hoping, we really wanted to find out what was the stability of it compared to the 32-bit counterpart … Anyway, we ended up not reporting crash rates correctly on the 64-bit or the 32-bit for that matter. So we don’t actually know what the correct crash rate is for 4.5.1. We have that fixed now internally, and the next release will have that fix.
0:42:34 JL: Generally, when we put out a release, we hear lots of people saying they’re crashing. And even though that’s a small percentage of people, we hear a lot of it; and when you ask people for feedback, you can expect, unequivocally, a lot of people to say it’s crashy. And in all the feedback we’ve received from users … nobody has complained about crashing; and in fact we have a lot of people saying it’s not crashing, it’s very stable. So that’s how we come to the conclusion that it’s more stable than anything and that is probably the main benefit to having 64-bit.
0:43:19 JL: Also worth noting is Singularity had their 64-bit out shortly before we did, and their crash reporting is correct, and it is more stable than the 32-bit counterpart … So we will have a 64-bit official release along with the next official release.
0:44:01 JL: Fitted Mesh: yes, absolutely … and you know what’s even better, and remarkably better, is that it’s done with very little code. Linden Lab basically did Fitted Mesh, which is basically what the mesh deformer was supposed to do, and they managed to do it with very, very little code, and Kudos to Linden Lab.
0:44:28 JL: You guys may recall, I think it may have been one or two Q&As ago, somebody asked about the mesh deformer and if it was coming, and I think I said something like, “Don’t hold your breath for the mesh deformer, but there may be something else in the works”, and that’s what I was talking about.
0:44:47 JL: The mesh deformer is not going to happen [but] it is still working on OpenSim, I believe, and I don’t know if Fitted Mesh is going to work on OpenSim or not … And also, those of you who follow our Q&As might remember me being teased about a certain pair of jeans that I was very depressed to have learned that they may be broken at some point in the future. Hallelujah! My jeans are safe! Anything with Liquid Mesh, it was worried that Linden Lab might break that, instead Linden Lab decided to use that methodology for Fitted Mesh.
0:47:40: Why is IM and local chat so laggy in the beta version of Firestorm? [Mac]
0:47:47 JL: This is new to me.
0:48:05 LP: It’s actually a chat entry lag. It’s really aggravating. I just got a new Mac and I’m not experiencing it very badly, but on my older one, and it was terrible. It slows the length of time for the words that you’re typing to show-up on your chat line, and anything else you’re trying to do in the process is inhibited as well … I had a habit of derendering the world if I’ve experiencing very terrible lag, the CTRL-ALT-= to get rid of everything. The lag is so bad, that doesn’t even work.
0:48:52 WF (via chat): FIRE-12172 ([MAC only?] [BUG-4121] [ MAINT-3357] Intense chat lag when in an area with a dozen avatars )
0:48:56 JP: It won’t work until everything that I type shows-up and then it opens-up and says, “OK you can use your keyboard for something else now”, and then it’ll happen … So it’s a Mac bug, and as Whirly put into chat, there is a report on it both for us and for Linden Lab, because that’s where it came from. So if you’re experiencing that, and you want to keep track of the status on that, take a note of the JIRA.
0:49:47: Why will music streaming not work on 4.4.2 with the new Mac OS upgrade?
0:49:54 WF (via chat): Known issue: MAC Mavericks OS X 10.9] Parcel radio streaming unavailable with Mac OS X 10.9 Mavericks
0:50:00 LP: It is a known issue; it’s been with us as long as Mavericks [Mac OS X 10.9] has been with us; All you can do is upgrade to 4.5.1. That is the one group of people who are screwed with the two versions, because if you’re on Mavericks and you want to listen to music in-world, you have no choice but to be on 4.5.1, but then you get all the other annoying matters.
0:50:25 JL: I was going to say 4.5.1 has all sorts of other bugs for Mac.
0:50:29 LP: Particularly for Macs … So 4.4.2 you’re simply not going to be able to have music, sorry.
0:50:47 WF (via chat): Basically Mavericks needs FmodEx to stream music. 4.4.2 uses Fmod not FmodEx.
0:50:47 JL: And that’s a Linden issue as well.
0:50:49 LP: Or roll back to Mountain Lion [OS X 10.8]. You can do that, too. Those are your two options.
Audience comment: workaround is to use your external music player.
0:50:59 JL: It’s worth mentioning that 4.5.1 works better with Mavericks because Cinder happens to do development for Mac, and she had Mavericks in her hands months ago, and had already been committing changes and improvements and fixes into Firestorm leading-up to the 4.5.1 release to make sure it would be compatible with Mavericks. Unfortunately, 4.5.1 does have a huge list of bug because of FmodEx and Cocoa for Mac people, and I feel for you guys. And I cannot promise we’re going to have all that fixed when we go with our next release.
0:51:58 WF: List of all Mac specific bugs due to Cocoa.
0:52:02 JL: Worth noting: the next release after that, 4.4.0 is going to be blocked because we’re keeping up with being only three version behind. I suppose it’s worth mentioning how the block went: incredibly well, aside from a lot of people complaining in our blog comments.
0:52:28 JL: I should actually explain something about the blocking … I stated that Linden Lab was putting pressure on us to get people off of the old versions, and it got taken a little bit out of context from what I was trying to say. They are a little bit upset that we have people on versions that do not support mesh or Server-side appearance …
0:53:10 JL: They really want to get third-party viewers on their update system … If you use the Linden viewer and you go to log-in one day, and suddenly you get a thing that says there’s an update available, and I believe it makes you update it; it forces you to update. It’s not a great system, and I really dislike how aggressive it is. And what happens is, if you update to it, and I believe it doesn’t give you a choice, you have to update, and it does it semi-seamlessly; unlike us, you don’t have to go to the website and all that stuff. Theirs downloads automatically, and that’s nice. But if you log into it for one reason or another, and you cannot use it, because it’s horribly broken for you, for whatever reason … unless you know hackery, you’re stuck; you can’t go back.
LL’s auto-update system is seen as overly aggressive by the Firestorm team
0:54:20 JL: There are ways around that, but if you’re not technically-minded, you’re not going to know how to do that, and then you’re just screwed and you have to wait until next week, or the week after that to try the next update that they have. And if that doesn’t work, you have to wait for the next week or the week after that … and I just find it overly aggressive.
0:54:53 JL: So people are complaining that we are being aggressive, why should we dictate who gets to use what version; why should we be able to say that? Well, first of all, because it’s our viewer, I don’t want to sound obnoxious. Second of all, we’re getting tired of having linden Lab rubbing my face in the fact that we had thousands of people on really old versions, which would be eliminated if we would use their update system. Every week I had this coming at me, “I’d like to put you on this update system” … and I kept responding with, “We’re perfectly capable of keeping our user base up-to-date, we’ve just not come to a point where we felt it was necessary to do that yet.” Well, we came to that point. And so we blocked eight versions, there are obviously a lot more versions out there that are self-compiled versions that are not ours, that Linden Lab believed that they were, because their channel names are similar, but they are definitely not ours …
0:55:58 JL: So, the alternative, if you were one of those people complaining that we blocked eight versions, the alternative would have been to give-in to Linden Lab and every time we do an update, have you forced to update and give you very little ability to roll back to another version. You would have one version to run at any given time … at least we’re giving you three. Because we know that sometimes we’ll put out a version that doesn’t work well for you. It might work well for others, but not for you. So some people aren’t able to upgrade. I hope that within three versions we can fix that problem for you, so you can use it again. So that’s what that was, and I hope I explained that well.
0:57:03: Did they really tell you directly and in plain English that they have a problem with users on old versions or is that kind of an assumption made?
0:57:11 JL: Yes. They did not want to have people ob old versions that do not support latest code. So here’s some other comments that came up in the blog comments; “No other viewer has been told that.” Well, I’ll tell you why. We had more users on version that did not support server-side appearance [approx. 64,774 users] than some of the most popular third party viewer have altogether. So they’re going to be harder on us than they’re going to be on some of the other third-party viewers.
0:57:52 JL: Firestorm has a lot of users, so we’re held to a higher accountability than the other third-party viewers are by Linden lab. We have a higher responsibility than perhaps the other third-party viewers have, and Linden Lab lays into us sometimes. It’s a give-and-take relationship we have with Linden Lab; I’ll give-in to them, and sometimes something will come up, and I’ll lean on Linden Lab, and sometimes they’ll give in. So it’s a give-and-take thing, and I think their request was sensible and reasonable. They want people in Second Life to be on viewers that support current code; there’s nothing wrong with that.
0:58:41: My wife does an inventory search and about halfway down it will reload. She has turned off all friends logging in/out, etc. and it still happens. Any ideas how to stop that. She is on 4.4.2
0:59:00 EM: Yeah, it’s doing the jumping thing. Open a second window … Open a second inventory window and work on that one instead of the first. It’s the first one that jumps on you, if I remember correctly.
0:59:20 JL: So open a second inventory window, and you don’t have that problem?
0:59:26 EM: You won’t have it in the second window; you’ll still have it in the first one.
0:59:40 JL: Actually, that bug regresses a lot. We used to have it, and it was caused by people coming on-line, and we fixed it and then I think we merged with Linden Lab and it regressed. And it’s not a Linden Bug, I don’t believe, but we had a regression with it when we did a merge; it’s just one of those bugs that keeps coming back. It’s like a cockroach; you can’t kill it.
1:00:28 WF (via chat): It used to be a V3 bug. But again, some do get it on v3. It’s a mystery why some people get it and some don’t.
1:00:36 JL: I should mention Phoenix … getting back to the blocking thing. We’ve had a lot of people ask how come we’re blocking Firestorm but we’re not blocking Phoenix? I did a silly thing some time ago, when we announced we were going to end support for Phoenix, and I made a promise. And that promise was that we would never block Phoenix. And I can’t go back on my word. So as far as Phoenix is concerned, I’ve told Linden Lab if they want Phoenix blocked, they’re going to have to handle it themselves.
1:01:13 JL: But I agreed to block Firestorm, and will continue to. In fact, the whole blocking thing shouldn’t have been news to anybody because we had stated that we were going to do that for some time now. For over a year we’ve been saying we would start blocking versions, and suddenly we make an announcement that it’s time, and everybody’s … “Where did that come from?!”
1:01:44 JL: And Linden Lab has voiced no opinion on Phoenix, by the way. There’s just under 10,000 people on Phoenix as of our latest stats from Linden Lab. Still, that’s a lot of people. In fact, there are more people on Phoenix than on some third-party viewers that do support avatar rendering and whatnot. But it’s a low enough number that Linden Lab is not concerned about it. So if you’re one of those people who still uses Phoenix … if it works, if it is acceptable to you … if Linden Lab is not concerned about it, I’m not.
1:02:56: When you “blocked” those older versions of FS, does that mean they can’t be used in other grids also (as applicable)?
1:03:04 JL: My apologies to OpenSim users. Up until version 4.4.2 we never had the infrastructure in the viewer to differentiate from one grid to another grid in regards to blocks. From version 4.4.2 and forwards, we will be able to differentiate, so we can block a viewer from Second Life and not have it affect any other grid. Or we can have it blocked from one particular grid or another particular grid and not have it affect Second Life. But that code is only new since version 4.4.2, so at some point we’re going to have to block 4.4.0, and that’s also going to block people on OpenSim. But once that’s done, we’ll be able to continue on and not affect people on OpenSim. I wish we had a way around that, but there was just no way; we didn’t have the infrastructure for it in the viewer, and so the blocks affected people on OpenSim as well.
1:04:12:Has the FS team ever considered working on a mobile Firestorm product?
1:04:16 JL: We did! You weren’t around in April?
0:04:22 TS: Yeah, for smartphones and stuipdphonesTM.
1:04:25 JL: Yeah!
1:05:00 JL: The honest answer is: no. It’s up in the stratosphere in terms of our capability and our interest. Working on a Second Life viewer, based on Linden code is one kind of ball game. But working on a mobile app? That’s like going from being a soccer player to being a snooker player. We don’t do that. Although Cinder knows how to work on ‘phone apps and stuff, it’s a totally different ball park.
1:05:45 TS: Speaking strictly for myself, I have a Nexus 7 7-inch tablet, and Lumiya works absolutely fantastic.
1:05:58 JL: At the end of the April Fool’s joke I did point out that there are some very good mobile apps out there for accessing Second life for Android and for iOS. The iOS one is Pocket Metaverse, unfortunately it’s not being developed any more, I think. The Android one is Lumiya, which is phenomenally good. And don’t expect when you get on this, that you’re going to get this entire immersive experience; you ‘phone is not capable of that. No matter how good Lumiya is, your ‘phone just doesn’t have an nVidia Titan graphics card in there. It’s not going to be able to play Second Life the way you see it here. And I stated in my, “sorry folks, it was a joke” blog post after the April Fool’s joke, is that the examples that are out there are as good as it gets. And what I meant by that is, don’t expect to log-in to these things and have this Second life viewer experience. It’s just not possible.
Lumiya offers an excellent means to access Second Life on an Android device – see the coverage in this blog
1:07:05 JL: But what you do have with Lumiya and Pocket Metaverse is as good as it gets. It’s really, really good for what a ‘phone is capable of giving.
1:07:44 LP: A quick point I want to throw out to those wanting to connect to Second Life on a mobile device … you can do it in an inefficient way by connecting remotely. You will need to have your computer on at home when you do it, but if you’ve got TeamViewer or a different kind of remote connection application on your tablet or ‘phone, then you can connect to your computer at home and log-in to Firestorm. You’re going to be a little bit inhibited when it comes to things like typing, and I believe you have to use the on-screen movement controls, which can be very awkward if you’re not used to them, but you can do it that way. So if you want to use Firestorm on a mobile app, that’s what you’re going to have to do.
1:09:21 JL: Yeah, we’re not working on mobile. Linden Lab is working on something mobile, and there are some pretty good apps out there already, but not us. We have our hands full as it is. And can you imagine us trying to support another, completely different, viewer? … Although mobile tech is evolving very quickly now. and in two years, you never know; they may have Titans in your little tiny ‘phone!
1:10:17 JL: Speaking of April Fool’s jokes, just wait ’til next year! Already got a plan.
1:10:34 JL: I have no more questions. Does anybody up here on stage have anything to add?
1:10:41 EM: I have something I’d like to say, in the form of a “thank you” to everybody who has come out to this, and a little bit of encouragement. It’s users like you that make Second Life a lot more fun for everybody. You come out, you get yourself informed, and Jess’s comment earlier about the Linden User Groups and encouraging you to go out to them: I’m going to second that. And the other one I’m going to plug, which is pretty-much normal, is come on out to the Firestorm classes, folks. We have classes almost every day; I see a lot of people here who have been to the classes, but it is the best way to stay informed.
1:12:03 JL: By the way, we’re going to be doing these Q&As once a month and we’re going to alternate the time of those Q&As… so out next Q&A will be at 08:00 SLT, and the one after that will be at 16:00 SLT, so we’re trying to accommodate people from other time zones.
1:13:20: Have you guys ever considered “drawing a line” on how far the developers will veer the code base away from LL? I watch the code repository a lot and it really does seem that there is so much work being done to new options and features and customizations….but then when it’s time to merge in all of the big sweeping changes from LL, it seems the time between releases could get bigger and bigger and bigger….have you guys thought about taking times where going into more of “maintenance mode” to focus on LL code and getting faster releases from time to time?
1:13:54 JL: Really good question. We’ve definitely done a lot of consideration and a lot of people want us to do this and that, and that, and that, and change this and change that. We probably can do all those things, but the more we do, the more we veer away from the Linden Lab codebase, and the more work it is to us to merge …
1:14:27 JL: You know when we get regressions in bugs? It’s because of merges. It’s because we’re merging-in, say, Linden code – it could be others’ code, but we’ll say Linden code – and a lot of the time when end up with conflicts in areas of the code, and then we have to work out which version do we want. Do we want the version we did, or do we want the version Linden Lab did? Sometimes we don’t know if something we have is something that we did, or something that Linden Lab did or something that we pulled in from some other viewer; we’re not quite sure what it does, exactly, so we have to go and investigate. And to do that properly would take forever.
1:15:12 JL: So quite often we have to do a little bit of guesswork and hoping and keeping our fingers crossed and just going by gut on what we think should be overwritten and what shouldn’t be overwritten; and then we get regressions and bugs and things. And we get a lot of people complaining, “You fixed this and now it’s come back! How stupid are you?” Well, probably not that stupid. Merging is a pain in the butt, and there are reasons why we haven’t gone too far away from the Linden codebase whenever possible.
1:15:49 JL: This recent merge with Linden Lab’s CHUI was a nightmare, because it over-wrote all the work we did for our chat layouts and stuff, and that would have been devastating. Ansariel was clever, and took all the work that we did, and put it in its own files. So we could have all the Linden Lab stuff come in, just in the chat area of things, and that code would come it, and the viewer would just ignore that, because it’s using ours. so we don’t have to merge that any more. And ideally, that’s what we should have done from day one. Anything we wrote should have been written in its own files, and that way we could merge-up with Linden Lab and it would probably be a lot easier to merge.
1:16:41 JL: We don’t have anything written in stone as far as “we can’t go past this point”, because every situation is different. But generally, we will look at things, and question whether it’s going to be a major problem for us going forward. So merging is difficult, and yeah, it slows down our release cycle. Especially when Linden Lab dumps a whole lot of code on us all at once. And they dump it because they’ve been working on this stuff in secret for six months … and then they drop it on us. And when they drop it on us, we get it like a week before it goes into a release version.
1:17:44 JL: Mesh, for example, didn’t become visible to us until a week before Linden Lab released it … Linden Lab makes this code public, so we can see it, and it’s going to take more than a week to get that merged into the viewer and then deal with all the bugs which it creates, because merges create a lot of bugs. Then we’ve got to do QA, then we’ve got to fix all the bugs that QA found that we missed the first time, then we’ve got to go into feature freeze; it’s just a big, long cycle. So when we’re merging-up to Linden Lab, the reason it’s slow is it’s a lot of stuff that has to go through. And we have to try to do it quickly, but still be diligent … We have more users on Firestorm than all other viewers combined.
1:18:55 JL: If linden lab release an unstable version, it affects X number of people. if we release a viewer with a bug, it affects a lot more people. And we have a dedicated, volunteer support team who have to deal with the ramifications of that. So we have to be very cautious, very careful and diligent in QA to try to limit that as much as possible. And when we can’t do that, we’re going to call in a beta.
1:19:33 JL: So merges slow us down, and this is one of the reasons why it’s difficult for us to keep up with frequent release cycles. We haven’t had a chance to fix many of our own bugs in a long time, because Linden Lab has this steady stream of stuff coming out now, like HTTP, the interest list, Sunshine (SSA and inventory updates), you name it, they’re just coming out with a steady stream of stuff, and it’s giving us no time to work on our own things. It’s giving us no time to fix our Firestorm-specific bugs. We’re spending most of that time just trying to keep up. Linden Lab has a lot more devs than we have, and they work right hours a day, they’re paid good money and this is their job. Whereas we’re all volunteers, we work our own jobs eight hours a day, and we come home, and we have a couple of hours to spend working on the viewer.
1:20:44 JL: So we don’t have nearly as much time as Linden Lab does, and although we have a team of devs, most of them have been inactive for their own reasons, so it’s difficult developmentally to keep things going.
1:21:01 EM: I’d like to address the chat comment that the support team is the reason we have so many more users. You know the reason we have a support team? Because of our mission statement. We’re here to improve the user experience. The reason we have as big a user base as we do is because you all like the viewer and what we’re doing. It’s not support, it’s not development, it’s not QA; it’s all of us together who make the difference.
1:21:40: What gives you the power to deal with firestorm?
1:21:47 JL: For me, it’s logging-in and once in a while I’ll have an offline from someone that’s like, “I know you don’t know me, but I just wanted to message you and say thank you.” But it’s different for everybody. I think that holds true for most of us, though.
1:23:03 EM: The thing that keeps me going is people who come out to the classes asking intelligent questions and making me expand my knowledge of Second Life and the viewer. We all win, from my perspective.
1:23:26 JL: It’s been a challenge, speaking for myself. It’s been a hell of a challenge being on this team and doing what I do. But I’ve learned a lot, and I appreciate that, because of you guys.
[After this the meeting winds-down with general chat.]
Filed under: Firestorm Tagged: Firestorm Meetings <a rel="nofollow" hre