Kokua: Admin changes and the 6.2.4 release

The Kokua team released Kokua 6.2.4 on Friday, August 16th, 2019, and with it come some changes to general administration of the viewer’s website and management tools.

In terms of the latter, and for ease on management going forward, a number of changes are in the works including:

  • The use of the Atlassian Confluence platform to provide:
    • A blog capability.
    • Release notes support.
    • A master download pages.
    • RSS feeds.
  • The use of Atlassian Jira (as used by Linden Lab and the likes of Firestorm) for bug reporting and tracking.

The switch-over is still a work-in-progress, so the existing blog, wiki and bug tracker remain in operation for the time being, however, relevant links for the new environment are given as:

While the switch-over is in progress, users are advised against linking to individual sub-pages within these sections, as pages may change as things are bedded-in. For this purposes of this blog, the new Kokua home page is referenced in the sidebar links (right, under Maintained Viewers) and within my Current Viewers Release Page and the weekly release summaries drawn from that.

Kokua 6.2.4

Kokua 6.2.4 brings the viewer to parity with the most recently Linden Lab viewer release (version 6.2.4.529638, formerly the Love Me Render RC viewer dated August 5th, promoted August 12th). In addition, it updates the RLV version to Marine Kelley’s RLV 2.9.26.2.

As has been customary with Kokua releases of late, the viewer is provided in three versions for each of the supported operating systems (Windows, Mac OS X and Linux, all 64-bit):

  • Non-RLV – version 6.2.4.45881.
  • “Standard” RLV (can be enabled and disabled via a viewer restart) – version 6.2.4.45882.
  • “Full Time” RLV (RLV is active all the time) – also version 6.2.4.45882.

In addition to these updates, Kokua 6.2.4 includes a number of third-party additions, most notably from Firestorm, as noted in the sections below, and with due credit to the originators of the code updates.

Settings Backup

Sometimes when installing a new version of a viewer, there can be a recommendation to perform a “clean install” – removing all cached and settings files. This can make any viewer installation labour-intensive, as settings all need to be restored after the installation is complete.

The Settings Backup (Preferences > Backup) eases some of the pain by allowing users to back-up many of their global and account settings to a local hard drive. Once done, the back-up can then be restored to an updated version of Kokua (e.g. if a clean install has been required, or if some settings have become corrupted). Settings can also be backed-up at any time as changes are made.

The Kokua Settings Back-up option, courtesy of Firestorm

Settings can be backed-up to any location on a local drive, and users can select those settings they wish to back-up by unchecking / checking the available options. It is also possible to save settings on a per account basis. So if you have several accounts, each with different settings, you can back-up each of them separately – just make sure each back-up has a unique location.

Restoring previously backed-up files requires the viewer is restarted after the restore – and again, this is conveniently taken care of by the viewer allowing you to quickly log-out following a successful restore – although you’ll have to manually re-start the viewer once you’ve been logged out.

Sounds Output Device Selection

Preferences >Sound and Media includes a new drop-down allowing users to select their preferred output device for playing in-world sounds.

Sound output device selection, courtesy of Firestorm

When using it, note that:

  • Selecting Default will always select the first output device in the list.
  • If Default is selected but the previous device is no longer available, the viewer will automatically switch to the next available “default” device as defined by your operating system.
  • Manually selecting an output device from the drop-down  prevents the viewer from automatically switching to another device if the selected device is no longer available. Instead, the field will show “Unavailable Device” until such time as the nominated device is again available, or the drop-down is changed to Default or an alternate is manually selected.

Updated Debug Floater

Finally from Firestorm, Kokua 6.2.4 includes an improved debug settings floater with search and sanity checking of key values.

The improved Debug floater, courtesy of Firestorm

Other Updates of Note

Finally there are a number of fixes/improvements on the Kokua code base itself, notably fixing the pie menus so that the Hover Height command appears (i.e. was there but a mistake in the file concerned prevented it being shown). For details, please refer to the Kokua 6.2.4 release notes.

Feedback

Kokua 6.2.4 continues to maintain parity with the official viewer whilst also importing some additional updates from Firestorm that Kokua users will doubtless find useful and which are likely to help enhance Kokua as the go-to viewer for those who have used Firestorm , but who are looking for an alternative that offers reasonable familiarity.

Additional Links

Sansar Product Meetings week #33: feedback and Q & A

Who said you can’t dance in Sansar? The June Organic Light Show by Mario2 Helstein

The following notes were taken from my audio recording of the August 15th (week #33) Sansar Product Meeting, which formed a general feedback and Q&A session. Not all topics are covered, notably those that were as case of requests being noted rather than being given a detailed reply, or passed on answering as the subject specialists from the Lab were not in attendance for the meeting.

Note on meeting videos: the Sansar team have resumed posting videos of meetings to You Tube, which allows me to once again embed their recordings in these updates (although at the time of writing, the video for this particular meeting had yet to be uploaded –  I’ll update when the video is available). This means the notes for those meetings I was able to attend between May and August 2019 have now been updated with their video recordings.

Quest Update 3 – August 15th

A third Quest release update was made on August 15th, 2019, which included both quest and profile improvements.

Quest Updates

  • Further Quest panel tweaks – notable a progress bar that records the number of objectives within a quest that have been achieved.
  • Scripts should no longer crash when the Quest Objective Controller script receives an Objective Complete event message that is missing agent data.
  • Users should no longer be blocked on completing locked objectives from quests offered by a quest character.

Profile Updates

Profiles receive an overhaul with this update. The panel has been enlarged and includes two panels:

  • Profile: includes buttons to send a direct message to the user; gift them Sansar Dollars; send a friend request to them (if they are not a friend) or remove them as a friend (button toggles automatically depending on their relationship to you); report and block a user.
  • Creations: lists all of the user’s creations (if they have any). This includes Sansar Store items, published experiences and snapshot uploaded to their Sansar web profile. Clicking on any of these options will display the relevant part of the web profile or take you to the user’s Store page.
  • Bio: a field (editable by the user owning the profile) for writing biographical notes (via Socialise > Edit My Profile then clicking on the bio field in the profile panel). If a web profile has been written by a user, it will be displayed here and any updates made in this panel will also be appear in the web profile).

In addition, the profile picture for the user contains:

  • A mute / unmute button for voice chat.
  • What appears to be an initial pass at an achievement indicator surrounding the profile image.
The new Profile panel for Sansar users – click for full size, if required

Finally, profiles for other users can now be accessed by clicking on the user’s profile image in any the chat or the quest info panels.

Avatar 2.0 – Reminder

Pre-release Creator Programme now in progress.

  • Designed to allow creators who create avatars, avatar wearables, accessories, etc to have their content tested by the Lab ahead of the avatar support being added to the client.
    • The Lab may only initially be reviewing around 2-4 items per creator. Additional items submitted will only be reviewed once all creators making submissions have been seen.
    • Creators are obviously free to test their items in their own 3D editor of choice, if preferred, and wait until the launch of Avatar 2.0 to make any necessary adjustments.
  • The programme will be discontinued once Avatar 2.0 has been released, when creators will be able to test their items directly in the client.

Official Documentation

Avatar 2.0 and Marvelous Designer™ Clothing

  • A set of tools for Marvelous Designer™ will be released with Avatar 2.0.
  • These will allow creators and users to scale, translate and rotate their MD clothing assets to better fit avatar (so a user can take a human jacket and scale it to fit an orc avatar using the Avatar 2.0 skeleton, for example).

XP System

There has been a lot of discussion about the upcoming Experience Points (XP) system via Discord. The feedback tends to reflect what is already under discussion / in development within the Sansar team. As such, while open to making changes based on suggestions and ideas from the community, what is already being developed addresses most of the ideas thus far put forward.

Direct Teleport Links

A frequent request is to have the ability to direct users to a specific point within an experience when teleporting to it, rather than them being directed to a spawn point. With quests and linking experiences, this has taken on greater import (e.g. if you enter a building in a quest by being teleported to another experience representing the building interior, when leaving, you should be returned to the “door” into the building in the originating experience – not to the spawn point).

LL has asked for creators to give specific use-cases via Discord on how this might work. Should it be a spawn point that has to be specifically requested (e.g. via a script)? Is it something that could be specified via an X, Y, Z coordinates heading? Is it something that should be restricted at the experience level so only certain scripted objects can trigger the teleport (imagine a key for a door that the user must obtain)?

Current Development Focus

Mention is often made of a roadmap for Sansar development. As a part of this, some of the high-level items the Sansar team is looking at include:

  • Further updates to the quest system – tools, UI, adding in storylines, NPCs, building new quests, adding the rewards system, etc.
  • The upcoming Avatar 2.0 release and the build-out of that capability.
  • The upcoming XP system.
  • Extending the current LOD system (focused on avatars) to include textures as well to help further reduce the load on client graphics memory.  Eventually, the system will extend outward to include scene content as well.

General Q&A

  • Persistence: the Sansar devs have been discussing the various requests for persistence (e.g. script persistence) that have been received (use cases still welcome) and determining which use cases should work from those which may not work, and are in the midst of determining what capabilities might be provided in a first pass at persistence.
    • It’s noted that any work that may come out of this may not initially address all use cases, but the aim is to define what can be rolled out in a reasonable time frame that addresses as many achievable use cases as possible. This will then be extended as necessary.
  • Valve Index headset support: LL have a couple of the headsets on order and do want to provide support, but time frames for doing so still TBD.
  • Store related:
    • Can a bulk update button be provided for things like discounted item prices to make it easier to update multiple items during sale events organised by Sansar? Currently not on the roadmap, but under consideration as part of the overall drive to provide more Store features and abilities.
    • Is the ability to bundle items of the same type (e.g. multiple colour versions of the same shirt or dress) on the Store coming? Not currently on the roadmap, but is something the Lab wants to provide.
  • Avatar and avatar accessory related:
      • How soon will the ability to deform the full Avatar 2.0 skeleton using sliders be behind the initial release (facial deformation will be possible with the first release)? Potentially a while because a) the deformation system is seen as needing to be hooked into the licensing system; b) skin texturing support (including custom uploads and layering) is seen as being a higher priority, as it has no other dependences.
      • The hope is to have body deformation available within a year – possibly a lot sooner.
      • Lack of fully body deformation is already being seen by some creators as something that could result in users reacting negatively to avatar 2.0 simply because it will be seen to be limited in much the same way as the current avatar.
    • Can the tri count for hair / headgear be increased to allow for more complex hairstyle and hair with hats, etc? Increasing tri count limits for hair and other assets in being considered internally, but no specific details or time frame on what might happen currently available.
    • Will additional default options for things like hair be provided by LL? Yes.
      • In particular, the deployment of Avatar 2.0 will see all hairstyles and rigged accessories supplied by Linden Lab replaced with new items.
      • Some inventory / look Book options will be changing as well – such as how skin selection works, in part in readiness for supporting custom skin uploads from creators.
    • Will things like flexies be supported for hair, etc? No. However, in the future, it is hoped that accessories like hair can use their own skeletons to provide them with flexibility via animations.
  • Will it be possible to host events in experiences other than your own – e.g. in Sansar Studio experiences? That is a longer-term goal. For experiences by other creators, this may involve a mechanism by which the experience can be purchased or rented or borrowed.
    • There are updates that are required to the events system before this can be deployed.
    • As a short-term measure, if someone wants to host an event in a Sansar Studios experience / Lab-created experience, they should contact either Galileo or Lacie Linden to discuss their ideas / requirements.
    • If there are specific venues types that would be useful, suggestions should be made via Discord, and attempts will be made to furnish more experience templates that users can obtain and host events within.
    • This also feeds into a wider discussion on monetising quests and events, something the Lab is also discussing internally.
  • Can individual volume controls for users be better surfaced in the client? This is something the Sansar team want to look into.
  • Can UI scaling be added to the client to address issues of elements being too small to read on 4K monitors? Again, is something the Lab plans to address.
  • As a lot of Sansar seems to depend on building-out the licensing system, why can’t this just be a focus in itself? Because that’s not a practical way to work: projects such as Avatar 2.0 (and others) have their own unique hooks that have to be added into the licensing system, and these can really only be done as a part of their own projects, rather than some form of “licensing project”.