Category: V7 Style

Kokua offers .DAE exports

Posted on by Inara Pey

kokua-logoKokua have released a further update in the form of version 3.6.3.29169 (August 23rd). With it comes some important notes, and the addition of the .DAE (Collada) object export capability.

Installation Notes

This is the first release from Kokua to use the auto update mechanism from Linden Lab, which was incorporated into the viewer with release 3.6.2. However, for Windows users, there are two important points to note:

  • If you are a Windows user and have a pre-3.6.2 version of Kokua installed on your PC, you should first try to run the viewer and allow the auto-update process to fetch and install the latest release. This should work OK with versions of Kokua at least back as far as version 3.6.1.28998 (June 28th 2013).
  • Because all Windows versions from 3.6.2 onwards are installed into a folder called Kokua (rather than Kokua Viewer). So if you have a version older than 3.6.2 already installed on your PC, note that the new version will be installed alongside it, rather than over it. If you then subsequently remove the older version using the uninstaller, your settings (located in C:\Users\[username]\AppData\Roaming\Kokua) will be lost – so make sure you back-up / move this folder before removing any old versions of the viewer & then restore it afterwards.

Those on older versions of Kokua (pre-3.5.1? I’m not entirely clear on this from the blog post) may find that the updater will direct them to install the official SL viewer from the Lab. As Nicky points-out, this is not some conspiracy to force people into using the SL viewer. Should it happen, quit out of the installer and use the Kokua download links (and take note of the 2nd bullet point above).

Collada Export

The major update for Kokua 3.6.3 is the inclusion of the Collada .DAE export capability which was recently added to Singularity, together with the ability to export objects in Wavefront .OBJ format. As the Singularity team made the export options available under a LGPL licence,  Jessica Wabbit has extracted the.DAE export capability and contributed to Kokua.

The export option works in exactly the same manner as with Singularity: it respects object permissions, and you can only export those objects for which you are the creator and owner.

To export an item which fit the criteria, simply right-click on it and:

  • If you are using context menus, select EXPORT > COLLADA DAE
  • If you are using the pie menu, select MORE > MORE > EXPORT COLLADA DAE

Either option will open a window allowing you to save the object to your hard drive. Once exported, the object can be used into applications which support the editing of .DAE files and / or imported as mesh to other virtual environments.

The DAE expoert options in Kokua's context and pie menus. If you're not the creator & owner of the item you're trying to export, they won't be available to you
The DAE export options in Kokua’s context and pie menus. If you’re not the creator & owner of the item you’re trying to export, they won’t be available to you

Note that if you do not have the requisite permissions to export the item, the export option will be unavailable on both menus.

Currently, the system only exports naked prims / sculpts (no textures), but this may be changing in the future – keep and eye on the Singularity team for news.

Commenting on the export capability, Kokua’s Nicky Perrian has said that if there is sufficient interest, the option to export to .OBJ may also be added to the viewer.

Additional Updates

This release sees Kokua use the Lab’s viewer 3.6.3 code base, and the following updates / additions:

  • The upcoming OpenSim Community Conference grid on OS Grid has been added to the grid drop-down list
  • Some tuning of the auto-update feature
  • Addition of a plain text chat history option in the chat preferences tab
  • Addition of new “Permissions” sub-menu for friends on the People floater for setting the usual options of whether friends can see when you’re on-line, etc. Enabled options display the requisite icon alongside the avatar’s name
  • Addition of group and role UUIDs at the end of the group’s General and Roles panels.
(l) Setting permissions for friends can now be done via a sub-menu int he people folder; (r) the UUID for a group can now be obtained from the group's general tab (role UUID can also be obtained from the Roles tab)
(l) Setting permissions for friends can now be done via a sub-menu int he people folder; (r) the UUID for a group can now be obtained from the group’s General tab (role UUID can also be obtained from the Roles tab)

Feedback

Another, small, tidy update with Kokua which adds what is likely to be a popular feature, given the excitement which followed Singularity’s release with the export options. Using Kokua 3.6.3 myself (although again very briefly due to RL commitments), I found it to be fast, stable and smooth – pretty much as with 3.6.2.

As I already had 3.6.2 installed, I allowed the auto-updater to upgrade me. This actually took a few seconds to acknowledge that an update was available (the delay seemed to be longer than the official viewer, which often has the update pop-up appear as soon as the splash screen has loaded). This tiny point aside, update was smooth and returned me to the log-in splash screen when finished, with 3.6.3 ready to go.

It’s great to see Kokua rolling along like this.

Related Links

Kokua 3.6.2: all set for auto-update

Posted on by Inara Pey

Update August 21st: Nicky Perrian from Kokua has added a comment about a Windows issue with uninstalling, due to a change in the installer.

kokua-logoKokua released version 3.6.2.29072 on August 16th, becoming the first TPV to start operating LL’s viewer update capability since the Lab formally announced it was making the capability available to TPVs if they want to make use of it (Catznip has actually has an auto update capability since release R7, but I’m not clear on whether that uses any of the LL code, or is something the Catznip team built for themselves). Along with this change comes a number of smaller updates.

Download and Installation

The latest Kokua installer (Windows) weighs-in at 36.8 Mb. As expected, the installer runs without a hitch. As I’m still getting around to re-installing viewers on an “as needed” basis on the new PC, I didn’t have to perform a clean install (not that one is recommended in the release notes).

Auto Update

Oz Linden announced that the Lab would be making their viewer release mechanism available to TPVs via an e-mail earlier in the month and also at the TPV developer meeting on Friday August 9th, when he indicated that the Lab were already working with some viewer development teams to help them implement it, Kokua clearly being one of them.

Kokua implements LL's viewer update mechanism code
Kokua implements LL’s viewer update mechanism code

With Kokua, the update options are presented exactly as they are in the official viewer – complete with the check box to update to release candidates. Whether this means Kokua will be completely following suit with the overall release process implemented by the Lab, I’ve no idea.

Obviously, while the code is from LL, viewer updates obtained via it are still coming from Kokua – it doesn’t mean people sill suddenly start getting SL viewer updates!

The change does mean that from now on, updates will be obtained from Kokua’s SourceForge repository as the code does not work with BitBucket. However, the team are at present continuing to post updates to both BitBucket and SourceForge.

Additional Updates

This release brings the viewer up to parity with the Linden Lab 3.6.2 code base, which means it has the more recent materials processing code updates, although not necessarily the very latest to surface in the SL Materials Project viewer, and well as other recent updates within the official viewer. Other notable updates comprise:

  • A return to standard SL viewer Debug for the login menu. This allows the selection of Debug level before logging in
  • “Stop animating me” short cut has been assigned to Shift-S
  • There are several Linux build changes to allow compiling on current compilers (builds on gcc-4.7 and gcc-4.8 have webkit runtime issues)
  • Maximum number of groups has been corrected for OpenSim
  • Freeze/Unfreeze and Eject/Ban context menu options have been added to the people / radar floater, as per Feature Request #1254
  • The Reach Out slider on the people floater mini-map is renamed Radar Range, has been repositioned above the mini-map and now has a maximum range of 4095 metres
  • The Map button in the tool bar is renamed World Map
  • Clicking on the bandwidth or packet loss graph will bring up the Statistics floater
  • The middle mouse button can now be used as a paste function and / or to scroll the world map.

This is another small but very tidy update for Kokua, and the release notes are available on the Kokua blog. While I only had a very brief time to try it out over the weekend, I didn’t notice any issues of import / impact (other than the issue of mesh clothing on other avatars failing to render, which I frequently encounter on Firestorm and the official SL viewer, so is not a Kokua issue).

All-in-all a tidy update.

Related Links

Firestorm meeting 10th August, 2013 – video and transcript

Posted on by Inara Pey

firestorm-logoOn Saturday 10th August, 2013, the Firestorm team hosted a question-and-answer session so they could outline the current status of the Firestorm viewer, the issues the team are facing, and outline plans for the future, as well as address questions from the audience.

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 were asked in chat while speakers were talking. This inevitably meant that replies to questions would lag well behind when they were originally asked. Therefore, to provide context between questions and answers, questions in the transcript are time stamped at the point at which each is addressed by a member of the Firestorm team
  • Some questions were asked and answered purely in text. These have been excluded for one of two reasons. Either a) they lacked context with the voice conversation, or b) the seating arrangements in the auditorium meant there were some questions or answers which didn’t appear in my local chat window.

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.

Video courtesy of Northspring

Continue reading “Firestorm meeting 10th August, 2013 – video and transcript” →

New viewer release process implemented

Posted on by Inara Pey

Update, September 15th, 2024: the viewer release process defined below has been replaced:

  • Linden Lab now maintains a single Develop branch for the viewer, into which updates all pass for internal viewer builds, and from which Release Candidate viewers are peeled and made available.
  • This is tied to a “featurettes” approach to new features and capabilities, whereby these may be added to the viewer and deployed within Release Candidates, but place behind debug settings / remain “turned off” until such time as all dependencies on their use (e.g. back-end support) are in place / LL are confident they are ready to be made fully available. 

Update July 23rd, 2013: As release candidate viewers are now available for download on the Alternate Viewers wiki page, I’ve added some notes on manually installing and running multiple release candidates to this article.

secondlifeThe new viewer release process announced by the Lab in May 2013 has officially been implemented.

Officially called the Viewer Integration and Release Process, It is designed to improve how the Lab can put new viewers before users and progress them through to a release status while avoiding bottlenecks such as those witnessed in late 2012, when an issue with the Viewer Beta channel effectively stopped any new viewer releases for around a two-month period.

With the new system, early versions of viewers will still be made available through “dedicated” project and beta viewers, all of which will be available for download via the Official Alternate Viewers Page. However, the major change to the process is the use of “release candidates”.

When a viewer is ready for final testing, a release candidate will be readied. Rather than residing in their own dedicated viewer channel, these release candidates will be updates in the regular release channel, residing in a named “cohort” within the channel.

The new Viewer Release and Integration Process means that viewers can be better developed tested and prepared for release in parallel

This means two things. Firstly, release candidates are available for download alongside one another and the default release viewer. Who might receive a given release candidate is a random selection based on a viewer setting (see below) and a pre-determined quota of downloads for the candidate (once the quota has been reached for a given candidate, the system will no longer select it for download).

Secondly, when a specific release candidate is deemed ready for release (based on bug reports filed, issues reported and fixed, stats gathered, etc.), there is no longer any need to rebuild it as a “release” viewer, as it is already in the release channel. It is simply moved from its named cohort to become the default release version on the SL viewer download page. Any remaining release candidates are then rebuilt using the new default release code, and continue with testing until one is deemed ready to become the next release.

From a user perspective, release candidates are largely indistinguishable from one another and the default release viewer (other than their version number and the features they contain), and the chances are that some users will be unaware that they have been selected by the system to run a release candidate; they will simply see it as receiving an automatic / mandatory viewer update, and install it.

“Willing to Update” and Release Candidate Downloads

As mentioned above, users who receive a release candidate viewer are selected at random, based on a defined quota of downloads for a given release candidate. However, whether or not a user might be selected to receive a release candidate viewer depends on whether or not they have left the “willing to update” option enabled in their current viewer.

Located in Preferences > Setup, “willing to update to release candidates” (to give the option its full name) is enabled by default. But just because it is, does not automatically mean someone will be selected to test a release candidate viewer. This is because the download quota defined for any given release candidate will always be relatively small when compared to the SL user base as whole.

However, if you don’t wish to run any release candidate viewers at all, you can disable this option, and only receive viewer updates when the default release viewer is updated.

Another point to remember with release candidates is that users won’t be moved between release candidates as a result of updates. So if you leave the “willing to update” option enabled and you happen to be selected for testing “release candidate A”, you won’t suddenly start receiving updates for “release candidate B”; you’ll stay with the updates for “release candidate A” until such time as it becomes the default release viewer. Only then might you be selected to receive another release candidate download at some point in the future.

Download Page and Alternate Viewers Page updates

As a result of the move to the new release process, the SL viewer download page has been updated, and there is no longer any link to download the “Beta Viewer”. Instead, there is a link which takes you to the Official Alternative Viewer wiki page, which instead lists all available beta and project viewers.

The Beta Viewer section of the viewer download page now takes you to the Official Alternate Viewer wiki page
The Beta Viewer section of the viewer download page now takes you to the Official Alternate Viewers Page

The Importance of Version Numbers

An important aspect of viewer bug reporting has been to give details of the viewer you’re running, including the version number. This information is requested in the “Environment” section of the bug report form. Given that the new viewer release process means there can be a number of release candidates in use at any given time, as well as various beta and project viewers, it is even more important that this information is given when raising a bug report.

Displaying details of the viewer you are using, including its version number
Displaying details of the viewer you are using, including its version number

Viewer information can be found in the About Second Life floater (Help > About Second Life), if you’re not already familiar with it. Further, the information on this floater can be copied directly to your clipboard ready to be pasted in a bug report to save you having to manually enter it.

Notes on Manually Installing Release Candidates

Viewer release candidates are now listed on the Alternative Viewers wiki page, and can be downloaded and installed, if so desired. If you do opt to do so, please note that release candidates are contained in “cohorts” within the viewer release channel, and are designed to overwrite any release candidate viewer you have installed. Therefore, if you wish to manually install multiple release candidate viewers side-by-side and with the de facto release viewer, you much ensure, in accordance with your operating system, that:

  • Any shortcuts / start menu links (e.g. Windows) you have for the viewer are renamed before you install any release candidates
  • Each release candidate is installed into a unique folder
  • Any shortcuts / start menu links (e.g. Windows) which are created as a part of the installation process are given unique names before installing the next release candidate

Notes:

  • If you provide unique destinations for each release candidate installation thorugh the installer package (e.g. Windows), make sure the installer is listing the correct destination folder when manually downloading and installing a subsequent release / update
  • The Windows auto-updater will automatically install into the last folder defined in the viewer installer (so if you have manually installed “Release Candidate A” and then “Release Candidate B” into separate folders, then get an update for “Release Candidate A” via the auto-updater, it will install into the folder for “Release Candidate B”)
    • Disabling the auto-updater in Preferences may not stop this from happening.
    • Instead, go to  viewer install folder/app_settings, then edit settings.xml, and find the entry UpdaterServiceURL and change  https://update.secondlife.com to https://secondlife.com/no-thanks (or similar) and save. You may need Admin privileges to do this.

Changes to this Blog

I maintain a list of viewers recognised as being used with Second Life (predominantly, but not exclusively, based on the Third-party Viewer Directory), which is updated as a when I become aware of new viewer releases being made. The section of this page which deals with the SL viewer has been updated to reflect the new viewer release process, and now includes all SL viewers currently listed in the SL viewer download page and the Official Alternate Viewer wiki page (with the exception of the Amazon channel viewer, which is the version of the viewer offered through Amazon.com).

Related Links

Calling all Firestorm users: get ready for an emergency update

Posted on by Inara Pey

firestorm-logoUpdate July 2nd: version 4.4.2 has been released by the Firestorm team, and Firestorm 4.4.1 has been blocked from accessing Second Life. If you have previously installed Firestorm 4.4.1, you can install 4.4.2 without needing a clean install. If you are updating from Firestorm 4.4.0 or earlier, a clean install is strongly recommended. The downloads can be found on the Firstorm website.

Firestorm 4.4.1 was release on June 27th. However, it will shortly be superseded with Firestorm 4.4.2.

The reason for this is explained in a new Firestorm blog post, but the short version is that due to a slight mishap, some additional logging capabilities which had been enabled during the beta release of 4.4.1 and which were intended to help Linden Lab gather information for the forthcoming release of Server-side Baking / Appearance were not removed from the viewer when it moved to release status.

As a result, the system the Lab uses to gether data on viewers is now being completely overwhelmed by the amount of data Firestorm 4.4.1 is sending to it. Although it has taken a few days for the problem to be identified and the Firestorm tem notified, the result is that they are now taking some emergency corrective action:

  • With immeidate effect, version 4.4.1.34164 of Firestorm has been removed from the Firrestorm download page
  • A new version for Firestorm is being prepared for release. This version – 4.4.2 – will be no different to 4.4.1 other than the removal of the additional statistics logging code
  • When the new version is released, and to ensure the LL service is no longer inundated with excess data, Firestorm release 4.4.1.34164 will be blocked from accessing Second Life.

It is therefore essential for everyone who has updated to Firestorm 4.4.1 keep an eye on the Firestorm blog an update to Firestorm 4.4.2 when it becomes available. This should not require a clean install (as was the case with 4.4.1) – but please double-check with any associated blog post which is forthcoming when the release is made.

Again, it is essential that all users of Firestorm 4.4.1 update to Firestorm 4.4.2 as soon as it becomes available.

Related Links

Firestorm 4.4.1: It’s time to update

Posted on by Inara Pey

firestorm-logoUpdate July 2nd: version 4.4.2 has been released by the Firestorm team, and Firestorm 4.4.1 has been blocked from accessing Second Life. If you have previously installed Firestorm 4.4.1, you can install 4.4.2 without needing a clean install. If you are updating from Firestorm 4.4.0 or earlier, a clean install is strongly recommended. The downloads can be found on the Firstorm website.

Firestorm 4.4.1(.34164) arrived as a release on Thursday June 27th. This is another major update to SL’s most widely used TPV, and one which all Firestorm users should update to sooner rather than later.

The reason for this latter comment is one which should be familiar to anyone who regularly reads this blog – Server-side Baking / Appearance (SSB/A) is a-coming.

Subject to final confirmation, the Lab plans to start deployment of the server-end of the capability on July 9th, and while it might take a while to encompass the entire grid, it will mean that anyone using a pre-4.4.0 version of Firestorm is going to start seeing increasing numbers of grey avatars around them as they travel the grid and (quite likely) finding themselves being told they are a cloud when seen by others.

Updating sooner rather than later will also greatly assist those volunteers who give up copious amounts of time to help with the in-world Firestorm Support groups. Right now, the Firestorm team estimate more than 77,000 users are still running versions of Firestorm older than 4.4.0, and thus have no SSB/A capabilities. It’s going to be impossible to supply all of these users with support and advice if they all leave updating their viewer until the 9th July or later – so please, if you are reading this review and you are using a version of Firestorm older than 4.4.0, consider updating now.

Doing so means that should you need to contact the Firestorm support team directly, because you are encountering problems and cannot find help through the Firestorm wiki or the troubleshooting index, you’ll be far more likely to receive a timely response to your request for assistance.

Even those who have updated to 4.4.0 should make the move to 4.4.1, as it includes the very latest updates and fixes for the SSB/A code from LL. Outside of SSB/A, release 4.4.1.34164 offers a number of important fixes for 4.4.0, and so it’s again important for 4.4.0 users to step up to 4.4.1 to gain these benefits.

As always, there is a lot to cover in a Firestorm release, so I’m not going to plough through everything here – the official change log provides a breakdown of all updates and fixes. Instead, this review focuses on what I regard as the key updates / changes. As always, credits for the various updates and contributions to Firestorm which are mentioned here can be found in the release change log – again, please check them there.

What is NOT in this Release

I’m actually going to start with what is not in the 4.4.1 release. It does not include the following major updates from the Lab:

  • The Communications Hub User Interface
  • Materials Processing

The reasons for this are simple. For one thing, the Firestorm team have been largely focused on fixing issues and problems with Firestorm and on getting the viewer ready for the SSB/A release. This  left them with little time to get changes resulting from the CHUI release by LL integrated into the viewer, although considerable work has been carried out in refactoring the code.

Similarly, there is no Materials Processing capability included with this release. This is in part because the Lab themselves have only recently moved the materials code to a release status (and it still has a number of very visible bugs associated with it), but mostly because changes made to the viewer as a result of the introduction of CHUI affect files which are also changed by the materials project. It is therefore important that the Firestorm team implement the changes in the same order – changes as a result of CHUI first, then the materials changes.

So those wanting to use materials in Firestorm are, unfortunately, going to have to wait a while longer.

New Features and Improvements from the Lab

Note these also include work by the Firestorm team arising from LL-development viewer updates.

  • “Missing prims fix” – MAINT-2647 / BUG-2116 / FIRE-8950 – this should hopefully resolve the majority of issues around prims / linksets failing to render in the viewer until an action such as right-clicking on them or toggling atmospheric shaders off / on is taken
  • Merge up to 3.4.5 codebase plus cherry picked fixes plus server-side appearance support improvements
  • Major under the hood refactoring in preparation for the CHUI merge
  • Added RegionHandshakeReply flags for Server-side Appearance – a fix for the SUN-74 issue.

Snapshots Fixes

Firestorm 4.1.1 includes an interim fix for the issue of black rectangles appearing in snapshots taken at very high resolutions. Note that this fix is not the recently released additional fixes arising from MAINT-628 made by Linden Lab. These fixes will be included in an upcoming release of Firestorm, and so the current fix should be considered interim.

Communications Updates

Radar can now be accessed via its own button / menu option / floater for those who prefer not to access it via the People floater. The new button can be selected from the Toolbar Buttons floater, which will open the new Radar floater. Additionally, Radar can be accessed via World > Radar from the menus.

The new Radar floater (left) and optional Toolbar button, compared to Radar as it appears in the Nearby tab of the People floater
The new Radar floater (left) and optional Toolbar button, compared to Radar as it appears in the Nearby tab of the People floater

The Radar retains all functions found when displaying it in the Nearby People floater, including the ability to display the mini-map within it.

The Payment icons on the Radar / Nearby People floaters have also been updated: $ indicates the user has Payment Information on File; $$ indicates Payment Information Used.

For those who use the Friends list (Comm > Friends or CTRL-SHIFT-F), highlighting a person’s name in the list and then tapping ENTER will start an IM conversation with that person (no need to click the IM button).

For those who use Growl, dialogue messages and inventory received from object messages are now displayed with Growl. In addition, all Growl preferences check boxes will only be enabled if Growl is installed on the user’s system.

Navigation Updates

Beacon distances are now shown for the
Map beacon ranges now show the distance from the avatar, not the camera

Firestorm 4.4.1 removes the 2-second delay when using the click-to-teleport functions or teleport chat shortcuts (gtp, etc.) or the Teleport To function in Radar.

A new option allows region grid coordinates to be displayed on the World Map (Preferences > Move & View > Firestorm > Show grid coordinates on the world map), which OpenSim users might perhaps find more beneficial than most SL users.

Also, map beacon ranges now show the distance from the avatar, not the camera.

Continue reading “Firestorm 4.4.1: It’s time to update” →