Why is this release numbered 6.4.16? Now there’s a question…
In terms of the underlying LL codebase this is effectively another 6.4.13 release (ie building on the Jellydoll release).
However, to understand why this is a 6.4.16 we need to review recent events. The first point to make is that we have a policy that we usually ship with the release number that matches the underlying LL codebase (unlike some TPVs which tend to ship with the version number after the one they’re based on). We use this principle to make releases easy to understand - LL’s 6.4.13 improved Jellydolls, so Kokua’s 6.4.13 does the same. If we were to use the next number each time there would be the situation where LL release a 6.4.14 with some new features but those features would not appear in Kokua 6.4.14 and only appear in Kokua 6.4.15 which gets confusing for all concerned. More confusingly still, this Kokua 6.4.15 would be lacking whatever gets released as LL’s 6.4.15. And so on…
Having established that principle let’s go over recent events.
LL released a 6.4.14 by promoting the Simplified Cache RC (Release Candidate) viewer to released status
Very soon after it became clear that this release had some serious bugs and LL reverted to 6.4.13 as the official release
This left LL with a problem - whether to power on through the problem by fixing Simplified Cache and reissuing it or to return it to development/testing and go with a different RC viewer as the next release
However, this causes a problem for the source code of the viewer. At the time of 6.4.14’s release its code became the basis on which all future development would occur, meaning that while the official release download could simply be reverted more complex surgery was needed on the source code to achieve the same effect
The situation was complicated by Third Party Viewers (Kokua included) having taken the official release as the cue to merge that code into their own codebase, thus for a while we were expecting to release a Kokua 6.4.14
LL opted to revert the changes introduced by 6.4.14 - this change consumed a version number thus 6.4.15 is a non-entity corresponding to reverting 6.4.14.
LL’s automated processes resulted in an additional increment of the version number with the result that it currently sits at 6.4.16 and the next released viewer (which is looking likely to be the Keymappings RC) will be a 6.4.17.
So… with LL expected to release a 6.4.17 next, we are releasing this as 6.4.16
(A note for the experts: I have simplified this explanation a bit. LL’s policy is to increment the viewer version number in the source code immediately after any release is done thus while 6.4.14 was on release, the file was set at 6.4.15. Similarly, the file is now set at 6.4.17 so that potential next releases embody that version number. When we merge from LL’s sources after a release occurs we take care to only merge up as far as the commit before the version number gets incremented to begin the next development cycle)
Although there is no new LL code featured in this release there are a number of other new items in this release.
The ability to toggle the crouching position has been ported over from Firestorm. The option for this is on Preferences > Move which has now been split into three tabs due to overcrowding
The ability to mark any folder as a System Folder (so promoting it to the first group of folders and protecting it from deletion) has been ported from Catznip
The ability to see a place or avatar profile from the minimap menu has been ported from Firestorm
In addition, the RLV and FTRLV versions incorporate RLV 184.108.40.206. Release notes for 2.9.30 are here with original documentation for @setsphere here . Note that while the examples in the documentation will work as expected, there are some subtle differences in the syntax to use as described in the 2.9.30 Release Notes.
There are some other RLV changes beyond those listed in the RLV 220.127.116.11 release notes
In the status floater it would try to resolve the uuid for camtextures to a name and fail, showing ‘waiting’. Instead it will simply show the uuid.
A new debug option RestrainedLoveSelectionOutlines allows switching between the earlier behaviour of no selection outlines/no change to vision spheres when an object is selected and the later behaviour of showing a selection outline whilst forcing the nearest vision sphere to opaque. The earlier behaviour is the default.
The RLV Status floater’s last tab has been updated to show @setsphere information whilst it is in effect
All the above are also in Marine’s RLV release. Finally, a Kokua-only bug has been fixed which allowed some IMs to be sent or received when they should have been blocked by RLV.
[KKA-817] - 6.4.14 bug fixing [Reverted - not present in this version]
[KKA-823] - RLV status - shouldn't try to look up uuid for camtextures/setcam_textures