Archive for April, 2018

Kokua Releases 5.1.3.43129 RLV and 5.1.3.43130 NORLV

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

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/5.1.3.513644 ) and in the case of the RLV version also with RLV 2.9.23.0.

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