The following notes are taken from the TPV Developer meeting held on Friday, December 15th 2017. The video of that meeting is embedded at the end of this update, my thanks as always to North for recording and providing it.
[2:35] The Alex Ivy 64-bit RC viewer has one more bug the Lab would like to resolve, this one with the updater within the viewer. The hope is a fix for the issue will be in a further update to the viewer at the start of week #51, commencing Monday, December 18th. If so, the viewer might be promoted to de facto release status before the holiday break.
[6:46] Once the Alex Ivy viewer is promoted to release status, the Lab will move to block versions of their viewer older than the 5.0.6 viewer (the HTTP updates from June 2017).
[4:00] The Voice RC viewer updated to version 22.214.171.1240039 on December 12th. This is doing “very well” and is currently being held from promotion due to the wish to promote the Alex Ivy viewer. As a result, the Lab might do a further RC update for it, with a new update from Vivox.
[5:19] A new Maintenance viewer, version 126.96.36.1990035, appeared on December 13th. It features a range of fixes, and is code-named Nalewka, in keeping with the Lab’s new habit of naming Maintenance viewers after alcoholic beverages. Nalewka is, according to Wikipedia, a rather interesting beverage mixing alcohol (vodka or neutral spirits) and fruits, herbs, spices, sugar / molasses and which has a liquer-like taste.
[5:43] The anticipated 360-snapshot viewer update has been held while it is integrated with Second Life Place Pages. This will allow 360 images to be uploaded to Place Pages and used in hero images, etc. It is anticipated that these updates will now appear early in the New Year and the viewer should move quickly to RC status thereafter.
[4:43] TPVs attempting to use the viewer updater have encountered issues, often resulting in them disabling it. Oz Linden acknowledges it isn’t easy for TPVs to update it, but has offered to work with them to fix issues once the Alex Ivy viewer (which uses a new version of the updater) reaches release status, coupled with a code refactoring to make updating it easier in the future.
Linux and the Viewer
[20:51-24:28] As per my previous TPV meeting notes, once the Alex Ivy 64-bit viewer (Windows and Mac) goes to release status, the Lab will look to TPV / open-source developers to help move the Linux viewer build to a Debian package without the additional libraries. this will allow TPVs to add the dependencies they require for their flavour of Linux build. If help is given and the project is successful, the Lab will then maintain the Linux build, with the caveat that it will only be subject to cursory QA, and will continue to look to the Linux community for fixes.
A repository for code submissions will be made available, together with a blog post / open-source community notification on the specifics, after the 64-bit viewer has been promoted to release status. Those wishing to support the work will need to sign a contribution agreement with the Lab.
Texture Decoding and Texture Memory Limits
[28:23-29:52] The Lab is making improvements to texture handling (e.g. using raw texture data rather than encoded). Some of this work is in the current rendering project viewer; there is another non-public viewer which uses a new structure for the rendering cache – although this hasn’t been overly successful in testing thus far. Oz is anticipating his team spending more time on rendering in early 2018.
Environment Enhancement Project (EEP)
A set of environmental enhancements, including the ability to define the environment (sky, sun, moon, clouds, water settings) at the parcel level; a new environment asset type that can be stored in inventory and traded through the Marketplace / exchanged with others; scripted, experience-based environment functions, an extended day cycle and extended environmental parameters. This work involves both a viewer updates (with a project viewer coming soon) and server-side updates.
[10:01-11:34] “Rider’s been on a power trip since starting this project!” Grumpity joked at the meeting, “Moving these celestial bodies around the sky!” – which Rider admitted was fun.
Progress continues, and it is anticipated that test regions on Aditi and a project viewer will be available “soon after” the new year, although these may not initially support using environment settings and inventory assets.
Server-side Reset Skeleton
[30:10-35:25] Bento introduced a reset skeleton option for details with avatar deformations. However, it is viewer-side only – therefore, if someone swaps between skeletons / avatars + attachments and is displayed deformed (e.g. BUG11310) or with attachments wrongly place (or a combination), they, and everyone viewing them has to individually perform a reset skeleton on their avatar to correct how they appear.
A preferred means of handling this might be for a local reset to be sent update the appearance system to ensure everyone gets updated (so if I’m deformed, I can use reset skeleton, and everyone around me gets the update as well, rather than having to also use the reset skeleton option). Oz has requested clear, concise feature request on the idea. Grumpity has indicated she’ll follow-up on the specifics of BUG-11310, which the Lab thought to be resolved through and internal JIRA.
Simulator Resources and Simulator Crashes / Performance Degradation
[43:53-50:20] Discussion on simulator resource use / loading balancing. This proceeds from the false assumption that a region / simulator can be crashed “just” by overloading it via a resource / physics hungry script. While there may still be exploits where this might be the case, the Lab long ago imposed absolute limits on script and physics time per frame. What more usually happens is that excessive script / physics loading on a region as whole as a whole can degrade performance as some script / physics executions are skipped within a frame (so scripted objects are slow in responding / may not respond as anticipated, for example); although it is acknowledged that specific items – intentionally or through bad scripting – can have an undue impact on performance. Anyone encountering specific objects, which can individually adversely impact region / simulator resources / performance is asked to file a JIRA with details of the object in question, so that the Lab can obtain a copy and poke at it.
- [13:24] Estate access / ban lists: (Estate/Region floater) – work has stalled on this.
- [14:21] A question was raised on the ability to teleport others home from, or out of, your own parcel, a capability that had been available in the older v1 (and v2?) viewers. Having an ability to remove people at parcel level is something the Lab will likely look at as they continue to work on the land tools.
- [16:59] the updates to the estate tools will include a log of ban actions taken – who banned whom and when – which will be visible to all Estate Managers (not general group / land users).
- [35:35-36:20] Semi-automatic viewer tests: Kitty Barnett (Catznip) have a number of semi-automated viewer tests (e.g. checking to see if all UI elements / floaters work in different languages). The Lab have found that as the viewer is updated / changed so often, such tests rarely maintain their value over a period of time. However, Oz is willing to learn more about at Kitty’s framework if it avoids such issues.
- [36:39-37:53] Viewer support for local meshes: this has been a frequent request, particularly with content creators. It is also something the Lab and Firestorm have looked into. However, supporting multiple mesh formats, dealing with LOD compositing, etc., makes it complex and difficult to implement within the viewer. However, if the Lab can find a way for the viewer to do this, they would consider implementing it.
- [50:43-55:07] Phishing/ URL link spoofing: a discussion on the use of URL link spoofing – which has affected Second Life and is a general issue on the web as a whole. Short version: always check URLs before clicking whatever you’re doing, and in terms of SL: always treat links receiving (e.g. via dialogue boxes, via unexpected / unknown IM, etc.) with caution, and while it does not eliminate risks, configure your viewer to use an external web browser to open external links. Obviously, and like any other company, the Lab cannot – and will not – every guarantee the safety of accessing URLs which are outside of its control.
- Lab No Change window: runs from Thursday, December 21st 2017 through until Tuesday, January 2nd, 2018.
- Next TPV Developer meeting: Friday, January 12th, 2018.
- Firestorm release: the next Firestorm release now looks set to go to beta in the week commencing Monday, December 18th, with a release to be made early in the New Year.