Category: News

UKanDo viewer 3.7.6: nips, tucks, tweaks

Posted on by Inara Pey

logoConnor Monaron issued the latest version (3.7.6.27995) of the UKanDo viewer on Tuesday April 22nd.

The update sees the viewer maintain parity with the Lab’s 3.7.6 code base, and introduces a number of tweaks and updates, as defined in the release notes.

Most notable among the latter are some further updates to the Preferences floater, a revised camera floater, and the import of some capabilities from other TPVs, notably Firestorm.

Preferences Updates

There are a number of updates to the UKanDo Preferences tabs with this release, including:

  • General > Avatar tab: check boxes for avatar turning added / re-introduced
  • Graphics > Hardware: now has a drop-down with options for Anisotropic Filtering
  • Move & View tab: camera mouse sensitivity slider added (slider to the left = slower, more controlled camera movement; slider to the right = faster camera movement); also numeric values added to sensitivity sliders (Mouselook and Camera)
  • Advanced tab: the check boxes (Allow Multiple Viewers, etc.) are now arranged in two columns
Avatar turning options in Preferences > Move and View, UKanDo 3.7.6
Avatar turning options in Preferences > Move and View, UKanDo 3.7.6

Firestorm Pose Stand

UKanDo 3.7.6 adds the Firestorm pose stand by Cinder Roxley with updates from Ansariel Hiller. This can be found on the UKanDo menu. This enables you to fit and adjust attachments, etc., wherever you are. The option does not require a physical pose stand to be rezzed – so it  can be used anywhere, regardless as to whether object entry / rezzing is disabled.

UKanDo 3.7.6 gains the built-in pose stand developed for Firestorm
UKanDo 3.7.6 gains the built-in pose stand developed for Firestorm

The pose stand animations will override those in your AO – unless your AO animations are very high priority. So if you find that you are not being posed when the Pose Stand window is open, then turn off your AO.

Firestorm produced a brief tutorial video when they originally released the pose stand. Note that the UKanDo implementation has a warning to remind users to disable their AO when activating the pose lock feature.

Other Items

As well as the above updates, UKanDo 3.7.6 includes:

  • camera
    The revised UKanDo Camera floater

    A smaller camera floater with button fixes (which could perhaps benefit for a drag-to-resize option)

  • Ability to prevent your avatar from automatically turning to face a selected object (from Firestorm / Ansariel Hiller)
  • Optional Viewer 1.x behaviour so your avatar turns to the camera direction after hitting ESC (see FIRE-6357 / Zi Ree)
  • Hide my group title option (via Kokua / Firestorm).

Related Links

Lab helps promote MOOC course for Spanish Educators

Posted on by Inara Pey

Following the recent Virtual Worlds Best Practices in Education Conference (April 9th-12th, 2014), Linden Lab has moved to help promote an upcoming Massive Open Online Course (MOOC) designed to help Spanish-speaking educators in the use of Second Life as a starting point in their interaction with emerging and innovative environments that can be used for education.

Professor Max Ugaz, UMSP
Professor Max Ugaz, USMP

The course has been developed by the Universidad de San Martín de Porres (USMP), located in Santa Anita, Lima, Perú, by the university’s Project Director of Virtual Worlds, Professor Max Ugaz.

Commencing on Monday, May 19th, the course will comprise three week-long modules with a total of 15 lessons and an average workload of around 5 or 6 hours per week.

The course details and registration form are available the university’s website, which includes an introductory video for the course (in Spanish).

The course will take place at one of the USMP’s teaching areas in Second Life.

Related Links

UKanDo announces support for automatic updates and version control

Posted on by Inara Pey

logoConnor Monaron has confirmed that the UKanDo third-party viewer is now using Linden Lab’s automatic update capability and viewer version manager.

This means that as of the current version of UKanDo  (3.7.4). As well as providing the option for users to have UKanDo automatically update on a new release, these changes mean that only the current release of UKanDo and the two immediately prior to it will be allowed to connect to Second Life; older versions will be automatically blocked, requiring users to update them.

The UKanDo blog post announcing these changes reads in full:

UKanDo now uses the Linden Lab® Viewer Version Manager (VVM) system for automatic updates and version management. As a user you have the option to set automatic or manual updates in Preferences-> Setup-> Software updates (by default it is set to Install automatically).

The release candidates tick-box is disabled as there are no plans what-so-ever to use this feature.

VVM is also used to control which versions can or can’t login to Second Life®. The versions which can login are the Current Release plus the two previous releases, all versions before these are now blocked!

One side effect to this is as a new version is released the older of the two previous releases will then become a blocked version.

Another side effect is, if you are trying to use a blocked version, it will update to the latest release before it allows you to login.

TPVs are being encouraged to adopt the automatic update / version management capability and / or to restrict their users to using the more recent releases of their viewer so as to lighten the load of having outdated versions of viewer which fail to leverage more recently improvements and capabilities (HTTP, interest list updates, fitted mesh, etc.). As such, UKanDo becomes the latest TPV to do so.

Lab asks for feedback on new Transaction History page

Posted on by Inara Pey

secondlifeOn Wednesday April 9th, I reported (under “Transaction History Oopsie”) on an error with the Transaction History page on people’s SL dashboards which lead to some upset and confusion after the familiar page was replaced with one that failed to show totals, and which had the familiar .XLS and .XML download options replaced by a single .CSV option.

The change lead to understandably negative  forum comments and a JIRA report (BUG-5664).

As a result of the upset, the page was rapidly withdrawn, and as I reported on April 12th, the Lab blogged on the matter, indicating they would be seeking users’ input to the matter going forward.

In line with this, the Lab issued a further blog post on Wednesday April 16th, entitled Try Out the New Transaction History Page, which reads in full:

Last week, we made a new page available as a replacement for the old Transaction History page. Due to your feedback, we rolled back the changes to this page to allow us to gather more feedback, and we are now providing this new page for review, without removing the old Transaction History page.

We have not yet made any changes to the new page, because we would like time to collect your feedback and review it. We have created a wiki page giving background on why changes were made to this page, where the new page is, and how to provide feedback. We will be closing feedback on April 30, 2014, so please take a look before then.

The wiki page repeats the blog post information, and confirms the primary reason behind the change:

The new Transaction History page was created to allow more than 500 transactions to be displayed for Residents with very active businesses.

It also invites people to provide feedback via the original BUG-5664 JIRA report raised by Sera Lok, which is open to comment for feedback.

Please bear in mind when examining the “new” Transaction History page, that no changes have been made to it since it was first revealed on April 9th – it is given purely as an example so that people can better identify and report issues they may have with it when comparing it to the existing Transaction History page.

People have been asked to provide feedback by Wednesday April 30th.

Reading through the comments, some constructive points have been put forward, although the range of comments doindicate the complexity of implementing changes like this, with people falling almost equally either side of individual changes. For example, many feel that providing only a .CSV download isn’t a problem, but an equal number feel that .XLS (and .XML) should be retained, as .CSV can create problems when it comes to processing the data contained n the downloaded file. Were I to be asked, I’d suggest that retaining .XLS (/ .XML) alongside .CSV would offer the most flexible approach. Backwards compatibility and not breaking legacy content (including scripted processes) has long been a watchword for the Lab when making changes to the SL platform – and this attitude should be carried forward with supporting services as well, such as the Transaction History page, to accommodate all those who have processes reliant on receiving their transaction data in .XLS.

What is healthy is that the Commerce Team appear to be listening and making a genuine effort to understand issues and concerns. Coming so long after what seems to have been a deliberate policy of disengagement by the team from merchants in many areas, this is undoubtedly welcome.

One can only hope this willingness is further reflected in how the new page is refined and updated going forward.

Lab provides Heartbleed information

Posted on by Inara Pey

This is a little long in the tooth, but I’m caught playing catch-up on a number of things, so apologies on my part.

As most will be aware, there has been a lot of coverage about the Heartbleed OpenSSL vulnerability in the course of the last week, and the impact it may have had over the last two years in exposing what should have been secure information.

The vulnerability is so-called because it affects an extension to SSL (Secure Sockets Layer) which engineers dubbed Heartbeat. It is a server-side exploit which could affect almost any system running any version of OpenSSL from the past 2 years, and allows an attacker to gain control of up to 64kB of the server’s working memory at a time, enabling them to eavesdrop communications, steal data directly from the services and users and to impersonate services and users.

Because of the widespread nature of the issue and the concerns it raised, the Lab issued a blog post on the matter on Thursday April 10th, which reads in full:

Many of you may have read about the Heartbleed SSL vulnerability that is still affecting many Internet sites.

You do not need to take extra action to secure your Second Life password if you have not used the same password on other websites. Your Second Life password was not visible via Heartbleed server memory exposure. No secondlife.com site that accepts passwords had the vulnerable SSL heartbeat feature enabled.

If you used the same password for Second Life that you used on a third-party site, and if that third-party site may have been affected by the vulnerability, you should change your password.

Supporting sites such as Second Life profiles are hosted on cloud hosting services. Some of these sites were previously vulnerable to Heartbleed, which may have exposed one of these servers’ certificates. As an extra precaution, we are in the process of replacing our SSL certificates across the board. This change will be fully automatic in standard web browsers.

Thank you for your interest in keeping Second Life safe!

Due to the weekend, there has been no further news as to whether the Lab has completed replacing the SSL certificates for those services which may have been exposed. Hopefully there will be a further update on Monday April 14th. In the meantime, if you have used the same password for SL that you used on a third-party website and wish to change your SL password as advised in the blog post, you may want to refer to the Lab’s password protection page on the wiki.

Lab to seek feedback on Transaction History page changes

Posted on by Inara Pey

On Wednesday April 9th, I reported on an error with the Transaction History page on people’s SL dashboards which lead to some upset and confusion after the familiar page was replaced with one that failed to show totals, and which had the familiar .XLS and .XML download options replaced by a single .CSV option. The change lead to forum comments and a JIRA report (BUG-5664).

The page itself was reverted around an hour after concerns were first raised, and Ebbe Altberg stepped into the forum to offer apologies and an explanation:

In an attempt to improve we made a few mistakes and caused some misunderstandings as well. We rolled back the changes and will work on getting it right. The team is looking at feedback and will communicate a plan for how to get there.

On Thursday April 10th, the Lab issued a blog post on the matter, providing further information on the situation, including the fact that they will be seeking input from users on proposed changes to the Transaction History page.

The post reads in full:

Earlier this week, we rolled out a few changes to the Account Management web pages for logged-in users at SecondLife.com, which were aimed at improving these tools for users. One of the changes we made updated the Transaction History page, and we heard lots of feedback that not all of the changes to that page improved our customers’ experiences or met their needs. So, we quickly reverted to the old Transaction History page.

We’d like to get some additional user feedback on the new Transaction History page so that when we make the changeover, the functionality best matches what Second Life users want and need. Once we are ready, we will post instructions on how to review the new page and provide feedback. We will not take down the old page until we have had a chance to review feedback and make appropriate changes to the new page. Check back on this blog for more details as they become available.

This is a positive step by the Lab, both in rectifying the error rapidly and in admitting their mistake. Hopefully, I’ll have a further follow-up once the additional information is published by the Lab.