March 15 Firestorm meeting: video, transcript and notes

firestorm-logoOn Saturday March15th 2014, the Firestorm team hosted a meeting and Q and A session to discuss the recent 4.6.1 release, provide updates on a number of issues, and answer audience questions.

While the meeting was recorded, the Firestorm team are aware that many of their users have hearing difficulties, and / or prefer to read text, so this transcript has been supplied on their behalf.

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 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
  • In the interests of readability, topics in the transcript are not necessarily presented chronologically compared to the video. For example: questions asked during the various updates, etc., are presented in the Q and A section of the transcript, rather than at the point at which they were asked (unless directly relevant to the topic being discussed). Similarly, topics of discussion which came up during the Q and A session, but which were not tied to specific questions, have been placed under their own subject heading outside of the Q and A section
  • 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 “…”
  • 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. I am not an official member of the Firestorm team, and technical or support issues relating to Firestorm cannot easily 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.

The TL;DR Summary

The following is a brief summary of topics discussed. Timestamps in braces refer to times in the video where the relevant commentary can be heard. All sections are expanded upon in the main transcript – click on the timestamp to go to them.

  • [0:0015] viewers are often subject to flase flagging by anti-virus programs as carrying a potential virus / Trojan. With the Firestorm 4.6.1, Norton anti-virus in particular had issues with viewer, prompting a positive response from Norton’s support
  • [0:14:32] Mac issues update: work is being done on some Mac issues within the Lab, but there is no major project to address problems some users are having. Firestorm are somewhat stymied in dealing with issues due to both a lack of developers  / developers with free time and because some of the issues are beyond their ability to resolve
  • [0:31:00] Windows XP officially reaches its end-of-life on Aprial 8th, 2014. What does this mean for users on XP using Firestorm?
  • [0:38:25] Even running a 32-bit viewer on a 64-bit OS yields stability improvements, although if you have a 64-bit version available, it’s obviously preferable to use that on a 64-bit OS
  • [0:57:40] Firestorm are often critiqued on the frequency of releases. The team are moving to imporve things to a 3-monthly cycle, and there are reasons why a more frequent cycle may not be feasible
    • [1:21:05] It remains that Firestorm will not offer nightly or weekly builds, because there are significant support issues
    • [1:27:32] The team already try to release based on feature sets, however, a time-based cycle offers potentially better management of releases in keeping with the needs of the developers, QA and support
    • [1:35:21] The target will therefore be a 3-monthly cycle of major releases, with possible interim releases with bug fixes or for special features, such as might be the case with the group ban functionality
  • [1:58:53] With a target of a 3-monthly release cycle, it is probable that the next 2-3 releases are going to be primarily focused on incorporating features and capabilities coming out of the Lab, simply because there are so many of them: group bans, SSA updates, AIS v3, interest list, voice updates, etc.
  • [2:01:55] The new download server has performed admirably with not craches or other issues.
  • [1:55:40] Firestorm classes – with a new release just out, don’t forget there are Firestorm classes which cover all the new features, including things like the updated Contact Sets
  • Questions and Answers: including information on clean installs / re-installs; using settings back-ups; troubleshhoting issues; the status of voice improvements; why group limits are unlikely to increase in the near future; helping Firestorm support, etc.

With thanks, as always, to North for the video.

Continue reading “March 15 Firestorm meeting: video, transcript and notes” →

SL projects updates 12/1: Group chat

There’s not a lot to report a present this week in terms of ongoing project work from the Lab.

Server Deployments: week 12

There are no server deployments scheduled for week 12 on the Main channel or the RCs.

SL Viewer

On Monday March 17th, the Lab issued the latest iteration of the Google Breakpad RC, version 3.7.4.288045, for the purposes of improvements to crash and statistics logging. It has been anticipated that this may be the last iteration of the Breakpad RC for a while.

It is anticipated that the remaining RCs will be updated during week 12.

Group Chat

Om March 17th, Ebbe Altberg indicated that group chat was being worked upon by the Lab via a Tweet in response to a complaint:

Ebbe-group chat

When asked about this at the Simulator User Group Meeting on Tuesday March 18th, Kelly Linden was able to say:

As Ebbe has confirmed someone is looking at and working on group chat. However it is a non-trivial problem saddled with a lot of legacy and high expectations. I have reviewed some of the changes so I do know changes are being made that sound like they will make improvements.

SL Go on the Nexus 7 2013 HD

SL go logoImportant note: The SL Go service is to be shut down on April 30th, 2015. For more information, please read this report.

When OnLive launched their SL Go service, a comment following my preview article on the service asked if I’d report back about any ongoing experiences I have with it.

At the time, I indicated it would be unlikely that I’d do so, as I rarely have need to access Second Life when away from my main computer, and when such occasions do occur, I have Lumiya at my disposal which tends to meet all the needs I have for mobile SL access.

However, I decided that in the interests of testing / reporting, I’d take some time to drive SL Go on my Nexus 7 2013 HD.

For those unfamiliar with Asus’ 2013 offering on behalf of Google, the Nexus 7 HD features a 7-inch screen with a 1920×1200 resolution at a whooping 323 ppi, a Qualcomm Snapdragon S4 Pro CPU paired with an Adreno 320, 400 MHz GPU and 2 GB RAM and, in the case of the model I have, 16 GB internal storage. As such, it runs Lumiya beautifully. But what of SL Go?

Wandering trhough LennonParkOnTheRock using SL Go on the Nexus 7 HD (overlay closed)
Wandering trhough LennonParkOnTheRock using SL Go on the Nexus 7 HD (overlay closed) – click for full size

Well, frankly and unsurprisingly, it runs SL Go pretty fabulously. As with the Samsung Galaxy Tab 3 OnLive loaned me for the SL Go preview, SL Go is slick and fast on the Nexus and beautifully clear – most of the time (a caveat I’ll return to in a moment).

Rather than a quick on / off with the service, I spent time wandering around LennonParkOnTheRock, which I’ve reviewed in these pages (using Firestorm for the photos, simply so I can access all the windlights I tend to use). I explored the trails and paths, had a chat with one of my blog subscribers (/me waves to Ringo), and tried a few snaps both via screen capture (1920×1200) and via the viewer’s snapshot floater & e-mail (allowing me snaps at 4096×2497).

Overall, and allowing for the fact my Internet connection was a tad bit ropy at the time due to an intermittent line fault, my experience on the Nexus was easily equitable to that gained on the Galaxy Tab 3. However, the additional real estate offered by the latter’s 10-inch screen did make it perhaps a preferable choice for me when using SL Go, even with the higher and crisper resolution on the Nexus.

LeonnParkOnTheRock captured on the Nexus at 4096x2304
LennonParkOnTheRock captured on the Nexus at 4096×2497 using the snapshot floater & forwarded to my e-mail account – click for full size

In my original preview of SL Go I made mention of the fact that there is obviously a lower limit in terms of screen size where using the service is liable to become impractical, even with the overlay and the ability to zoom-in on the UI. This is something OnLive acknowledged in our chats about the service prior to launch as well. However, quite where this limit is comes down to a number of factors – with eyesight perhaps topping the list, alongside (maybe) screen resolution.

For me and my eyes, which aren’t quite what they used to be (although in difference to Spike Milligan / Eccles, they never used to be my ears….) my Nexus 7 is probably that lower limit. Yes, it was great having SL displayed in all its glory on the screen – graphics at Ultra, shadows, ambient occlusion and all the rest, but after 30 minutes, I started finding it hard to focus and found things getting a little blurry due to eyestrain (hence my little caveat earlier). This is not a fault of OnLive’s; I think there is simply too much detail on the Nexus’ screen for my eyes to comfortably process without me feeling some strain.

Of course, I could partly mitigate this by zooming-in on specific areas of the screen, reducing my overall field of view. But this raised its own issues; if I wanted to use a tool bar button or menu option, for example while zoomed-in, I had to first zoom back out and then zoom back in again to ease the amount of strain I was feeling behind my eyes – and this did start to get a little tedious in its own right. It also wasn’t something I noticed so much when using the bigger 10-inch screen of the Galaxy Tab (or at least, I wasn’t so conscious of it when using the Tab).

SL Go on my Nexus 7 HD + keyboard
SL Go on my Nexus 7 HD + keyboard

But leaving this aside, SL Go did run exceptionally well for me. The overlay, as with the Samsung Galaxy Tab 3, performed flawlessly, and the Bluetooth keyboard I use with my Nexus allowed me to chat a lot more easily than using the on-screen keyboard, and was obviously completely non-invasive on the screen, which was a big plus when compared to having just an on-screen keypad for text use.

So, would I be tempted to use SL Go over Lumiya?

That’s a tough one for me to answer and not necessarily because of the current SL Go pricing plan. The fact is that  I rarely need to access SL when away from may home computer, and when I do, Lumiya actually more than meets most of my needs, as noted at the top of this article. However, and more to the point, I’ve been a firm supporter of Lumiya and Alina’s work ever since Oz Linden gave me a nudge towards it back in early 2012,  and so have a certain loyalty in that direction which I’m unwilling to set aside purely on the basis of new shiny.

But that said, were there an occasion when I wanted to be in-world which benefited from having all the graphical richness of the viewer when away from my PC, then yes, I’d opt for SLGo, even with the current pricing plan. In fact, given my “mobile SL” needs are so rare, the fact that the service currently does have a metered payment system actually makes it more attractive to me than were it to have been introduced purely on a subscription basis.

This should not be taken to mean I’m against the service having a subscription payment option – I’ve already expressed an opinion that OnLive should offer both. It’s purely that even $25.00 for 10 hours of SL access via my Nexus is most likely going to last me a good several months based on past habits, thus making it potentially a lot lighter on my purse than a straightforward subscription service.

As it is, and putting questions of payment plans and what OnLive might or might not do in the future (and they are monitoring things closely, believe me) aside, I do now have two options for using SL from my Nexus should the need arise. And, eyesight allowing, choice is always a good thing, right?

Viewer release summaries 2014: week 11

Updates for the week ending: March 16th, 2014

This summary is published every Monday and is a list of SL viewer / client releases (official and TPV) made during the previous week. When reading it, please note:

  • It is based on my Current Viewer Releases Page, a list of  all Second Life viewers and clients that are in popular use (and of which I am aware), and which are recognised as adhering to the TPV Policy
  • By its nature, this summary will always be in arrears
  • The Viewer Round-up Page is updated as soon as I’m aware of any releases / changes to viewers & clients, and should be referred to for more up-to-date information
  • The Viewer Round-up Page also includes comprehensive links to download pages, blog notes, release notes, etc., as well as links to any / all reviews of specific viewers / clients made within this blog.

Official LL Viewers

  • Current Release version updated on March 10th to version 3.7.3.287491 (formerly the Maintenance RC) March 10 – core updates: assorted MAINT fixes (download page, release notes)
  • Release channel cohorts (See my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
    • FmodEX Hotfix RC version 3.7.4.287875 released on March 11th – core updates: fix for a suspected thread race crasher in the FmodEx audio streaming library (download and release notes)
  • Project viewers:
    • No updates.

LL Viewer Resources

Third-party Viewers

V3-style

  • Firestorm updated to version 4.6.1.40478 on March 12th – core updates: many LL updates, incl HTTP & fitted mesh; many UI additions, multiple improvements and bug fixes – please refer to the release notes and my review here.

V1-style

  • Cool Viewer updated on March 15th to the following versions: Stable: 1.26.10.14; Experimental: 1.26.11.14; Legacy: 1.26.8.51 – core updates: all – backport of inventory updates / improvements; backport of potential gesture-related crash fix; backport of server alerts/notifications; Stable bug fix for a fitted mesh glitch;  Experimental: backport of the AISv3 API support  (release notes)

Mobile / Other Clients

  • No changes

Additional TPV Resources

Related Links

SL projects updates 11/3: TPV developer meeting, March 14th

A TPV developer meeting took place on Friday March 14th. The core items discussed in the meeting are reported below, with timestamps in the relevant paragraphs indicating the point at they are discussed in the video embedded here. My thanks as always to North for the latter.

SL Viewer Updates

[0:01:37] The list of release candidates in the release channel remains unchanged from part two of this week’s projects updates, and as per my Current Viewer Releases page.

FmodEx RC

[0:01:44] The FmodEx Hotfix viewer RC (version 3.7.4.287875), is a fix Monty Linden has been working on, and is described by Oz Linden as:

A threading problem that at least manifests when there are various FmodEx things going on, but is not strictly speaking an FmodEx problem. We think that was a good and important fix, but it doesn’t seem to have done all we hoped it would do yet.

Whether or not this is a fix TPVs would need to implement quickly or not is down to how they have implemented FmodEx.

Voice RC

[0:02:38] The Voice RC is essentially the release viewer with the Vivox 4.6.x SLvoice plugin packaged with it for Windows and Mac. Commenting on in from a Mac perspective, Oz Linden indicated that it does appear to solve a number of issues, such as working with an iPhone headset adaptor, which was an issue with earlier versions, as well as addressing some Mavericks related issues.

[0:11:11] There has been some confusion over the latest SDK supplied by Vivox, in that only the Windows and Mac versions of 4.6.x have so far been supplied; the Linux version is still an older version. It’s unclear as to when the Linux Vivox SDK will be supplied, as this is apparently seen as a “lower priority” compared to Windows and Mac, although the Lab is working on Vivox to try to improve matters. The Lab is also working to try to get 64-bit versions of the Vivox SDK, which could then be made available to those TPVs building 64-bit versions of their viewers.

Interest List RC

[0:41:54] Concern is raised as the number of updates which form a part of the interest list RC viewer, and whether these may leave TPVs with another “CHUI situation” when trying to merge things.  The repository for the viewer has been available since the viewer reached RC status, however, Oz went on to comment:

There’s a bunch of refactoring of things that people decided needed refactoring as a part of the process [and] which may or may not have been strictly needed as [a] part of interest lists; that is, part of the functional change that that branch is doing. Some of it was a new trace capability that’s used in a bunch of places where they wanted to take the measurements they wanted to take about it.

The interest list RC is working its way towards release status ... slowly ...
The interest list RC is working its way towards release status … slowly …

There have been various stability issues with the interest list RC, hence why it has remained an RC rather than being promoted to the de facto release viewer. However, it is now reaching the point where its stability is comparable to that of the other RCs in the release channel – and is actually better than some.

In terms of merges, there is the potential for the interest list viewer to cause TPVs some problems, as there appear to be changes to llCommons and other libraries which are causing issues for those TPVs which have attempted a merge.

Google Breakpad

[0:04:53] The Google Breakpad RC is due to make another appearance, as a “bunch of issues have been wrestled to the ground”, and the hope is that when it does appear in the release channel, it will mark the last round of updates for that particular project, and those TPVs using Google Breakpad are advised to take a look at what the Lab has done.

Overall Status for RCs

[0:04:10] Overall, it appears as if none of the RCs are performing as well as the Lab would like them to be in terms of crash rates. It had been hoped that the FmodEx Hotfix RC would get the Lab back below what Oz referred to as “an acceptable, if not admirable, crash rate”, but it has not done so as yet.However, the other RCs in the channel should see updates released in week 12 (week commencing Monday March 17th), one or more of which may improve the crash rates.

[0:43:56] In terms of what does get promoted next, the most likely candidate will be the RC which shows clear evidence that it is reducing the crash rate compared to current levels across the release and RC viewers.

[0:05:27] In the meantime, because of the volume of RCs sitting in the release channel, the Lab are holding back a number of further RCs,. These include the Project Zipper (faster installer) viewer being updated to RC status, and the group ban viewer (although there are bugs in this which are still being worked upon). There is also likely to be a further Snowstorm RC appearing with a mix of code contributions, again once the number of viewers currently in the release channel is thinned-down a little.

Continue reading “SL projects updates 11/3: TPV developer meeting, March 14th” →

SL projects update week 11/2: group bans, JIRA, Oculus Rift

Server Beta meeting, Thursday March 13th
Server Beta meeting, Thursday March 13th

Server Deployments: week 11 – recap

As always, please refer to the server deployment thread in the forums for the latest updates / changes.

  • On Tuesday March 11th, the Main channel was updated with the server maintenance project deployed the BlueSteel and LeTigre channels  in week 10.
  • On Wednesday March 12th, BlueSteel and LeTigre joined Magnum in having support for a new version of the inventory service, AIS v3, enabled.  This service requires the use of the Project Sunshine RC viewer. The only changes compared to last week’s Magnum release was to include this week’s SLS changes.

Aditi Server Maintenance Package

A new server maintenance project arrived on Aditi in week 11, en route for a release on the main grid. This includes some bug fixes and some further work on the LSL syntax project  Ima Mechanic has been developing, and which is largely encapsulated in STORM-1831. The new project on Aditi specifically includes a new schema to fix STORM 2000, so expect this to be filtering through to the main grid in due course.

Group Ban Update

Not a lot to report here. Whirly Fizzle uncovered an awkward bug whereby a person granted the ability to ban others from a group could actually accidentally ban themselves. This proved a little hard for the Lab to initially pin down, prompting Maestro Linden to comment at the Server Beta meeting on Thursday March 13th, “We [he and Baker] both had problems earlier, because we were using a more manual method of just POSTing the data to the capability.” However, now the issue has been identified, a fix is being worked on.

JIRA Settings – Making Older BUG Reports Visible.

Following my note in part 1 of this report that users can opt to set their older BUG reports visible to the public, Maestro Linden said:

By the way, it’s possible to set the visibility of your past BUG issues by editing the ‘Security Level:’ setting. For the most part, we’re leaving that up to the reporters to change, if they’re willing to share their bug report issue more widely.

The reason we’re doing it that way is because people previously filed BUG reports with the expectation of only a few people being able to see it, and in some cases there are sensitive details like email addresses and conversations and whatnot.

On the matter of privacy, Maestro also indicated that new BUG reports can also be set for limited public viewing – that is, only to “Triagers and Reporter” should anyone have any concern over posting sensitive information in a new BUG report.

Oculus Rift

Not a lot to report here. The Lab has put out a call for beta testers for the Oculus Rift version of the viewer, as I reported here. commenting in broad terms about the project, Maestro Linden indicated that there is a slight drop in frame rate when using the headset, although he was uncertain as to the overall impact. He also described the revised UI as seen when in Riftlook as floating overhead, possibly in a toroidal form, and that the user needs to move their head to see it, so as not to have the UI invade the world view. He actually gave up trying to describe it, as he was without a headset when discussing it, and reported, “Marissa’s trying to explain it to me but it’s complicated :).”

Those fortunate enough to have a headset and who get into the beta programme will doubtless find out in due course!