The following notes are taken from the TPV Developer meeting held on Friday, February 15th, 2019. A video of the meeting is embedded below, my thanks as always to North for recording and providing it. Time stamps are provided to the major topics of discussion, which will open the video in a new tab for ease of reference.
The Bakes On Mesh project viewer updated to version 220.127.116.114367 on Friday, February 15th. The rest of the current viewer pipelines remain as per earlier in the week:
- Current Release version 18.104.22.1682263, dated December 5, promoted December 13. Formerly the Spotykach Maintenance RC viewer – No Change.
- Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
- BugSplat RC viewer, version 22.214.171.1244348, February 13. This viewer is functionally identical to the current release viewer, but uses BugSplat for crash reporting, rather than the Lab’s own Breakpad based crash reporting tools.
- Estate Access Management (EAM) RC viewer, version 126.96.36.1993351, January 23.
- Love Me Render RC viewer, version 188.8.131.523177, January 16.
- Project viewers:
- Linux Spur viewer, version 184.108.40.2069906, dated November 17, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
- Obsolete platform viewer, version 220.127.116.110847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7. This viewer will remain available for as long as reasonable, but will not be updated with new features or bug fixes.
It is hoped that one of the current RC viewers will gain promotion to de facto release status, although there is one further issue in the Love Me Render viewer to be seen to. Also, the EEP viewer could see promotion to RC status in the very near future.
Viewer-Related Web Changes
[16:35-18:20] The Lab will be introducing a new system for release notes. In short:
- It will use a new website for publishing release notes, and not the currently SL wiki pages.
- Those release notes currently on the wiki will remain there for archival purposes.
- Once visible, any issues should be reported via Jira.
User Profiles – Viewer and Web
[18:23-24:35] The current user profiles seen in the viewer, on the web, via various feeds, etc., are all currently powered by a single application. There is an upcoming system upgrade in the pipeline that might result in some breakage within this app. The Lab will therefore be moving viewer profiles back to using floater-style user profiles, as is seen with the like of Firestorm.
It is not currently clear what will happen to the current web profiles and feeds. It is hoped these will be able to continue to work, but the Lab is also contemplating a “worst-case” scenario that they may be retained for historical purposes (so snapshots uploaded to feeds are preserved and remain viewable, for example), but will no longer work as they do now – but this is not what the Lab is hoping to achieve.
This will not be an immediate change, as there may be issues along the way the Lab need to work through.
[5:27-6:31] The weekend of February 9th /10th saw some significant issues with Second Life, and extended periods of unscheduled maintenance. The problems that contributed to the issues are still being investigated, ut the Lab is close to understanding exactly what went wrong, and how to respond should a similar issue occur.
As an aside, the weekend issues result in inventory problem that caused some uses to see the “cannot remove protected categories” error. If you are still seeing this message, and have not already done so, file a support ticket.
- [1:20-1:46] Visual Studio 2017 Build Process Update: work on this is progressing well, but will like pause in the coming week, due to the project lead being on vacation.
- [2:09-2:40] EPP: As per my SUG meeting and CCUG meeting notes, the simulator EEP code is now on BlueSteel and LeTigre. This will not get a further promotion in week #8, as there is a fix for another issue the Lab wants to see get wider exposure on the grid.
- [6:50-10:18] Avatar attachment issues: there have been reports of attachments belonging to other avatars randomly appearing to be attached to your screen when logging-in to / teleporting to busy regions. The underlying problem appears to be a race condition in which the object data for the attachment is received by the viewer ahead of the avatar / attachment point data (and should correct when the latter is received).
- In the meeting, the issue is specifically reported as occurring with “jellydolled” avatars, but this appears to be purely coincidental.
- [10:39-11:28] New EEP Assets causing log-in freezes: a default set of new EEP object types were added to the asset library recently for use with the EEP viewer. However, if pulled into a non-EEP viewer, they can cause log-in freezes, as the viewer repeatedly generates an error message for each individual asset it encounters in loading inventory, rather than simply throwing a single message of the asset type, and simply ignoring the rest of the individual assets. There is a fix for this, but it has yet to reach the current release viewer code base.
- [11:37-14:10] Landmark assets getting fetched twice at log-in: this appears to be a new(ish) issue. Although landmark assets only appear once in inventory, the viewer appears to be fetching them twice; once around mid-way through the log-in process, and then again at the end. The cause is unknown at present, but it has been noted by the Lab.
- An intermediate workaround if your logins are being delayed unduly is to delete you landmarks.
- This can might cause the degraded performance message (see below).
- [13:07-15:33] Degraded performance message: “Linden Lab has detected degraded performance on your connection”, with a suggestion you relog, is a message users might receive when the viewer is failing to acknowledge enough of the UDP messages exchanged with the simulator.
- This can be the result of your router being overloaded by whatever else it might be doing, so responses from the viewer fail to reach the simulator.
- It might also be the result of issues being experienced in the simulator.
- While a lot of asset-related UDP messaging has been removed from simulator / viewer communications, there is still much that does require / well suited to UDP, particularly where information is changing, and the viewer needs the latest update, not a re-send of a now outdated updated (e.g. object updates), as would be the case using something like TCP, which attempts to re-send the data it has, rather than any new data.
- See also BUG-225544.
[30:21-31:37] In-Viewer Animation Creation: This is a project based on contributions from NiranV Dean (Black Dragon viewer). Vir and Nat Linden had been working on elements of the project, but are both also busy with other viewer-related projects (e.g. Animesh follow-on investigations for Vir, working on the VS 2017 update for Nat). Resources are also being swallowed by the under-the-hood work required for the transition to the cloud, which is also impacting assorted projects.
- [32:18-32:35] Texture resampling & mipmap availability: this has been the subject of extensive blog and forum discussions – see my week #7 CCUG summary) One outcome of this is Beq Janus has filed a feature request so users can define more than a single resolution when uploading a texture (see the dummy uploader floater design, right). The hope is this might encourage more people to make better choices about texture resolution use (very high resolutions aren’t always required, depending on how / where they are used, but can result in unnecessary texture memory use if unwisely employed).
- [32:39-32:50] Asset UDP messaging deprecation: Aura Linden is now engaged in this work. This will include removal of the GrantUserRights message (found in LL PropertiesProcessor::sendfriendrights() ), which has been completely disconnected in the viewer since 2.0 days.TPVs are asked to check their code to confirm removal of the message path will not cause them problems.
- [34:37-35:19] Does SL use multi-threading: yes, in parts of the viewer and the simulator code, but not as extensively as the Lab would like.