Firestorm by far most popular on hypergrid

The Firestorm Viewer is the most popular on the hypergrid by a wide margin, according to today’s analysis of Hyperica server logs.

More than half of the last 3,600 visitors to Hyperica used the Firestorm Viewer. Less than a third used Singularity, and CtrlAltStudio, Cool LV, and Replex were all around 3 percent each. Kokua accounted for just over 2 percent of visitors, followed by Imprudence and OnLook at around 1 percent each.

Viewer use April 2015

 

These numbers are for Hyperica visitors only — many closed commercial grids use their own viewers, and those numbers wouldn’t show up in these statistics.

Why so popular?

The Firestorm viewer is currently the most popular viewer in Second Life, and it makes sense for people to continue using a viewer they like and are familiar with when they come to OpenSim.

Plus, the Firestorm viewer developers have openly committed themselves to supporting OpenSim for the long term, and, last night on Metaverse Week in Review, project manager Jessica Lyon repeated that pledge.

Jessica Lyon on Metaverse Week in Review

Jessica Lyon on Metaverse Week in Review

“I believe that the future of virtual worlds lies in OpenSim,” she said, at the 1:05 mark in the video below.

Firestorm publishes two versions of its viewer — one specifically for Second Life, with the proprietary Havoc physic engine for pathfinding and physics mesh uploads, and the other for OpenSim. But she doesn’t advise people — including Second Life users — to use the Second Life viewer.

“I recommend everyone use the OpenSim viewer,” she said.

She explained that only a handful of people would ever need the specialized physics mesh upload option or the pathfinding creation tools that the Second Life-specific option offers.

“The OpenSim version can upload mesh as well, just not with the physics attribute,” she added.

In fact, she said, the majority of Second Life users do actually use the OpenSim version and, thus, have access to all the OpenSim grids with the same viewer.

There are also other benefits to using a popular viewer. For example, it’s easier to get help with a viewer that everyone else is using. There are also more people working on bug fixes and other improvements.

New features that are developed in other viewers get thoroughly tested by the users of those other viewers and prove their value before they’re added.

Finally, there are usually good reasons why a particular viewer is more popular than another. While other viewers may have certain features that appeal to particular groups, Firestorm seems to be the viewer that serves the majority of people best.

In-viewer Destination Guide

I was inspired to run the numbers because I’m working on a Destination Guide based on the Hyperica directory, and different viewers have different methods for coding destination links. Testing the directory against every single viewer was becoming really time-consuming, since each time I made a change, I had to check it with several different viewers!

In particular, Kokua and Imprudence use an old-style coding scheme that isn’t supported by the new viewers. These viewers are popular with people who need an old-fashioned interface — but, according to my visitor logs, not that popular with the average hypergrid traveler. So right there, two fewer viewers I need to test with.

Ideally, of course, all the viewers would get on the same page and adopt a common protocol.

Last night, I had a chance to ask Firestorm’s Lyon about the coding issue. It’s a long show, but some of the discussion starts at the 21 minute mark.

“This is the first I’ve heard of OpenSim grids taking advantage of the Destination Guide,” said Lyon.

Some grids — Openvue and OpenSimulator Community Conference grids in particular — have had Destination Guides in place since last summer. But the news hasn’t necessarily spread far. Lyon wasn’t the only one — I only heard about this feature recently, when Xmir’s Gavin Hird posted about it on Google Plus this past week.

“I can only speak for Firestorm, but it’s interesting that it works at all, actually,” she added. “This is something we could be investigating and improving.”

She mentioned that one thing she’d like to see is a protocol that allows people to click on a link in a regular Web browser, and it automatically opens a viewer and, if the grid isn’t in the grid directory, automatically adds it in.

This is a tricky thing to implement, however — some people might not want to be logged into a grid, but to be teleported into it from another grid, for example. It will take quite a bit of work to get the optimum solution — and, unfortunately, the Firestorm team is currently short of OpenSim developers and testers

But Lyon said that OpenSim users could help Firestorm’s efforts in several ways.

First, she urged those with Second Life accounts to join the Firestorm Early Adopters and Testers group. Second Life account holders can also attend Firestorm Classes, which usually end with a question-and-answer session.

The Littlefield Grid is currently working on organizing Firestorm-related events for those on the hypergrid, and runs the Firestorm on OpenSimulator Google Plus community.

Lyon also recommended that people post bug reports on the Firestorm Jira (free account required), or even email her directly. She said she welcomes input from OpenSim users.

Raw Statistics

For those interested in the details, here’s the breakdown of Hyperica visitor numbers based on viewer type:

 Astra: 3 visitors
 Avination: 5 visitors
 Avination 64: 3 visitors
 Barosonix: 1 visitors
 CariousBot 1.0.0.0: 4 visitors
 Cool VL Viewer: 119 visitors
 CtrlAltStudio-Viewer-Alpha: 112 visitors
 CtrlAltStudio-Viewer-Release: 11 visitors
 DigiWorldz-Release: 3 visitors
 Dolphin Viewer 3: 2 visitors
 Exo-Life: 7 visitors
 Firestorm-Betax64: 79 visitors
 Firestorm-DJ-ADAM01TIME: 6 visitors
 Firestorm-MD: 1 visitors
 Firestorm-MOSES: 11 visitors
 Firestorm-OnLive: 2 visitors
 Firestorm-Release: 657 visitors
 Firestorm-Releasex64: 1282 visitors
 Hippo Release: 7 visitors
 Imprudence: 48 visitors
 Kirstens S19: 2 visitors
 Kokua OpenSim Release: 71 visitors
 Kokua OpenSim Release 64: 2 visitors
 Kokua Release: 10 visitors
 Kokua_OpenSim Release: 2 visitors
 Lumiya Release: 3 visitors
 OnLook Release: 30 visitors
 OSCC Viewer: 1 visitors
 Phoenix-Firestorm: 1 visitors
 Replex Alpha: 22 visitors
 Replex Alpha 64: 13 visitors
 Replex Release: 2 visitors
 Replex Release 64: 55 visitors
 Singularity: 8 visitors
 Singularity Alpha: 29 visitors
 Singularity Alpha 64: 12 visitors
 Singularity Release: 431 visitors
 Singularity Release 64: 593 visitors
 TestClient: 3 visitors
 Unknown: 17 visitors
maria@hypergridbusiness.com'

Maria Korolov

Maria Korolov is editor and publisher of Hypergrid Business. She has been a journalist for more than twenty years and has worked for the Chicago Tribune, Reuters, and Computerworld and has reported from over a dozen countries, including Russia and China.

  • Cinder Biscuits

    Firestorm support for the Destination Guide on opensim has been available since 2012.

    “She mentioned that one thing she’d like to see is a protocol that allows people to click on a link in a regular Web browser, and it automatically opens a viewer and, if the grid isn’t in the grid directory, automatically adds it in.”

    This is kinda-sorta in there, as Ai Austin can attest to. 😉 I’ve been formalizing the spec for the uri scheme and working on this on-and-off for a little over two years. Once it’s ready and I have functional code for it, I’ve already spoken to both Firestorm and Singularity and the new protocol should be adopted by the major viewers and hopefully gain ubiquitous usage.

    • Whoo hoo!

      So, if I’m clicking on the URI in a browser, what will it do?

      And if I’m clicking on the URI in an in-world media screen, destination guide, or chat, what will it do?

      In particular, I’m wondering what happens in the following two cases:

      1. If you don’t have a viewer running, will it open your preferred viewer? And, once that happens, will it log you into your preferred grid and teleport you to the destination? Or will it add the destination grid to the grid manager (If its not already there) and try to log you in?

      2. If you’re already in-world, will it try to teleport you to the destination? Or will it try to log you into the destination grid?

      Probably, closed commercial grids would prefer it to log you in, and users of hypergrid-enabled grids would prefer to be teleported in with their default avatars.

      • Cinder Biscuits

        The scheme will be registered in the IANA-maintained URI registry, and, as such, which viewer gets launched when clicked is determined by the user of the system the viewer is installed on (like how mailto: and http:// have their default apps on most systems.)

        Once clicked, if the viewer is not running, the viewer will be launched and the destination populated as the Start At location. If the viewer is already running, it will open the parcel info for the location if available, or by preference, immediately teleport you there. If the account you are connecting with is in a closed grid and the link is outside that grid, this will will fail, obviously.

        Adding a grid to the viewer would be handled in a different form. Rather than using the same link it would be distinctively different. Not quite as convenient for the end user, but much easier for the viewer to handle. As an example, (let’s call it metaverse:// for now, even though I haven’t the faintest idea what it should be called in the end, but it works for this.) The login uri metaverse://login.yourcoolgrid.com:8002 would fetch the login information for the grid and prompt the user to add it to the grid manager. metaverse://login.yourcoolgrid.com:8002/region/mycoolregion/128/128/40 would try to teleport you to MyCoolRegion on yourcoolgrid and if we’re feeling really ambitious, metaverse://login.yourcoolgrid.com:8002/agent/48c2ae04-bcba-41b4-8bbe-7125f5571ae3/im could start an instant message session with the user with that principal id on yourcoolgrid, but that would still be out a ways.

        I’ve been meaning to start digging into what hifi has come up with so far now that they’ve reached alpha stage and see if something can’t be done for future interoperability not just within OpenSim but there too.

        • Cinders… when you design the scheme remember that some grids use a different HG address to their login URL. OSGrid for example needs hg.osgrid.org:80 for HG map locations rather than its loginuri of login.osgrid.org:80
          Some grid owners have also said they use https:// protocols versus http:// ones. I am not sure if that “just works”.

          • Cinder Biscuits

            Yes, the uri I used was just an example (and the most common use.)

        • High Fidelity uses the protocol hifi://domainname/x/y/z or hifi://Place where “Place” is registered on their US$20 a year per name directory.

          http://blog.inf.ed.ac.uk/atate/2015/01/09/high-fidelity-alpha-tests-public-place-names/

      • I’m not positive but I think Kitely already does part of this. When logged into the grid with a local avatar, you can go to the world page and click enter world. It then boots up the region [as we know they are offline until called for] and teleports you to that region.

        See this page as the example I used just now to confirm it still works;

        http://www.kitely.com/virtual-world/Jacon-Cortes/Antiquity

        You can also disconnect via the same page.

        and fyi that 2×2 is owned by a guy named Jacon Cortes who is building a couple of castles which look really good so far. [for people who like castles]

    • As Cinders said, the destination guide has been working very well for some time in Firestorm, which is the main viewer I use and recommend for SL and OpenSim users.

      As Cinders hints… the hop:// protocol she and others have been working to support in some viewers, including especially FireStorm, using a more standard URL syntax… not the variants that work with :region in the domain:port part! …is the one I hope gets into use across the board. I can confirm that when launched with a click for the hop:// protocol the viewer launches, the viewer looks up or if necessary registers the grid URL in the OpenSim grids list, then launches the viewer with a preset location for that grid:port/region/x/y/z.. If the viewer is already running a suitable teleport dialogue comes up.

      Where a grid uses a different HG link address and loginURL (such as on OSGrid with hg.osgrid.org:80 and login.osgrid.org:80) that fails as Firestorm assume they will be one and the same at present.
      hop: does not quite work right yet everywhere… the main issue being that hop:// links are placed in local chat even for TPs on one grid and they fail when you click to go back (the address bar previous buttons work if you use those). Also, the grid you initially logged into sticks with you even when you go to other grids. Hence the hop:// addresses are wrong.
      Hopefully these sort of glitches can be fixed one day. There are Firestorm JIRA and OpenSim Mantis issues for these things as in some cases server side support might be needed.

      Some test hop:// links and notes are at http://www.aiai.ed.ac.uk/~ai/hg.html

  • Lani Global

    The other big issue is that we now have 5 or 6 different types of SLURLS for OpenSim and Hypergrid. All the viewers should support all of them. Instead they each support one or 2. This is a terrible situation for anyone wanting to provide a teleport via text, such as a notice or website.

  • Geir Nøklebye

    > In particular, Kokua and Imprudence use an old-style coding scheme that isn’t supported by the new viewers.

    Not sure what you mean by that, because while true of Imprudence, the Kokua viewer basically use the most up to date Linden code, in combination with the latest RLV code from Marine Kelly + the developer’s own support for OpenSim.

    Using the latest LL code proved to be an issue with many OpenSim grids, but that has now been sorted out perhaps with the exception of Avination where I believe it will crash shortly after login.

  • Bryan French

    Cool info Maria! I am impressed our residents are visiting with our Exo-Life Grid viewer. We also have Hyperica listed as the first grid on our teleport board so that may be driving some traffic there from our grid too.

  • Mal had mentioned he had a hard time finding specific gates on Shaun’s Sanctuary grid HG HUB. What I have been doing is putting up area object search and putting the HG grid name, in full or partial (I suggest partially in case one is not sure of the entire HG address). Use the definition search as all the gates use that as part of his gate script…turn on beacons and fly right to it-)

    For example, Littlefield’s HG is LFGrid.

    Also, when you land in the enclosed space landing point, then tp down using the gate in there, look behind you and there is a copiable gate. I like them as all I have to do is put the HG in the description of the gate to make them work.

  • Walter Balazic

    I’ve never seen that. I have a grid full of people that use firestorm primarily as their viewer, and not once have I ever seen that kind of error. We have hundreds of groups on our grid, and some groups have well over a few hundred people in them, and we’ve never had that complaint, nor have we seen any of those errors.

  • Lani Global

    Firestorm users don’t see it. It silently fails for them, so they don’t even know it is happening.

    • Walter Balazic

      I operate a grid, I think I would know if something I put in place to cause someone to join a group failed or not. I test things before I put them out. And so far this is one obscure instance of the MANY bugs you are complaining about. I think you just like to bash Firestorm myself. Fact of the matter is I get way more complaints about things not working in Singularity than Firestorm on our grid. And I have heard the same from many people on other grids as well. As for not loading inventory completely, if that were the case, our help ticket system would be riddled with complaints. Haven’t had ONE complaint about that. In addition, I’ve never once experienced that, and I think that’s something that wouldn’t be silently failing, I think it’s something people would notice pretty easily. Just because “you” can’t get your inventory to load, don’t blame it on Firestorm.

      • People are free to choose any viewer they want. The fact that they overwhelmingly choose Firestorm says a lot to me.

        Personally, I haven’t noticed any differences except the fact that I can have the “destination guide” button on my screen in Firestorm. Which is now, to me, a critical difference! 🙂

        • Geir Nøklebye

          If you spend a lot if time in-world the version1 interface that Singularity is built on can be very much more efficient in some situations than the later version 2 or 3 interfaces. I am sure the Singularity alpha builds will add the Destination guide to the bottom toolbar shortly.

          My biggest gripe with Singularity is they use old libraries, and for the Mac version that is about 40% lower frame rates in the same scenes over Kokua. It used to be that Singularity was very fast, but since Apple release a major new version of OS X about every 18 months, some of the outdated libraries struggle more and more (it is comparatively as you would be running Windows 2000 libraries.)

        • Walter Balazic

          I have tickets from people and could site a myriad of issues they have with Singularity (I will say I almost never get a complaint with CV or Kokua). But there’s no reason to viewer bash. These viewers are doing this for free, and in Firestorm’s case, I know personally they bend over backward for Opensim doing training, fixing things that send their way etc.. Just like anything else, if you can do better, write your own viewer. 🙂

  • Lani Global

    The most common Firestorm group join errors are when osInviteToGroup function is used, or when the group is not an open public group, but someone who is allowed to invite the firestorm user is inviting them. The only workaround is to temporarily set the group to Public Can Join… then change it back after the Firestorm user joins it.