2022 CCUG and TPVD meetings week #5 summary

The following notes were taken from:

• My audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, February 3rd 2022 at 13:00 SLT. These meetings are chaired by Vir Linden, and meeting dates can be obtained from the SL Public Calendar.
• My audio recording and the Video recording by Pantera (embedded at the end of this piece) from the Third-Party Viewer Developer (TPVD) meeting on Friday, February 4th, 2022.

So this document forms a summary of the key topics discussed, and in the case of the TPVD meeting, timestamps to the relevant point of the video are included.

Available Viewers

[Video: 0:19-0:52 + notes from CCUG]

This list reflects the currently available official Second Life viewers.

• Release viewer: version version 6.5.2.567427 – Mac Voice hotfix viewer, January 13 – 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).
  • Maintenance RC viewer, version 6.5.3.567451, issued on January 20th, combining the Jenever and Koaliang Maintenance viewers.
  • The Tracy Integration RC viewer version 6.4.23.563771 (dated Friday, November 5) issued Tuesday, November 9.
• Project viewers:
  • Performance Improvements project viewer version 6.6.0.567604, dated January 24.
  • Mesh Optimizer project viewer, version 6.5.2.566858, dated January 5, issued after January 10.
  • Performance Floater project viewer, version 6.4.23.562625, issued September 2.
  • Legacy Profiles viewer, version 6.4.11.550519, dated October 26, 2020.
  • Copy / Paste viewer, version 6.3.5.533365, dated December 9, 2019.

General Viewer Notes

• The Maintenance J&K RC viewer is likely the next viewer to gain promotion as the de facto release viewer.
• The Performance Improvements viewer is close to being ready for promotion to RC status, and is just pending some remaining bug fixes.
  • This viewer did have changes to alpha sorting for rigged attachment, but following reports of content breakage as a result of this change, which was more a technical change than a performance enhancement, it has now been reverted to expected alpha sorting behaviour to avoid the breakage issue. Instead, possible alternative approaches will be looked at in the future.
  • A future version of this viewer is to include a new UI element intended to help make adjustments to some of the high-impact graphics settings to help improve frame rates,
• LL is also completing work to switch the viewer over to using Python 3.

Viewer Multi-Factor Authentication Support – TPVD

[Video: 0:53-23:00]

Background

• In September 2021, Linden Lab introduced multi-factor authentication (MFA) utilising either a QA code + mobile device or a key number, for those pages of the SL website that provide access to users’ account information (see: Second Life Multi-Factor Authentication: the what and how, September 2021).
• When introduced, it was indicated that over time, the use of MFA would be expanded and improved, and would eventually include the viewer as well.
• Brad Linden is now working on implementing MFA for the viewer.

What This Means

• The work has reached a point where LL is close to having a viewer with MFA support ready for initial testing (as defined by  see: SL Wiki: Login MFA), together with updates to the back-end log-in service to support it.
• Viewer MFA will be based on users opting in to the capability via the secondlife.com dashboard, as described in the blog posted linked to above.
• It is  recognised that TPVs will need time to integrate the necessary viewer-side code into their offerings, therefore:
  • There will be a grace period between the initial introduction of the code in the official viewer and a time when all viewers / clients access Second Life will be required to support MFA to allow users who have opted-in to MFA to continue logging-in to SL.
  • During this grace period, all users on a TPV will be able to access Second Life, regardless of whether or not they have opted into MFA.
  • After the grace period has expired, all TPVs will be expected to support MFA, and those users on them who have opted in to MFA will be required to authenticate themselves when using the viewer to log-in to Second Life (with the use 30-day period of valid authentication, as per secondlife.com MFA).
  • During the grace period, users on TPVs that switch to support MFA will likewise need to start authenticating themselves when logging-in to SL.
• Again, this will only affect users who have opted into MFA (unless LL at some point decides all user must use MFA to access SL).
• MFA on the viewer will be a blanket action – there will be no additional MFA authentication for actions such as buying Linden Dollars through the viewer.
• Using MFA when logging-in to the viewer will not automatically also authenticate you on secondlife.com or vice-versa.

There was a broader discussion on providing alternative mechanisms by which users can opt-in and use MFA – such as e-mail – rather than relating on a mobile device and authenticator software. Such decisions fall outside the realm of the viewer development team, and so could not be answered directly (however LL have stated  additional / alternate methods of authentication will be added to the system at some point in the future).

In Brief

Content Creation Meeting

• BUG-231731 “Script text quality and performance” prompted questions on how it might be implemented given it has been accepted. Vir pointed out that “Accepted” does not necessarily mean it a Feature Request will be implemented forthwith, and as such, it will be raised for discussion once it has reached a point where LL is considering working on it.
• BUG-229205 “Re-enable PRIM_CAST_SHADOWS” came up for discussion, it is believed that the viewer-side code for it has been deprecated / removed, and the server also no longer recognises the function.
  • Runitai Linden suggested it is something that should be re-enabled on the grounds that it is “something that most graphics engines let you do.”
  • However, any final decision will be subject to further internal discussions within LL.
• Request: allow seated avatars to temporarily have a physics shape of none if explicitly set by script (potential use-case: an in-world game uses tiny vehicles in a scaled environment to simulate a larger playing field, but as the drivers are normal-sized avatars, they cause collisions between one another, impairing gameplay; disabling the avatar physics would  in theory prevent this, although it is not clear if such a change would be recognised by the simulator, where it is believed the expectation of avatar physics is  assumed throughout the code).
  • The discussion encapsulated requests such as BUG-5538, the need for an overhaul of the camera control system & better LSL access to same; better joystick control options, and better support for alternative input types.
  • The latter point in turn led to a discussion on wider HID support and even the potential for MIDI (Musical Instrument Digital Interface) support (having been a means to provide remote control and synchronisation prior to HID design becoming the “standard”) as a means to transport and synchronise joystick inputs from the viewer to the simulator in a generic, open manner.
  • All of this was spitballing, rather than the formulation of an actual project.

TPV Developer Meeting

• [Video 26:10-53:10] Animation Override Discussion – TPVD
  • This follows-on from the week #3 TPVD meeting.
  • Essentially what is being sought is a solution similar to the Firestorm AO (but without the apparent overheads) that effectively allows viewer-side replacement of animation states sent by the server with local animations, avoiding the need for scripted HUDS / attachments.
  • Much of the discussion at this meeting is clarifying the original request for Vir Linden’s benefit, although the consensus is that official a cap replacement for llSetAnimationOverride and allowing TPVs to implement their own viewer-side AO UI elements would be a good start.
  • Once this has been done, then discussion can turn to the more complex issue of adding further animation states.
  • A Cap and viewer-side controls will not fully eliminate scripted AOs (particularly in the case of non-human AO walks, sits stands, for example), but this shouldn’t negate the provisioning of a Cap.
  • Please refer to the video for the discussion – much of which is in text chat.