UKanDo 3.6.10: nips, tucks and tweaks

logoUKanDo, the v3-based viewer from Connor Monaron updated to a new release on Wednesday November 13th. Version sees the viewer return to parity with the Lab’s release code base and gain the most recent improvements from the Lab including the Facebook SLShare capability.

This is more of a progressive update on capabilities already in the viewer rather than a major update with lots of new features and shinies, which is entirely in keeping with Connor’s stated intent to produce a viewer which is reasonably close to LL’s own, but which incorporates some of the more popular TPV functions and abilities.

In my last look at UKanDo, I reported on the arrival of the QuickTools floater, a variation of the popular Quick Preferences options found in a number of TPVs, which offers  rapid access to a number of the viewer’s capabilities. At the time, I pointed out that the icon for the toolbar button for the panel could perhaps do with a re-think, given it was the same as the icon for the viewer Preferences panel, so there was a risk of the two buttons being confused when set to Icon Only display mode.  With this release, the QuickTools button icon has been revised so that it is now a film reel / pie menu, making the button quite distinct from the Preferences button when both are used in a toolbar.

As well as the QuickTools button, the Area Search button and the Build button also get new icons.

Area Search Udpate

Area Search also sees the addition of further search criteria in the form of check boxes which allow the user to define the kind of objects which are to be located: physical, temporary, attachments, or others. These can be checked individually or in combination, and provide an additional level of granularity to object searches.

Area Search: updates with new checkboxes for more granular searches and a new option button (bottom left)
Area Search: updates with new checkboxes for more granular searches and a new option button (bottom left)

A new gear button has also been added to the floater, which can be used to access additional configuration options. Currently this only comprises Auto-Track Selections (displays beacon for an item selected from the list) and Stop Tracking (removes beacon). However, as this is reported as “part 1” of an overhaul of Area Search, more options may be forthcoming in the future.

Advanced Build Options

Version of UKanDo see the introduction of an Advanced Build Options floater, which contains some of the options also found in Preferences > UKanDo > Building, as well as some options not present in that tab.

The Advanced Build Options floater, offering additional default / options for builders, some of which can also be found in Preferences > UKanDo > Build
The Advanced Build Options floater, offering additional default / options for builders, some of which can also be found in Preferences > UKanDo > Build

The new floater is accessed by editing / creating an object and selecting Build > Options > Advanced Build Options from the menu bar or pressing CTRL-ALT-B.

Geometry Overload Protection

A new addition to the Graphics tab of Preferences with release is the Geometry Overload Protection. Enabled by default, this is designed to stop the viewer crashing due to someone using objects with excessive geometry (a common form of viewer attack in some regions). This addition brings a slight change in layout to the default display of the Graphics tab, which includes the option to enable the Advanced Lighting Model without having to access the Advanced options.

Preferences > Graphics gets revised to include the Geometry Overload Protection option and an option to enable / disable ALM without having to access the Advanced options
Preferences > Graphics gets revised to include the Geometry Overload Protection option and an option to enable / disable ALM without having to access the Advanced options

Other Updates

This release also includes:

  • Further adjustments to the viewer UI, with the buttons looking even more V1-style
  • Favourites Bar Landmark text now white for easier reading
  • Select only copyable objects Added to the Build -> Options menu
  • Show each avatar’s age in their name tag unless they are older than the number of days specified in Preferences > UKanDo > Avatar
  • Show LookAt / PointAt- includes names on crosshairs option Preferences > Privacy
  • Status Bar Hide/Show options for the:
    • Marketplace button
    • Buy Currency button
    • NetStats Bar Graph
  • Option to displayed log-in names as well as Display Names in the People floater tabs (click the options button and check View Login Name)


A small, tidy update to the viewer which again draws upon some popular TPV features without risking the viewer becoming top-heavy.

Still no media filter at this point in time, which I’d personally like to see (and would like to see in the official viewer for that matter). Having it available discourages a complete disabling of media and allows one to more easily enjoy music when travelling around without necessarily being over-exposed to more nefarious goings-on. Another thing I’d like to see is the proper release note attributions for those elements incorporated from other TPVs.

That the Advanced Build Options floater and the options in Preferences > UKanDo > Building have an odd level of functional cross-over which might cause some confusion at times. Given both the degree of overlap between them and the degree of individual options found in one but not the other, it might be an idea to make them consistent in terms of the options offered by both, but this is a minor quibble.

Performance-wise, the viewer operates pretty much as anticipated, and I didn’t notice any particular drop-off in frame rates when using CHUI in expanded mode, so I assume this issue has been fixed in the last rebuild of the 3.6.10 viewer, and that UKanDo has the fix. However, this is only my experience, so don’t quote me on that if you find you are still having that particular problem either with the latest release of UKanDo or the official viewer!

In the meantime, I’ll keep following UKanDo as it develops.

Related Links

15 thoughts on “UKanDo 3.6.10: nips, tucks and tweaks

  1. This approach seems to work well and in this way UKanDo is promptly updated. In comparison, Firestorm takes months to merge the code etc… just to deliver a buggy beta, because else we would have to wait 2014. I’m sorry for Firestorm, because I liked it for a very long time, but since the past 2 or 3 releases I’m starting to worry. Now I still use it, because of its features, but I looking at alternatives with growing interest, and UKanDo is becoming my choice. As for UKanDo, the only thing I don’t like so far are the buttons: black text on blue isn’t the best for reading. I hope the author will keep to improve it without to bloat it and without to make the merges too complicated.


    1. Firestorm unfortunately got hit by the surprise of CHUI, which did set them back, but they are rapidly catching-up. Of course, the irony here is that, aside from one or two aspects of the conversations functionality (such is in-viewer chat log viewing), Firestorm already had much of what CHUI was offering, and potentially presented it a lot better than CHUI has managed where Firestorm users are concerned. Thus the team were faced with a difficult task.

      That said, when looked-at across the board, Firestorm’s release schedule isn’t actually any better or worse than other viewers in terms of time frames. Some can go several months between updates, some will go for a couple of months, then release a number of updates in a staccato burst before pausing for another couple of months, some manage to pull-off weekly updates. All, however, face the same basic issue: time. People who work on TPVs do so in their spare time, not as an occupation. Therefore, other needs must come first (such as earning a living). Sod’s Law sometimes dictates that periods between releases can be exacerbated by a lack of time as well as a complexity of the viewer code itself.

      In terms of waiting until 2014 for the next update, again part of the delay here isn’t entirely Firestorm’s. We’re into the run-up to what is effectively an extended “holiday season” for the United States. Thanksgiving is on the horizon and then at the end of December there is the Christmas / New Year period. At these times, the Lab imposes a “code freeze” on releases (viewer and server) and requests that TPVs do not make significant releases of their viewers. One code freeze generally occurs during the US Thanksgiving week, the other tends to run through the Christmas / New Year holiday period. The reason for this is so that the Lab’s support staff do not get inundated with support requests as a result of a release immediately prior to the holiday period (and they do take a lot of calls related to TPVs as well as their own viewer). So this does naturally put the brakes on trying to push updates out the door on both sides of the fence.


      1. Thank you for your polite and informative answer! 🙂 This is one of my favorite blogs, and I always gladly read you.


    2. I’m always a bit amused when people refer to the “tons of bugs” in Firestorm. Apparently most of them never tried running the official viewer or viewers staying close it Linden code, because then you would see even more stupid and sometimes hilarious bugs. Alpha suddenly not working correct with materials? Who cares! Viewer lagging down to death when opening conversations? In our 5 minute test it never happened – ship it! Everything pink on ATI cards? We use nvidia! Go for release! And if we wait with a Firestorm release for fixes for all those crazy issues, people also start to complain. And then still we get blamed for bugs that are actual Linden bugs.


      1. I wasn’t referring to the “tons of bugs” that Firestorm has (you seem to answer to me, but that’s not my quote…), I was comparing the efficiency with the UKanDo way. Since you want to talk about bugs, well UKanDo is less troublesome to me than that Firestorm beta. And I called it “buggy beta”, because that’s a fact: the long list of know issues in that beta release (some of them very annoying) is isn’t a secret, but well linked in the last post of the Firestorm blog, where it’s also written that is an unpolished and substandard release. Yet “recommended”… in that state. But the topic wasn’t the bugs, and I wasn’t complaining because of the bugs, I was worried because I thought Firestorm became too complex and merging the code became an huge work. While UKanDo keeps all the differences with the LL viewer at a minimum (but still featuring all the most important stuff from TPVs), so it can update quickly, in days… I see instead that after almost an half year The Firestom Team wasn’t able to release an update before 2014 and had to release a buggy beta.
        And answering to the other argument: yes, I have other viewers installed that I use, the LL one included, both for curiosity and necessity. Yes, LL Viewer has bugs. They have a fast release cycle. Firestorm has a slow release cycle precisely because of that, among the other reasons, and because you have so many users and you have a responsibility blah blah… the support group… the quality assurance blah blah… I read that. Then, after months of wait, your confident users finally read the triumphant announcement of “the best release we have ever issued” (4.4.0)… that had so many issues that you had to talk about it for about two months, until a new release with (some) fixes came out (4.4.1) that had to be promptly retired because… ops! (OK, happens), anyway 4.4.2 was still behind and feature lacking. Many months later, you are catching up, but eventually you have to release a beta, with even more apparent bugs (but of course betas are meant only for beta testers, or the curious and adventurous users… right?), yet you recommend it as update. So your users have to wait hopefully for the next release, and they have to keep those pesky bugs for months. And to think that you were so proud of your QA! Now what’s amusing? Enough of the humor. Besides that (that was NOT my topic), I understand that the team got hit by the surprise of CHUI, I know that the Firestorm Team does its best, for free, and I ask nothing, instead I wish good luck to the team, and, as I said, I liked it for a long time as my primary viewer (and I love the customization), but I don’t think that UKanDo will be ever taken by surprise in that way, nor that it will take so many months to merge the code etc., because of the way it is made. So, to me, it looks like a more viable and efficient approach, about the updates. Since Linden Labs seem very active lately, daring even somewhat radical change, I hope that Firestorm and its complexity can keep up with that. What I saw lately worried me. That’s what I said.


        1. Do you really think the official viewer or other TPVs have less bugs? They just don’t make them public in such a way. And if you look closer at the list, you will notice that most of them have a MAINT-xxxx reference, meaning they are also in the official viewer and other TPVs as well. Right now, you are even using a viewer with all those bugs! :p


        2. Hoping I’m not making you feel like you’re being beaten-up, Ansariel does raise a fair point: oftentimes, TPVs are blamed for bugs which they haven’t created, but have inherited. This happens not just with Firestorm, but all TPVs.

          And again in fairness, if you take a look at the right-hand side of the list of known issues for Firestorm 4.5.1 you’ve referred to, you’ll see that of the 64 listed, no fewer than 44 of them are related to bugs reported within the LL viewer (“Viewer 3 bug”), and have an associated LL JIRA raised against them. Only those with a “no” in that column are specific to Firestorm.


  2. Using it as well (In fact since you posted the 1st review!).
    Yesterday i tried the expanded mode and on a region with a lot of avatars around (live show) i did noticed the drop of fps when on expanded mode, but not as much as before so i do think something must had been done on that chapter already by LL!
    For now to be honest i do think this viewer has all that one needs and it is the perfect one for my personal use!


  3. I must say that Firestorm would be much easy ironed if they didn’t still try to please all!
    How it would run if only there was a choice of the v3 interface or no legacy code still in use!
    But they choose their path long ago and in many ways it resembles Sl and other virtual worlds, All know Sl, only a few dare to explore the rest of the grids, same with firestorm and the rest of Tpv’s!
    Still i keep installing any new version of firestorm even if per facto i never use it, but i need to have a benchmark to compare diff Tpv and firestorm is that 1!


    1. I’m glad that they offer choices, but perhaps that’s a bit too extreme. After all who wants a V1-like viewer can still use Singularity, so the choice is still there and it works well. I don’t dare to think of the amount of angry users if they drop that, but I’m afraid that sooner or later they could give up with Firestorm as they did with Phoenix, telling that they can’t continue to do all that amount of work for free, in that way. Maybe it is only a difficult moment and I hope so, but indeed they choose the hard way.


      1. There was a choice made with Phoenix which made sense at the time (which is not to say it now doesn’t made sense); that choice was whether to continue to work with a v1-based / style viewer and work to revamp the code base while also trying to backport new features and code to work with it, or opt to go with something built from the ground up which has v2/v3 as its foundation, and then port across the more popular features from Phoenix.

        Whether one agrees with the decision to do so or not, the fact remains that the Phoenix / Firestorm team have done a more than credible job. As I mentioned previously, when you step back and look at their release cycle, it is no better or worse than other viewers, so they would appear to be managing things well, and I doubt they’re anywhere near giving up.

        As it is, Firestorm has only really suffered one truly major setback in planning, and that has been CHUI, which clearly did knock the team back on their heels and lead to problems in maintaining their planned release schedule. As it is, they’re now over that hump, and are in a position to continue forward, address those issues they can address and work on merging and integrating upcoming new releases and code updates as they appear from LL, such as the interest list updates which have only just made it to an LL release candidate viewer, putting all of the TPVs in more-or-less the same position in terms of adopting that code.


  4. Still as this is a post abut UKanDO i can only add that, i like his approach, i do think is the correct one when the team is a smaller one and i do find Connor Monaron the most humble developer i had the chance to speak with!
    The fact that he did listen was a pleasant surprise, for that and only that, ill never forget and always be grateful!


Comments are closed.