The following notes are primarily taken from the Server Beta User Group meeting of Thursday, January 14th and the TPV Developer (TPVD) meeting held on Friday, January 15th, 2016. A video of the meeting is included at the end of this report, my thanks as always to North for the video recording and providing it for embedding.
Server Deployments – Recap
There was no deployment to the Main (SLS) channel on Tuesday, January 12th. On Wednesday, January 13th, all three RC channels received the same sever maintenance package comprising:
- Feature Request: llGetObjectDetails() constant OBJECT_TOTAL_INVENTORY_COUNT – when targeting an object, OBJECT_TOTAL_INVENTORY_COUNT will return the total of all inventory types in each link of the linkset. See BUG-10575 for further details
- Feature Request: llGetObjectDetails() constant OBJECT_PRIM_COUNT – provides a means to get a worn attachment’s prim count (rather than just returning 0). See BUG-10646 for further details.
- Simulator crash fixes.
RC Server Deployment Week #3
The RC server deployment scheduled for week #3 (week commencing Monday, January 18th), should include the feature request for llGetObjectDetails ( myKey, [OBJECT_REZZER_KEY] ), which returns the parent_id of any task in the region:
- If the object came from an object rezzer it returns the ID of the parent object
- If it was rezzed by an avatar, it returns the agent ID of the avatar.
It will only return details for those objects rezzed in-world after the code has been implemented. Objects already in-world prior to deployment will be ignored (NULL_KEY is returned).
SL Viewer Updates
[00:30] The Maintenance RC viewer, version 4.0.1.310054, was promoted to de facto release status on Friday, January 15. This view comprises some 38 fixes and improvements, including updates for some regressions introduced into the viewer with the previous release viewer, and some CEF bugs.
The Project Azumarill HTTP updates RC viewer and the Vivox voice updates RC viewer have been merged into a single release candidate, version 4.0.1.309943, release on Thursday, January 14th, 2016. This is expected to be updated in the next week to deal with a further issue, after which it is anticipated it will be promoted relatively soon to the de facto release viewer.
[01:43] The Quick Graphics RC (Avatar Complexity and graphics presets) is still undoing further refinement, particularly in the way that Avatar Complexity is calculated as a result of feedback provided by users testing the current RC version (4.0.1.309320 at the time of writing).
[0213] There is an update to the Oculus Rift project viewer (3.7.18.295296 at the time of writing) in progress, but no ETA on when it will appear.
Project Bento (Avatar Skeleton Extensions)
Main update: Project Bento User Group update 2 with audio
Issues with the Bento project viewer are viewed as a priority by the Lab. However, no time frames are being set for updates as the project is very much still in beta on Aditi.
There will be a “show and tell” event on Aditi on Tuesday, January 19th, where content creators working the new avatar skeleton extensions will be demonstrating their work for an upcoming episode of The Drax Files World Makers, which takes a look behind the scenes at the project.
CEF and 64-bit Official Viewers
[12:00] The switch to CEF has forced the Lab to re-think its position on 64-bit viewers. Essentially, the CEF code comes as a package, and those producing it ceased supporting Mac 32-bit a while ago (so CEF on the Mac viewer from the Lab is actually a release or so behind the version on Windows).
As a result, the Lab has started on a 64-bit viewer build project, which includes both Windows and Mac. It is possible that as a result of this, and once the 64-bit versions of the viewer are ready to go, the Lab may cease in offering a 32-bit Mac version of the viewer (obviously Windows will continue to be offered in both 32-, and 64-bit flavours).
The 64-bit versions of the official viewer will include 64-bit specific contributions from TPV developers, and Oz has also requested that a number of other open-source contributions which have been languishing since submission are folded into the project.
Aditi Log-in Issues and Inventory Syncing
[06:40] There are still issues being experienced by some people when logging-in to Aditi, which see them redirected to a “safe” zone (most frequently ACME H), rather than to their last log-in point. This is still subject to investigation by the Lab.
The new process for inventory syncing (see my report from 2015 week #52 for full details) between Agni and Aditi still has yet to be implemented. In essence, once this comes into effect, a password change will no longer trigger any syncing between your Agni and Aditi inventories. Instead, logging-in to Aditi will flag your account for inventory syncing. This takes place overnight (Pacific time), and cause your Agni inventory to be merged with your Aditi inventory, rather than overwriting it, thus preserving content unique to your Aditi inventory.
In the meantime, if you need your inventories syncing between the two grids, file a support ticket requesting a manual synchronising of inventories.
Second Life Mirrors
[28:22] Back in August 2014, I blogged about some experiments Zi Ree had been carrying out into creating truly reflective surfaces in Second Life, without relying on tricks with Linden water, to create genuine mirrors.
At the time, the work generated a lot of excitement, but also raised concerns related to implementation, performance, etc., much of which can be found on the original feature request, STORM-2055.
The idea has lain largely dormant since then, but a question was asked at the TPVD meeting on whether it might be implemented, prompting this response from Oz:
We don’t believe mirrors are a good idea. We’re not going to do mirrors … There are too many corner-cases it cannot be made to support well enough, and frankly, we think it would cause us more trouble in people complaining [that] they don’t work well, than we get now saying there are no mirrors. Think curved surfaces, think mirrors that reflect each other; there’s just lots of reasons that’s just not that great an idea.
Other Items
Voice updates
[26:58] There are further voice updating in the pipeline for both the viewer and server-side of things, which will be appearing in due course. In the meantime, those who have had voice issues are asked to try the HTTP / Vivox RC viewer, and see if that resolves their issues.
24-hour Day Cycle
[29:34] Currently, Second Life operates on a cycle of 4 hours daylight followed by one hour of night (real-time). A future update will allow region owners to use a full 24-hour day / night cycle if they so wish, together with other updates to the environment capabilities. Of interest here is the implication that region owners may be able to set their own prefer length of day / night, with the 4-hour day, 1-hour night cycle remaining the default unless a region owner opt to change it. So to is the potential for region owner set when “midnight” occurs in real-time (e.g. so that region midnight occurs at, say 16:00 PST or 08:00 PST, etc.).
Firestorm Release
The next Firestorm release, which had been provisionally scheduled for a mid-February release, has run into issues with the CEF merge and bugs (some of which should now be fixed with the Maintenance viewer release), and so is unlikely to appear before March at the earliest.
Inara Pey: Living in a Modemworld 
There are one or two TPVs which have 64-bit versions, but I can’t say I have had good experiences with them. It needs rather more than a compile switch to see any benefit. One gotcha I have seen is a tendency to use all the physical RAM, in a remorseless grabbing of space, and I am not sure the code which stores data in RAM is all that well written. In the 32-bit version, there are some hard limits.
If they get to a good 64-bit version, which can take advantage of multiple cores and threads, and plays nice with other software, I shall be happy to use it. I am not holding my breath.
It may be that the defaults used in Linux are better suited to situations which don’t have that much RAM anyway. But it looks as though people are going to find out what hitting the swapping to hard drive can do to performance.
LikeLike
I beg to differ. 🙂 If it weren’t for 64-bit FS viewer, I would have likely left SL already, as the 1G video memory limit was an absolute necessity for my many materials-enabled scenes. 512MB just isn’t cutting it any more: everything kept blurring because of the lack of texture memory. 64-bit is the way to go!
LikeLike
Consider that your visitors as well, with their mesh avatars, hair, clothes and accessories, are carrying loads of hires textures and materials nowadays. If your scenes aren’t optimized and require so much video memory, you are going to get texture trashing again, and your visitor may lag and crash. I don’t say it’s your case, but the main culprit of texture trashing in SL is creator using too many unnecessary hires textures. More memory gives extra breath, but optimization makes a big difference. When you see something as small as a cup of tea coming with five 1024×1024 textures, when you can use a smaller optimized single one, you can see were problems come.
Further reads that can help to understand this:
http://pennycow.blogspot.it/2013/02/why-second-life-fails.html
http://pennycow.blogspot.it/2013/06/building-better-second-life.html
LikeLike
Optimizations are always a good idea. But you have to keep in mind, that with the advent of materials, the texture requirements potentially tripled overnight (leaving, worst case, 512/3 MB for all your scenes, which just wasn’t enough).
So, this is not about ‘a cup of tea coming with five 1024×1024 textures,’ but about a materials-enabled cup of tea now often coming with 3 textures, whereas before it needed only 1 (sans materials).
LikeLike
‘Mirrors that reflect each other’ should not present a real problem. in fact, the practical solution to this was already seen in the first Portal game, where they set a recursive portal depth of max 4 (for opposing red and blue portals). Nothing would really prevent LL from imposing similar limits on mirrors. Besides, the FS viewer already supports (experimental) floor surface reflections.
LikeLike
Yes, Zi did the ground work, but it was rudimentary in some respects – such as not working if ALM is enabled – and thus required further work, and Zi herself was the first to state.
However, that said, technical issues don’t seem to me to be the central thrust of Oz’s comments. Rather, his concern appears to be that by limiting the functionality of mirrors in one or more ways, the Lab could be making a rod for its own back. That is: give rise to increased levels of complaints and negativity over a feature which to the lay user, only seems to work in one or two ways, rather than rather than being a “good” feature, and working in every situation in which they want to use it (something which additionally might result in it simply not being used, despite the efforts of the Lab and third-party contributors to offer it).
LikeLike