Kokua Release (RLV) and (NORLV) including Alex Ivy for Linux

Please note: Sourceforge is currently experiencing difficulties. If you find you can’t download a new version or get to the Issue Tracker please be patient and try again later.

The headline news for these versions is the first release of an Alex Ivy Linux build as part of the release set.

This version is at parity with Linden Lab viewer release 5.1.3 and also with RLV for the RLV edition.

Some areas of the Linux release are still being worked on, however we believe that enough is working and well enough to share this with a wider audience to help us squash any remaining gremlins.

Please raise any issues you find via the Kokua Issue Tracker at Souceforge https://sourceforge.net/p/team-purple/kokua/tickets

Here are the other changes in this release compared to and

  • Both: Resolved a bug that could cause incorrect textures to be used to render water when viewed from high up (more than 1000m). The viewer will now not render anything for the water until considerably closer.
  • Both: Remove reporting of the region corner in decimal from Help > About (this was left over from the OpenSim code removal – the standard Linden Lab message with global coordinates is still there)
  • RLV: The behaviour of the blind-at-login feature is improved in this version. The decision whether to apply the blinding is now taken automatically based on whether any items have queued RLV restrictions before the viewer begins processing them (as will typically be the case with worn items reapplying restrictions from the previous session). If you want to always have the blind behaviour (or have problems with late arriving attachments failing to trigger the automatic code) you can set the option “Always apply blinding effect upon login” which can be found on Preferences > Kokua > General below the RLV enable switch. It can also be edited directly using the debug setting KokuaRLVAlwaysBlindStartup. The former KokuaRLVNoBlindStartup debug setting which was used in previous versions is now obsolete and does nothing.

Kokua Releases RLV and NORLV

Kokua announces the release of:
Kokua Release RLV/ and Kokua Release NORLV/

This version of Kokua is at parity with Second Life Viewer V5.1.3.513644 ( http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Release/ ) and in the case of the RLV version also with RLV

Starting with this release we will keep the viewer version (5.1.3) aligned with Linden Lab to make it easier to confirm the latest version is being used. When LL releases a 5.1.4 viewer we will increment to 5.1.4 too. The new Second Life Viewer version includes a number of media-related improvements and newer component versions – see the viewer release notes for more details.

Kokua gains the ability to report on changes in the number of scripts in a region, changes in the server channel with changes of region found in other viewers and much much more.

All the new features can be found on the Performance 1 and Performance 2 tabs within Edit/Preferences/Kokua.
The idea behind these is not that most people will want to turn everything on – that’s a surefire way to swamp the screen with too much performance related information. The actual idea is that most people will want to use only a few of the possible options that reflect on specific interests such as how many avatars are in a region, how many scripts are running, how the physics simulation is performing or overall timing information. Think of it not as a big hammer to use but rather a toolkit of very specific tools to use only when each is best suited.
The first section of the Performance 1 tab deals with notifications on entering a new Region. Once the region entry notification is enabled it has options for additional information about channel, agents (avatars), scripts, timing and basics (Time Dilation and Frames Per Second). You may also choose to have this information repeated with every performance notification if you wish to see more detail when one particular measurement goes out of limits. This is followed by the options for a notification if the server software channel version of the region just entered is different to the previous one and another option to control whether notifications are given when a statistic returns within limits as well as when it goes outside. While this can be useful for knowing when an out-of-threshold situation has ended it also doubles the number of notifications. The rest of Performance 1 consists of the individual areas for Agent and Script notifications. The notifications can be turned on and off as a group allowing individual settings to be maintained. Each option then has its own enable checkbox and a slideable/writable value to set the threshold. Changes in this window are immediate and do not need OK selected to apply them.

Performance 2 consists of similar areas covering Frame Timing and Basic Performance. Within the Frame Timing group there are additional options to display the whole frame timing information every time the whole frame exceeds its threshold or every time any component exceeds its own threshold.

Finally there is an option that selects whether output from these features is displayed as a notification in the top right and in chat history or just in chat history (perhaps with a chat toast too if the chat history is not visible at the time).

It should be noted that blips in most of these statistics will occur and are often part of normal Second Life operation. For instance, when an avatar arrives in the region the statistics will reflect that the region is prioritising completing the arrival and in particular will often give a lot of script time to get the avatar’s scripts running again which will then settle down as the transfer fully completes. This also means that when you have region entry statistics enabled and arrive in a new region yourself the values will often be abnormal since the region is prioritising your arrival.

All of the statistics have default values which are intended to be representative of fairly average performance. Where a statistic is of interest it should be enabled and then the threshold value adjusted so that most of the time the performance in the area of interest is within that threshold. You can tell when you pass the current value during adjustments by the generation of a notifcation each time the value being adjusted passes the actual value.

Although the basic statistics of Frames Per Second and Time Dilation are included they are generally of less value now than some years ago since regions have become much better at managing their time distribution and in particular at limiting script time to stay within the overall target frame of 22.5 ms. Should you see a region that is consistently failing to maintain FPS or TD it is either significantly overloaded beyond its self-management capabilities or has something wrong and would benefit from a reboot.

Homestead and Open Space sims are intended for very light use. In both cases it will be observed that script performance is strongly and deliberately limited. The script run percentage will start to drop well before the region runs out of frame spare time. In contrast mainland regions typically perform as well as a full private region (island) under all but the heaviest loadings.

Finally, here are some tips about what to watch for in specific situations.
If you are interested in vehicles then enabling the Physics time section of the frame monitoring is an essential. Turning on the ‘include whole frame information’ option is also recommended so that other factors can be seen at the same time as the Phsyics portion overruns. Enabling notification of changes in the region agent count is also recommended since arrivals and to a lesser extent departures will cause the region to re-prioritise its timings. Successful region crossings with vehicles depend a lot on how much data has to be transferred, so the lighter the vehicle load (and its passengers’ scripts, attachements and rendering complexity) is the easier and more likely a successful region crossing will be.

If you are interested in the overall health of a region various features should be enabled to allow notification of unusual situations, particularly total number of objects and active objects, total number of scripts, overall frame time, script time and physics time particularly.

If script performance is the most important aspect then most of the notifications in the Script Notifications section will be of interest together with overall frame time and extended region entry notifications
Should you wish to monitor most of these statistics continually they are available in any viewer by selecting SHIFT-CTRL-1 for the full Statistics window or SHIFT-CTRL-2 for the Scene Load Statistics. Unfortunately the latter omits one or two important statistics, notably the script execution percentage.
More information on the meaning of each statistic can be found here: http://wiki.secondlife.com/wiki/Viewerhelp:Statistics together with some performance tuning hints here https://community.secondlife.com/knowledgebase/english/how-to-improve-viewer-performance-r601/Section_.3

The new Performance 1 tab within Kokua Preferences
The new Performance 2 tab within Kokua Preferences
An example of a Homestead showing script limiting taking place well before the region runs out of frame spare time (the screenshot is of the standard CTRL-SHIFT-1 Statistics display mentioned above)

Path Forward – The Future

Readers of this blog will be aware of the previous postings in the Path Forward series where Nicky laid out his plans to scale down Kokua involvement to achieve his goal of taking a less active role to coincide with his 75th birthday and the completion of integrating LL’s Alex Ivy (64 bit) work into Kokua.

Originally Nicky had planned to scale back to a point where the only active development was on the non-RLV Second Life version of Kokua, however after various requests from the community the Second Life RLV version remained active too. The work on Alex Ivy also took longer than expected and while the 5.1 viewers are now available for PC and Mac there is still no Linux Alex Ivy version from LL upon which to base a Kokua version.

Kokua occupies a unique position in the TPV landscape. It incorporates Marine Kelley’s RLV features however its main origin is the latest current version of the LL viewer. Unlike larger projects like Firestorm which are forced to work on a formal release schedule Kokua has always had the agility from its smaller team size that allows it to make and implement rapid decisions about when to integrate versions, apply new features or generate releases. This means that historically Kokua has always been prompt in incorporating new releases from LL and Marine Kelley.

While Marine’s own viewer is the authoritative RLV implementation it is also very true to LL’s standard implementation with relatively few added features. In contrast Kokua is feature-friendly and provides a way for people to use Marine’s RLV implementation alongside the added features most Third Party Viewer (TPV) users have come to expect.

Earlier this year when it became apparent that no-one else had heeded the calls for new team members Chorazin Allen chose to become involved. Chorazin brings to the team project management, software development and build experience coupled with many years’ experience of inworld LSL scripting and working with RLV/RLVa although he freely admits his C++ is best described as ‘rusty’ – the original motivation for not volunteering sooner.

During the past few weeks Chorazin has been getting integrated into the team, setting up the necessary build systems and has reached the stage where the last few releases and build merges have been done by him rather than Nicky.

There is still quite a bit of integration to complete, like setting up accounts on the various Kokua websites, blogs, wikis etc. We will probably also move kokuaviewer.org to new hosting in due course.

Kokua will continue to be actively developed and maintained as a Second Life viewer with both RLV and Non-RLV versions available. We have recently completed a behind-the-scenes exercise to realign these versions more closely with LL’s latest sources to make future maintenance easier and ensure we are closely based on the latest viewer.

Chorazin is now project prime and release manager as well as prime developer for both Windows versions and RLV/RLVa expert. Nicky continues with the Mac versions as well as tracking LL’s work towards an Alex Ivy linux 64 bit version. The Open Sim versions are not maintained.

While Kokua’s future is now secure, we must scale our activities to match our resourcing. The Windows and Mac Alex Ivy-based 64 bit versions will be fully maintained (RLV and non-RLV). No other versions will be maintained (aside from working towards a Linux Alex Ivy version). Open Sim versions will not be actively developed until/unless someone with strong Open Sim experience joins the team. We must also scale our various communication media appropriately.

The Kokua group within Second Life is the preferred medium for user-to-user support and will also be used for group notices about new versions or other significant developments. The Kokua wiki will continue to be used for viewer release notes (as seen in the viewer when a new version is launched) and for the summary of current versions and download sites. We will also continue with occasional announcements on this blog.

Other past communication media such as Twitter or IRC will no longer be supported (and in most cases have been in disuse for a while already).

The preferred method of communication to the team is via a ticket raised in Sourceforge against the Kokua Project. This allows us to formally track requests/bugs and ensures someone on the team is assigned the ticket and can respond to it.

As well as continuing with release parity to LL and Marine’s viewer there will also be occasional original features and continued integration of the best of other viewers’ features. In the past Kokua has imported features from other viewers (notably Firestorm) and this trend will continue.

We will also continue our policy of releasing fast and often, typically whenever we see a feature, bug fix or integration as significant enough to warrant a new release. There is a downside to this. Sometimes this will mean that integration errors or bugs will slip through. We accept this as a side-effect of our rapid release cycle and will generally get a correction out as soon as possible once we’re made aware of a problem. The upside of course is that Kokua users will usually have the very latest LL and Marine features at their fingertips combined with Kokua’s established integrations of additional and original features.

Finally, we should publicly note our gratitude to Nicky for his sterling, and often solo, work on Kokua. Without Nicky’s efforts and persistence, as well as his decision to stay with it until Alex Ivy was finished, there would be no Kokua today. Thankyou from the whole Kokua community!

Click here to Reply or Forward

Kokua-5.0.9 and Kokua-5.1.0 (Alex Ivy) Releases and path forward 7

Kokua-5.0.9 brings Kokua to SL 5.0.7 and 5.0.8 plus a few cherry picked fix changes from 5.0.9 repositories.
Kokua-5.1.0 includes all from Kokua-5.0.9 plus Alex Ivy 5.1.0 through changesset https://bitbucket.org/lindenlab/viewer64/commits/7608919689971da624a2b208616dffb415fd04c1

Included are RLV and NORLV installers. NORLV is an internal work product for merging changes from SL. Users with no interest in RLV may prefer NORLV.

Included are 32 bit installers. Unless there are comments or feedback making a convincing argument; this will be the last publication of 32 bit installers.

Past practice has been to publish Test versions of installers and once enough test time elapsed to move to release versions. Going forward weekly builds will be release versions. Test builds will only be published for a specific test reason.

Kokua-5.1.0 does not use the SLLauncher as it is bypassed for now, but can be made active again once LL has it working.

Refer to Downloads wiki for links to each installer type.

Just as these builds were complete Marine Kelley and LL both pushed updates. These will be included as weekly updates. The best way to be informed about updated installers is to enable notifications from the Kokua viewer project page on SourceForge.

Help wanted: Someone to take over this project.

OpenSim (OS) versions of Kokua and path forward 6

As explained in my Jul 25, 2017 post I planned to reduce my involvement with Kokua starting in October. After today I will no longer be supporting the KokuaOS viewers.

Current test viewers are available on SourceForge:













Source code:

If someone wants to take over I can assist with development / build systems setup.

Thank you to all that have assisted with KokuaOS.

Alex Ivy Releases Updated installers and path forward 5

LindenLab published a fix for Advanced Lighting Model and materials (macOS) last Friday. That fix caused issues for the Windows build which LL fixed earlier today.

New installers for macOS and windows are available from the Kokua viewer file download on SourceForge.





Alex Ivy Releases Updated macOS installers and Path forward 4

The problem with Advanced Lighting Model not being active is an accepted jira at BUG-41395.

The problem of leaving an extra app icon on the dock is fixed temporarily. The problem was the SL_Launcher running at viewer start and exiting to the viewer without removing the icon.

We have taken the front end code for SL_Launcher and removed it. It is just 2 lines of code that can be put back after LL makes the launcher behave better and TPV’s have the ability to complete automated viewer version updates.

Here are some updated installers:

Kokua with RLV; https://sourceforge.net/projects/kokua.team-purple.p/files/Kokua-SL/Macintosh64bit/Kokua_Test_RLV_5_1_0_42219_x86_64.dmg/download

Kokua without RLV; https://sourceforge.net/projects/kokua.team-purple.p/files/Kokua-SL/Macintosh64bit/Kokua_Test_NORLV_5_1_0_42218_x86_64.dmg/download

Hope it goes well.


Alex Ivy Releases and Path forward 3

Status Update

There are updated test viewers available on the SourceForge Kokua project site.

For those unfamiliar, LindenLab has Project Alex Ivy in progress. Alex Ivy updated Windows and MacIntosh SecondLife viewers to 64 bit and for Windows kept a 32 bit viewer.

SecondLife Alex Ivy has progressed from white-board to Project Viewer and now is a Release Candiate viewer.

Additional details about this viewer can be found in the Alex Ivy Release Notes at:

Kokua developed and provided a Linux 64 bit viewer, but never developed Windows and Mac 64 bit as we preferred
to wait until LindenLab developed upstream. We now have Windows and Mac 64 bit Alex Ivy viewers available for testing and feedback.
For RLV capable–


For no RLV–


These viewers should contain functionally at par with current SL default viewers. We recommend testers focus on, but not be limited to, notifications and taking and processing snapshots as those areas caused the most problems during the recent merge.

We have also merged all other Kokua viewers to SL Default. Downloads for these can be found on SourceForge at:

Kokua Linux viewers do not yet have the Alex Ivy code base.



Path forward 2

Kokua for the Mac with 64 bit, based on LL Project Alex Ivy, is ready to test. I only tested the ability to login and saw that I was dressed and then teleported to a couple location on aditi (beta grid). Teleports did seem faster.

As with any new viewer we (Kokua Project) suggest a first login to aditi and once satisfied then login to the Main Grid (agni).

Thanks to onefang a Kokua Project Member for providing the better part of a week computer time for these MacOS builds.

SL code is not able to process multiple word channel identification so RLV and NORLV are not in the file name.

The NORLV version is at: https://sourceforge.net/projects/kokua.team-purple.p/files/Kokua-SL/Macintosh64bit/Kokua_Test_5_1_0_42072_x86_64.dmg/download

The RLV version is at: https://sourceforge.net/projects/kokua.team-purple.p/files/Kokua-SL/Macintosh64bit/Kokua_Test_5_1_0_42083_x86_64.dmg/download

General comments such as “It’s Great” or “It Sucks” are welcome as blog comments, however, problems need to be reported on our Ticket system at: https://sourceforge.net/p/team-purple/kokua/tickets

Speaking of Tickets, there are several open tickets that need someone to volunteer to fix.

Path forward

This is a copy of what a sent earlier to the kokua-dev mailing list and the Kokua group on SecondLife.

Hello all,

This coming October I will turn 75 years old. I intend to have minimal (consulting only) involvement with Kokua after that. Hopefully, someone will take over the project or it will fade away.

Between now and then I intend to cut some routine building and updating. The first cut will be the RLV build of Kokua opensim followed by RLV build of Kokua SecondLife then NoRLV build of Kokua Opensim.

That will leave The NoRLV build of Kokua SecondLife version.

I want to thank all who have contributed to Kokua including other third party viewer project developers and those that work for Linden Lab.

I will try to complete the Alex Ivy integration. Kokua Project Alex Ivy Windows versions can be
built and tested now.

Test down loads can be found at
The source code for secondlife resides at:
The source code opensim which is at start state with the last commit 5 months ago resides at: