Category: SL User Group Meetings

2026 week #6: SUG meeting summary

Posted on by Inara Pey
Whithermere, January 2026 – blog post

The following notes were taken from the Tuesday, February 3rd, 2026 Simulator User Group (SUG) meeting. These notes form a summary of the items discussed, and are not intended to be a full transcript. They were taken from the video recording by Pantera, embedded at the end of this summary – my thanks to Pantera for providing it.

Meeting Overview

  • The Simulator User Group (also referred to by its older name of Server User Group) exists to provide an opportunity for discussion about simulator technology, bugs, and feature ideas is held every other Tuesday at 12:00 noon, SLT (holidays, etc., allowing), per the Second Life Public Calendar.
  • The “SUG Leviathan Hour” meetings are held on the Tuesdays which do not have a formal SUG meeting, and are chaired by Leviathan Linden. They are more brainstorming / general discussion sessions.
  • Meetings are held in text in-world, at this location.

Simulator Deployments

  • Tuesday, February 3rd, 2026:  the SLS Main channel simhosts were restarted without any deployments.
  • Wednesday, February 4th, 2026:
    • Simulator release 2026.01 (Kiwi) should be deployed to the BlueSteel and preflight RC channels.
    • All remaining Release Candidate channels will be restarted without any deployment.
    • A new server-side SLua update will be deployed to the SLua Beta regions. This will support a new permission “PERMISSION_PRIVILEGED_LAND_ACCESS”, allowing the llSetParcelForSale function to be used (and potentially other parcel settings in the future), but will require a viewer-side SLua update.
  • The simulator release to follow that – 2026.02 – has been given the code-name of Loganberry, but it’s too early in development for details to be provided.

In Brief

Please also refer to the video, below.

  • Leviathan Linden had two announcements concerning his current work:
    1. He has a proposed resolution for the false error report when failed rez on mesh, whereby an attempt to rez from inventory onto some mesh surfaces result in a failure to rez and incorrect error message.
      • He describes the resolution as “a workaround hail mary” rather than an outright fix: if the first attempt fails, the serve will try again try again using the bounding box of the mesh object. See: also: Why can’t I rez on my mesh table/floor/bed in Coming to Firestorm soon… A couple of new features for builders and non-builders alike.
      • He further noted that during the rezzing request to the simulator, the viewer supplies a line segment: ray_start and ray_end, and it is possible that ray_start and ray_end might be insufficient to actually hit the mesh object’s collision shape when that shape is different from its visible shape.
      • The led to an on-going discussion in the meeting.
    2. He has also started a further look into issue #3469, comment 2819987122, whereby some uploaded assets have the incorrect number of faces on the server, and trying to set the textures on those faces appears to work on the viewer but a) if the object is cloned, the new clone doesn’t have the texture changes and / or b) the original object will revert to a pre-texture change state at a later date. He has an idea for a possible fix, but is not sure it will work, so wishes to test the idea before passing further comment.
  • Monty Linden indicated the annual simhost certification work is still in progress. He further noted:
    • The Kiwi release includes an update which should be highly compatible with the current certificates. But if anyone who has experienced issues with past certification updates should test on the Preflight or BlueSteel RC channels following the Wednesday deployment.
    • Current relevant expiration dates are: Agni – 23:59:59 GMT on March 13th, 2026; Aditi – 23:59:59 GMT on February 28th, 2026.
    • As per the last formal SUG meeting, he hopes to automate the recertification later in 2026, and the certification process will change slightly at that time.
  • Harold Linden has been “working on a lot of things surrounding SLua but not specifically SLua itself. These include:
    • Refactoring  the definitions repo where all LSL constants and functions and how they behave are documented, because the repo was becoming unwieldy. He passed on thanks to all those who have helped contribute to the repo.
    • Further work on the `require()` RFC. The new release that’s coming out won’t have any new features, but the release after that should have `table.append()` and `table.extend()`, and _maybe_ some of the SetPrimParam list-building wrappers., adding: “Basically, if you’ve noticed how annoying it is to build list for setprimparams, it’ll be much better with these changes. Hopefully.”
  • Roxie Linden gave an overview of recent WebRTC updates:
    • Most WebRTC improvements are going into the voice servers, so the simulators shouldn’t have and effect on WebRTC quality.
    • LL is working on spatialization improvements, which might be released as soon as this week.
    • The latest updates to the WebRTC server appear to have fixed the majority of crash issues.
    • March remains the tentative release month for grid-wide WebRTC, the the sawp-over occurring as a part of the normal simulator deployment cycles.
  • A broad discussion on scripted capabilities (e.g. giving inventory to attachments (possible) and deleting inventory from attachments (not possible); setting script pin from setlinkprimparams (on Rider’s personal roadmap); adding inventory operations for other prims in a linkset.
  • General disucasions:
    • SLua: it has (TimeProviderFactory.new():build()):askForTime() – equivalents to NUX time.now) a discussion on the SLua editor and its capabilities, SLua and HTTP.
    • LL is not currently carrying out any keyframe motion (KFM) work. This expanded into a general discussion on ideas for KFM work.
    • Ideas for better LOD performance.

Date of Next Meetings

  • Leviathan Linden: Tuesday, February 10th, 2026.
  • Formal SUG meeting: Tuesday, February 17th, 2026.

† The header images included in these summaries are not intended to represent anything discussed at the meetings; they are simply here to avoid a repeated image of a rooftop of people every week. They are taken from my list of region visits, with a link to the post for those interested.

2026 week #5: SL CCUG and Open Source (TPVD) meetings summary

Posted on by Inara Pey
Hippotropolis Campsite: venue for CCUG meetings
The following notes were taken from:

  • My chat log of the Content Creation User Group (CCUG) meeting of Thursday, January 29th, 2026 and my chat log of that meeting
  • Pantera’s video (embedded at the end of this article) and my chat log of the Open-Source Developer (OSD) meeting held on Friday, January 30th, 2026.
Table of Contents

Please note that this is not a full transcript of either meeting but a summary of key topics.

Meeting Purpose

  • The CCUG meeting is for discussion of work related to content creation in Second Life, including current and upcoming LL projects, and encompasses requests or comments from the community, together with related viewer development work.
    • This meeting is generally held on alternate Thursdays at Hippotropolis and is held in a mix of Voice and text chat.
  • The OSD meeting is a combining of the former Third Party Viewer Developer meeting and the Open Source Development meetings. It is open discussion of Second Life development, including but not limited to open source contributions, third-party viewer development and policy, and current open source programs.
    • This meeting is generally held twice a month on a Friday, at 13:00 SLT at the Hippotropolis Theatre and is generally text chat only.
  • Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

  • Default viewer 2025.08 – 7.2.3.19375695301 – maintenance update with bug fixes and quality of life improvements – December 2 – No Change.
    • Notable addition: new VHACD-based convex decomposition library for mesh uploads.
  • Second Life Project Lua Editor Alpha version 7.2.3.19911032641, December 5 –  No Change.
  • Second Life Project Voice Moderation viewer 26.1.0.20139269477, December 12 – No Change.
    • Introduces the ability to moderate spatial voice chat in regions configured to use WebRTC voice.
  • Second Life Project One Click Install viewer 26.1.0.21295806042, January 26, 2026 – one-click viewer installation.

Upcoming Viewers

Viewer 2026.01 – One-click Installer / Updater

  • Now available as an alpha viewer (above).
  • As the name suggests, triggers a one-click install / viewer update process.
  • Is still being worked on, with a focus on ironing out some kinks in the one click install, including an uninstaller for old non-velopack viewers that can be triggered when required, the usual registry stuff for Windows, and so on.
  • Also includes improved monitoring / logging of viewer freezes and crashes, etc.

Viewer 2026.02 – “Flat” UI, Font Changes

Example of the upcoming flat UI. Via: Geenz Linden / Github #4681/2
  • This viewer is to be part of the Lab’s “first impressions” push to make SL resonate more with incoming new users and hopefully encourage them to keep logging in.
  • Will include a new “flat” UI (as seen in the Project Zero (viewer in a browser) version) which comprises things like a font change, a colour scheme change,  and generally giving the viewer a more “modern” look and feel. This is not a major UI overhaul in terms of overall look and feel, more an aesthetic one.
  • Font changes within this viewer are currently described as “experimental”.
  • Also looking like it will include a log-in landing refresh.
Example of the upcoming flat UI. Via: Geenz Linden / Github #4681/2

General Viewer Notes

  • Work on clearing viewer bugs and implementing smaller feature requests into the viewer is continuing, so users can expect more of this, allowing for other priorities in viewer work.
  • On the viewer development side:
    • There should be some vcpkg movement in the near future. A Pull Request for this work via a third-party developer is apparently in progress, but will not be shipped immediately on approval. Rather, it will be allowed “soak time” so other developers can assess impact on their build pipelines downstream and the like.
    • There will also be some CMake project changes, although these appear to be more of a “modernization” push, to bring CMake in the viewer into line current CMake project norms.
  • LL is contemplating bringing back viewer maintenance releases to try to encourage some TPVs to pick-up bug fixes and incorporate them faster into their viewers (rather than waiting for a major viewer update which includes bug fixes to get to release status and then merging them).
    • If this is done, the maintenance releases will be “much smaller in scope” than past maintenance updates (so a kind of taking bug fixes that are flowing into upcoming major viewer releases, cherry picking them and then QA’ing and releasing them as a small update to the viewer.
    • Those TPVs at the meeting indicated this could either add to their workload or that they would not alter their existing workflow due to overheads, but instead will continue to cherry-pick upstream fixes as a part of their own release cycles.
  • In response to questions on whether Kitty Barnett’s RLVa code contributions will be included in the official viewer (and which are currently pending fixes she has submitted for RLVa avatar appearance fixes anyway), Geenz Linden stated:
If we did, it’d likely be a very progressive and targeted thing that we do. And hopefully not in a way that significantly makes downstream more difficult to maintain. It’s a longer discussion that needs to be had basically. 
    • This led to concerns that LL could end up implementing a variant of  RLVa that is at odds with the current RLV/RLVa API, and effectively end up being ignored for being incompatible. In response, Geenz further noted:
I’d prefer one that everyone can participate in if we do go that route so we can be more targeted with others helping to guide that. Last thing we want to do is make it take 7 months to ship a TPV just because we made a change to RLVa. We also have to consider overall content compatibility and such.
  • Also as per the last meeting, official Linux support is aligned with the in-progress SLua viewer .

“First Impressions” Context

  • This work is focused on trying to ease that first experience for a lot of new residents to try and drive up retention numbers.
  • The work is seen more-or-less as experimentation at this point in time, but the goal is to drive up first day engagement among incoming new users to encourage them to continue to log-in to SL.
  • Work on this is on multiple fronts, and more will be shared on it in due course.

Grid-Wide WebRTC Deployment

  • The Lab is currently looking at a March deployment of WebRTC voice across the grid, but this is subject to possible change.
  • The viewer server is currently in a beta soak test (see: WebRTC Voice Open Beta is Expanding).
  • The last major server crash has been fixed, and there have been none since that fix went in.
  • There is an upcoming fix – see Pull Request #5322  (included in viewer 2026.01) – to address some of the issues with voice dropping. The recommendation is for TPVs to get this into their viewers for a good user experience.
  • An upcoming server-side update will hopefully address some of the issues with WebRTC spatialisation (e.g. voice volume varying greatly with even small camera position movements on the part of a listener).
  • Additional connection tweaks for WebRTC have been made to the 2026.01 viewer to help improve voice performance (e.g. to improve auto-reconnect).
  • Feedback on people’s experiences with WebRTC is still being sought (notably via the beta testing).

SLua Update

  • An update to the SLua project viewer is forthcoming.
  • As noted above, this will bring with it support for Linux
  • Still no confirmation as to when SLua will go live across SL

General Discussion

OSD Meeting

  • SSR and PBR water real time reflections and shadows: Geenz indicated that work is progressing on this and that when available, it will be given “a proper” alpha/beta/Release Candidate process.

  • The was noted that whilst improvements on SSR and PBR water reflections are being made, they will never 100% match pre-PBR views without a lot of work being put into optimisation, what would likely still result in mixed feedback without any significant win.
  • This led to a general discussion on addressing water reflections and shadows.

CCUG Meeting

  • PBR lighting: still on the list of potential updates, but requires “quite a few” server-side changes in order for it to happen.
    • The existing SL lighting system has a range of constraints dating back 20+ years, and so would require significant modification in order to enable PBR lighting support.
    • As such, this is currently viewed as being on the back burner for the foreseeable future, while other things are worked on.
  • A question was asked on whether it would be possible for an Animesh using only ten bones in total to have a lower Land Impact / rendering cost than one rigged to 10 out of the 110 bones of the default skeleton. Short answer: no, not without custom rigs.
  • Custom rigs themselves are acknowledged as something SL should have, but the work involved in enabling them is extensive and touches on multiple areas (e.g. re-targeting bones for clothing fits; re-targeting animations – and even a couple overhaul of the animation system -, etc.). There is also work to be carried out elsewhere that would yield benefits for things like quality of life which are of a higher priority. As such, custom rigs are not something currently on the roadmap.
  • In-world mesh creation tools: unlikely to be a thing, as the implementation would be costly in time and effort, and likely would not measure up to the capabilities of external tools like Blender.
  • It was asked if the import route for rigged meshes could be “streamlined” without the need for AvatarStar / MayaStar. Neither of these tool are actually a requirement for rigged mesh import / export, rather they are tools that can help with the process of rigging from within SL. Meshes that have been correctly rigged and weighted using external tools should import correctly through the current import mechanisms (COLLADA or glTF).
  • Overhauling the mesh import file format  / process through the support of something like OpenUSD is an idea that is being mulled over within the Lab. However, a) this is not something that is likely to be prioritised in the next 12 months; b) it is something that would require a lot more in the way of discussion before moving towards it; c) there is still work to be done in improving the import / export of currently supported formats before trying to add to them / replace them.
  • Materials import for meshes: this is something the Lab wanted to implement for glTF mesh import (rather than having to import materials separately).
    • However, due to the way in which asset uploads to SL work, it proved to be more a complex issue than first thought.
    • The hope is that the work can be returned to in the future, possibly using a new import flow that is more in line with other platforms and tools, but this is not something on the current roadmap.
  • PBR specular support: this is still something Geenz would personally like to get done, but it is currently sitting behind various other items which need to be completed / implemented in order to clear time for working on it. Also, this work does have impacts on things like the glTF upload validator, scripting, simulator support, managing glTF overrides (which are currently not well handled) etc., all of which would have to be factored into the work and which are outside of Geenz’s immediate responsibilities.
  • In terms of extending glTF support in general (PBR specular, IoR, etc.), the preference at the moment is to fix more of the existing issues / bugs within the existing PBR capabilities before adding further options.
  • The meeting was somewhat sidetracked by talk on the use of bots, ToS bot violations, Tiny Empires, etc., the majority of which are more of a Governance issue.

Next Meetings

January 2026 SL Mobile UG meeting summary

Posted on by Inara Pey
Campwich Forest grounds: location for the Monthly Mobile User Group (MMUG)
The following notes were taken from the Thursday, January 29th 2026 Monthly Mobile User Group (MMUG) meeting. These notes should not be taken as a full transcript of the meeting, which was largely held in Voice, but rather a summary of the key topics discussed.

The meeting was recorded by Pantera, and her video is embedded at the end of this summary – my thanks, as always to her in providing it.
Table of Contents

Meeting Purpose

  • The Mobile User Group provides a platform to share insights on recent mobile updates and upcoming features, and to receive feedback directly from users.
  • These meetings are conducted (as a rule):
    • The last Thursday of every month at 12:00 noon SLT.
    • In Voice and text.
    • At Campwich Forest.
  • Meetings are open to anyone with a concern / interest in the above topics, and form one of a series of regular / semi-regular User Group meetings conducted by Linden Lab.
  • Dates and times of all current meetings can be found on the Second Life Public Calendar, and descriptions of meetings are defined on the SL wiki.

Resources

Current Releases

SL Mobile (Beta) version 2025.1075 (A) / 0.1.1075 (iOS) – December 12, 2025 – Avatar loading improvements.

New Starter Experiences Update

[Video: 5:37-7:08]

  • SL Mobile is seeing new users signing-up and joining SL, this led to the creation of a series of New Start Locations for those coming in via Mobile to be able to easily reach, and which have been put together by the location creators specifically to be Mobile-friendly.
SL Mobile New Starter Experiences front-and-centre.
    • The range of available experiences is being expanded, with the latest being a Brazilian-based experience – the Brazilian Beach Hangout – offering Voice in both English and Portuguese.

SL Mobile Alpha

[Video: 7:13-8:53]

  • As many are aware (and a part of ), there is an invite-only SL Mobile Alpha group providing early access to users to help test upcoming Mobile features and updates prior to them being made publicly available through the main Beta programme on Android and iOS.
  • The app for this programme is entirely separate to the app available via the Apple and Google stores.
  • The most recent releases to Alpha include Bubble Chat and single-taps.

Bubble Chat

  • This is is response to complaints about having to switch views / trying to remain in contact with the in-world scene when using chat.
  • Allows chat and incoming IM’s to be viewed over the in-world scene, and allow tap-to-reply.
  • In the initial iteration, tapping a message to reply will still take a user back to the menu to show the keyboard.
  • However, as the feature is expanded, it is hoped that it will enable the keyboard overlay to be displayed over the in-world scene to allow for faster responses without having to switch away.
  • Bubble Chat is also seen as a means of encouraging greater use of Mobile rather than just a quick “checking in” tool.

Single Tap to Interact

[Video: 10:07-11:45]

  • Interactions with SL Mobile can be “tedious” in terms of the number of taps, etc., required to initiate an action – such as chatting, finding a person’s name  / profiles, etc., and even interacting with objects.
  • Single Tap to Interact replaces the current long press required to garner a response from objects in the world view (display the context menu). When tapping on an item, Single Tap will display the top items in the context menu as an overlay to the in-world view. So for example:
    • Tapping on an avatar will display the options to send an IM or Friend request or expand the menu to see more options – such as their Profile.
    • Tapping on an in-world object will similarly display the most common options in the context menu (e.g. “sit” if it is chair / seat), with an option to display the rest of the context menu.
  • Like Bubble Chat, Single Tap is seen as a means to increase on-going use of SL Mobile beyond being an adjunct to using the viewer, and allow greater opportunity for users to be active in SL when using Mobile.

Technical Notes on Both

[Video:  12:43-17:21]

  • Bubble Chat is seen as relatively “easy” to implement, outside of one or two quirks in how Unity handles uniformity of presentation of things like overlays, which does require a little additional work to solve.
  • Single Tap to Interact is a more complex subject, as it not only involves changes to the underlying touch functionality, it is also attempting to more accurately map on-screen taps to ensure the right focus and the the resultant correct menu is displayed.
    • On-screen interactions – touch, tap, etc., – can be seen as collisions, which require a degree of physics calculations. Generally in SL the vast majority of physics interactions and collisions are managed by the server – the viewer is essentially “dumb” to them.
    • With Mobile, this can lead to inaccuracies arising between where the screen is touched and where the simulator thinks it has been touched, simply because of the network latency involved in back-and-forth communications and calculations, resulting in the noted frustrations with long-touch, etc.
    • So as a part of the implementation of Single Tap, it was decided to incorporate some of the physics-related calculations into the app itself.
  • Incorporating physics calculations into the app has involved building a “mini physics simulator”, capable of loading all of the physics colliders into the app’s already constrained memory limits (so effectively pre-caching them), and providing a means for the colliders and calculations to be recognised by, and accurately passed between, two different physics engines  – Havok on the simulator, Unity’s own in the app.
  • Whilst complex, this has resulted in a significant reduction in latency between touch and response and in ensuring the relevant menu appears, and with little to no added latency resulting from the device hardware having to do all the pre-caching and calculations. the only appreciable impact is on networking bandwidth during the pre-caching process.
    • A further help here is that the Unity physics engine can be switched off excepted for when actually required, thus removing a continuous overhead for the app.
  • This work will also help with other physics-related interactions down the road.

Future Work

[Video: 29:41-34:39]

  • Stability: the Lab uses both their own internal metrics and those from the app stores to monitor SL Mobile’s overall stability.
    • There has been a steady decrease in Android crash rates, and a further fix is coming in the next production beta release of Mobile.
  • New work being initiated (no due dates / target release dates at present):
    • Persistent chat (i.e. chat histories persisting between Mobile and viewer, rather than being broken by using one or the other).
    • Chat logging.
    • More work on language localisation for Mobile.
  • Map and Search:
    •  Search: Web search is already Mobile responsive, but hard to use. To overcome this, this preferred route at present is to take Web Search and put it into Mobile as an embedded view. This requires a certain amount of work, which is in progress in terms of how to best present Web Search within the app and ensure its performance, prior to actually embedding it into the the app.
    • Map support: starting to be looked at as a facet of Search, with the hope that the two will be fairly well integrated with each other in the future and where relevant (e.g. toggling between Search and the Map when searching for places). Once this is in place, the Mobile team will look to build further viewer World Map functionality into the Mobile Map.

General Q&A

  • What is SL Mobile’s maximum Draw Distance?
    • Up to 250 metres can be selected (but not recommended), but the app currently defaults to 40-50 metres to reduce the memory load.
    • As a rule of thumb, every additional 10 metres of draw distance can result in 30%+ of the app’s memory allocation (determined by the OS / hardware) to rendering alone.
    • Higher distances can be set at the user’s discretion via settings, but these can impact performance., and many of the higher settings (100m+) are not recommended for general use, as noted here and in the app.
    • A danger with exceeding memory limits in an app is that the OS will simply drop it without warning.
  • Concern was expressed about content being suitable for Mobile consumption – LODs, Land Impact, etc., – and on the need to encourage content creators to think Mobile in their work.
    • The Mobile app does actually carry out a degree of object culling to lighten the load – small objects, for example, aren’t rendered unless directly focused upon.
    • There have been internal discussions at the Lab about Land impact and how it relates to Mobile, but no firm decisions have been taken.
    • The matter of LODs and content creation tools vis-à-vis Mobile has also been discussed, but again, no firm decisions have as yet been made. LOD models are a part of a wider discussion overall for SL, given they also impact lower-specification hardware running the viewer, and there are on-going talks (e.g. through the Content Creation User Group) on LODs, automatic LOD generation, decomposition tools, etc.
  • PBR, Shadows and EEP support:
    • PBR – not yet.
    • Shadows – yes, supported, but is device-dependent, as shadow rendering is expensive (e.g. can as much as triple the rendering complexity for a scene).
    • EEP – limited support, with two passes of integration carried out so far. More work is required on this (e.g. average scene lighting to bring Unity’s lighting more into line with how scenes appear on the viewer), but it is not an easy task in terms of future maintenance.
  • Will SL Mobile support:
    • In-scene dialogue menus (i.e. the blue menus displayed when touching scripted object in the viewer)? – Yes, possibly in the next couple of months.
    • A walk / run / fly toggle on the movement joystick? – This is something that LL would like to support down the road.
  • Alpha Texture support: there are two primary issues in managing alphas on Mobile:
    • Formats: the viewer uses JPEG2000 for textures, Mobile uses a variety of formats which are hardware-dependent, and so additional work such as switching out texture formats is required – which itself can be problematic (e.g. can invalidate texture caches and cause issues such as slow loading, etc.).  However, Adam Sinewave (Mobile Lead Developer) does have a potential fix for this in the works.
    • Tiled-based GPUs: these are common on mobile hardware and do not like overdraw (rendering the same texture multiple times, required for alphas).
    • Both of these mean that Mobile uses a mix of dithered alpha rendering and temporal anti-aliasing to achieve the desired result. This actually simplifies alpha rendering on Mobile, but does produce unwanted artefacts on transparency, some of which will be hopefully resolved, others of which might continue to result in differences in how alphas appear on Mobile compared to the viewer.
  • Will SL Mobile be made available through other mechanisms than Google Play Store? Possibly, the idea of providing Android Package Kits (APKs) has been discussed, but brings with it a distribution problem. Also, the idea of using Google’s update mechanism for apps has also been discussed, which would bind SL Mobile more to the Google Play Store.
  • Minimum requirements for Mobile: these are somewhat hardware constrained (CPU / GPU pairing). As a broad rule of thumb, SL Mobile requires a device with at least 4Gb of RAM, and preferably a more recently SoC combination of CPU/GPU.

Date of Next Meeting

2026 week #5: SUG Leviathan Hour – Game_Control and bits

Posted on by Inara Pey
Whithermere, January 2026 – blog post

The following notes were taken from the Tuesday, January 2th, 2026 Simulator User Group (SUG) off-week meeting (the “SUG Leviathan Hour”). These notes form a summary of the items discussed, and are not intended to be a full transcript. They were taken from my chat log of the meeting, and Pantera’s video is embedded at the end of this article – my thanks to her, as always, for recording and providing it.

Meeting Overview

  • The Simulator User Group (also referred to by its older name of Server User Group) exists to provide an opportunity for discussion about simulator technology, bugs, and feature ideas is held every other Tuesday at 12:00 noon, SLT (holidays, etc., allowing), per the Second Life Public Calendar.
  • The “SUG Leviathan Hour” meetings are held on the Tuesdays which do not have a formal SUG meeting, and are chaired by Leviathan Linden. They are more brainstorming / general discussion sessions.
  • Meetings are held in text in-world, at this location.

Simulator Deployments

  • There were no planned deployments for the SLS Main Channel.
  • Wednesday, January 28th might see the next simulator update 2026.01 (Kiwi) to one or more simulator RC channels. However, this is an assumption given the status of the release last week, and no confirmation was given at this meeting.

Game Control Update

  • Leviathan Linden has cut a pre-release of the new game-control viewer, thank to work by Rye of the Alchemy Viewer.
  • If anyone tests on Linux or MacOS, Leviathan would love to have direct feedback on success/failure, either via the SUG meetings or via IM in-world.
    • In this he noted that “MacOS does some silly proprietary checks and only supports a small set of officially sanctioned controllers” and LL are limited to whatever Apple support, as otherwise the viewer doesn’t even see see hardware detection events ton Mac OS.
  • He also noted that one feature of game-control is you can allow normal avatar control inputs (either from keyboard or the UI widgets) to be interpreted as game-control events that get sent to the server. But – that mode doesn’t provide access to all the possible buttons that a game controller has: just a few of the buttons, because the game-control feature is a work in progress (WIP) and he hasn’t as yet worked out how best to map everything.

Game_Control Resources

SLua Mini-Update

  • General appreciation for the work Harold Linden has put into the project, and requests at LL keep him on for the future – although he has indicated he is happy working as a contractor.
  • No news on when the latest simulator-side updates to SLua will see the light of day, but they are not in the upcoming 2026.01 (“Kiwi”) release. They Might make the cut for the follow-on 202602 (“Loganberry”) update.
  • The SLua beta viewer is progressing, and will progress to release status in due course.

SLua Resources

In Brief

  • Leviathan gave insight into some of his work remit, and those of other members of the simulator engineering team:
    •  Some of his work is visible to residents, but he also work on internal problems: things that are causing headaches for other developers, the support team, etc.
    • Currently, he working on an issue whereby simulator states (simstates) sometimes fail to save. These appear to be related to LL’s use of a new compression scheme for simstates: zstd. This should offer faster compression/decompression and smaller packages. However, it is reporting failures every once in a while. These, Leviathan believes, appear to occur during simulator rolls. He’s still investigating this.
    • Like other members of the simulator engineering team, he is on pager duty for the week. This occurs once every four weeks, and when on pager duty, the team member is typically working on maintenance issues: bugs and such.
  • In addition, Leviathan is continuing to investigate / fact-find about the whereby when sometimes rezzing an object on a mesh surface will fail and supply an incorrect or misleading message (e.g. not having parcel rez rights or something).
  • No work has been started on addressing the wrong-number-of-faces-on-old-mesh-uploads problem yet. However, Leviathan hopes that if he can find time to start looking at this again.
  • The search for a new Senior Vice President of Engineering is on-going, and the Lab is “see great candidates”.
  • There is a reported workaround for avatars becoming stuck on a region crossings when riding a vehicle:
    • It appears possible to escape from the broken state after a failed region crossing by deleting the sit target, forcing the simulator to recompute what’s sitting on what, and seems to unjam left-behind avatars. If this works, they should be able to walk to the vehicle and re-sit (or RLV potentially used for a re-sit, if available.
    • The workaround is described as “a horrible hack”, but appears to be the best temporary “solution”.
    • Leviathan indicated he will look at it as well.
  • A general discussion on the missing SIT_FLAG_INVISIBLE, which also included llSetLinkSitFlags, a working SETMASS() flag – and its workaround and avatar bounding boxes. Please refer to the video for details.
    • The request for a working llSetMass() script method was being requested by some race bicycle creators who wanted to eliminate some variance in vehicle performance.
    • The above rolled into more general discussions and WIBNIs (“wouldn’t it be nice ifs”).
  • General discussions on the discrepancy between avatar height and prim height as reported on most viewers and avatar movement (e.g. introducing mousewalking to the official viewer) – again, please refer to the video.
  • From comments passed at the end of the meeting, it would appear that the work on implementing RLVa into the official viewer, initiated by Kitty Barnett and Vir Linden (prior to his departure from the Lab) may have been stalled.
  • It was suggested that LL carry out a limited survey of TPV users and request then list their top X TPV features that prevent them from using the official viewer. These could then be collated in terms of common requests and used as an initial starting point for possible prioritisation  / integration.
    • Exactly how a good cross-section of TPV users could be found was an open debate.
    • Managing such a task might be problem for LL, as it would require input from all of the core engineering teams to offer their input – deflecting many of them (approx 45 LL employees) for core activities.
    • Contextual note: “approx 45” does not mean that this is the total number of developers work on SL – the Lab utilises contractors on and individual and company (ProductEngine) contractors, plus a lot of general operation on the server-side are now handled through AWS.

Date of Next Meetings

  • Formal SUG meeting: Tuesday, February 3rd, 2026.
  • Leviathan Linden: Tuesday, February 10th, 2026.

† The header images included in these summaries are not intended to represent anything discussed at the meetings; they are simply here to avoid a repeated image of a rooftop of people every week. They are taken from my list of region visits, with a link to the post for those interested.

2026 week #4: SUG meeting summary

Posted on by Inara Pey
Reality Escape, January 2026 – blog post

The following notes were taken from the Tuesday, January 20th, 2026 Simulator User Group (SUG) meeting. These notes form a summary of the items discussed, and are not intended to be a full transcript. They were taken from the video recording by Pantera, embedded at the end of this summary – my thanks to Pantera for providing it.

Meeting Overview

  • The Simulator User Group (also referred to by its older name of Server User Group) exists to provide an opportunity for discussion about simulator technology, bugs, and feature ideas is held every other Tuesday at 12:00 noon, SLT (holidays, etc., allowing), per the Second Life Public Calendar.
  • The “SUG Leviathan Hour” meetings are held on the Tuesdays which do not have a formal SUG meeting, and are chaired by Leviathan Linden. They are more brainstorming / general discussion sessions.
  • Meetings are held in text in-world, at this location.

Simulator Deployments

  • All simhosts are undergoing restarts this week, with no deployments.
  • The next simulator release  – 2026.01 (Kiwi) is currently with QA.
  • The simulator release to follow that – 2026.02 – has been given the code-name of Loganberry, but it’s too early in development for details to be provided.

Game Control

  • Leviathan Linden had planned to try to get a project viewer branch put together for his game_control work, but has been sidetracked in dealing with issues with the Kiwi simulator code.
  • He still hopes to be able to cut that branch “on the side” and see if he can create an installable that can be used to check to see if the game_control code actually works with the port to the current viewer code branch.

Grid-Wide WebRTC Deployment Announcement

  • As per the most recent OSD meeting, LL is hoping to deploy WebRTC grid-wide in March 2026.
    • This is not a set-in-stone target, and further updates will be made.
    • This means that Vivox, whilst still being held in reserve, will no longer be available as a Voice service – so those using Voice and using a non-PBR  / WebRTC viewer will need to update.
    • The Lab is currently looking at a March deployment of WebRTC voice across the grid.
  • The public beta for WebRTC has expanded – see this official blog post for details –  and Roxie Linden and her team hope the beta expansion will provide more feedback from users on voice quality, voice stability, etc.
  • Transcription using WebRTC is being poked at by the Lab, but will not be a part of the initial deployment.

SLua Work

  • Harold Linden has a rough draft on how `require()` has to behave to make sense both in VSCode and in-viewer. This is very much a work-in-progress.
    • In short: if you’ve ever had to edit someone’s preprocessed LSL script without all the #includes they had on their disk, and had to wade into the generated code + //#line comment soup, this should be a more readable way to bundle together all the code so editing is nicer.
    • This prompted a series of question on the documentation – please refer to the video.
    • Having the include/require path include object inventory for scripts in objects was noted as future work.
  • A new SLua editor will be available with upcoming viewers which should have much faster script editing.
  • Rider Linden indicated he would like to add something to the VSCode plugin that would provide access to scripts in inventory – and noting a concern in giving anything automated access of any kind to agent inventory.

SLua Resources

  • The nine beta test regions are centred on SLua Beta Void (mind the water!).
  • Official scripting portal (this is a work in progress and open to contributions – Github for the latter here).
  • The Second Life official Discord server / channels.
  •  Suzanna’s SLua Guide (Suzanna  Linn).
  • Official VScode plugin notes:
    • It is not yet available on the VScode marketplace.
    • Issues and PRs for code submissions can be made here, and the plugin downloaded.
  • VSCode plugin + documentation (Wolfgang Senizen – likely be discontinued and contributions shifted to support the official documentation).

In Brief

Please also refer to the video, below.

  • Monty Linden indicated the annual simhost certification work is now in progress. Overall, very little is changing, so no problems are anticipated.
    • The new certifications are being used by the 2026.01 code running on the release test regions on Aditi (the beta grid).
    • Monty plans to automate the recertification later in 2026, and the certification will change slightly at that time.
  • A request was made to allow scripts to exchange messages (or streams of messages) with the viewer using by using llOwnerSay (sending towards viewer), and listen on certain channel (receiving from viewer) but directly without a listen.
    • Apparently a feature request for this is in development for submission to Firestorm.
    • Rider Liden expressed an interest in seeing that request once written.
    • This also sparked a discussion on how llOwnerSay works across region boundaries (e.g. with the help of child agents).
  • A general discussion on Drawer Distance and how to extend it beyond 1024 metres (e.g. via anchoring the camera in a region and flycamming to another and anchoring there – or by using a 3D Mouse such as SpaceNavigator  – my preferred choice).
  • Further requests for the Mainland default EEP setting to be adjusted and  on the status of llSetLinkGLTFOverrides fails to clear alpha override. The former will be referred back to the LDPW and Patch Linden (again), no answer was provided on the latter (it may have been missed in the chat).

Date of Next Meetings

  • Leviathan Linden: Tuesday, January 27th, 2026.
  • Formal SUG meeting: Tuesday, February 3rd, 2026.

† The header images included in these summaries are not intended to represent anything discussed at the meetings; they are simply here to avoid a repeated image of a rooftop of people every week. They are taken from my list of region visits, with a link to the post for those interested.

2026 week #3: SL CCUG and Open Source (TPVD) meetings summary

Posted on by Inara Pey
Hippotropolis Campsite: venue for CCUG meetings
The following notes were taken from:

  • My chat log of the Content Creation User Group (CCUG) meeting of Thursday, January 15th, 2026 and my chat log of that meeting
  • Pantera’s video (embedded at the end of this article) and my chat log of the Open-Source Developer meeting held on Friday, January 16th, 2026.
Table of Contents

Please note that this is not a full transcript of either meeting but a summary of key topics.

Meeting Purpose

  • The CCUG meeting is for discussion of work related to content creation in Second Life, including current and upcoming LL projects, and encompasses requests or comments from the community, together with related viewer development work.
    • This meeting is generally held on alternate Thursdays at Hippotropolis and is held in a mix of Voice and text chat.
  • The OSUG meeting is a combining of the former Third Party Viewer Developer meeting and the Open Source Development meetings. It is open discussion of Second Life development, including but not limited to open source contributions, third-party viewer development and policy, and current open source programs.
    • This meeting is generally held twice a month on a Friday, at 13:00 SLT at the Hippotropolis Theatre and is generally text chat only.
  • Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

  • Default viewer 2025.08 – 7.2.3.19375695301 – maintenance update with bug fixes and quality of life improvements – December 2 – No Change.
    • Notable addition: new VHACD-based convex decomposition library for mesh uploads.
  • Second Life Project Lua Editor Alpha version 7.2.3.19911032641, December 5 –  No Change.
  • Second Life Project Voice Moderation viewer 26.1.0.20139269477, December 12 – No Change.
    • Introduces the ability to moderate spatial voice chat in regions configured to use webRTC voice.

Upcoming Viewers

Viewer 2026.01 – One-click Installer / Updater

Viewer 2026.01 is in progress. This will include:

  • Improved bugsplat support (we want better reporting for freezes, and just generally better crash reporting). This work builds on the successes of 2025 in detailing with viewer crashes and reducing overall causes for crashes.
  • A new one-click installer, which in brief:
    • Will be powered by a new dependency called velopack, and will allow a single-click installation of the viewer (with a brief pop-up message), with the viewer launching once the install process is complete.
    • Will default to installing under Apps/Local on windows; will remain as a drag-and-drop process on Mac OS, while Linux is currently TBD. It will still be possible to install the viewer to a custom location, initially via a command line argument.
    • Will not change the install location of config files, or anything that counts as user data.
  • Development work on this did hit a delay, which has now been cleared, the hope remaining to get an Alpha (previously known as Project) viewer out with the update code in place sooner rather than later.
  • As an added benefit to the switch to velopack for TPVs, LL will be providing a solution to add auto-update functionality to TPV projects, if TPVs wish to leverage it. More information on this is due to be made available in the next week or so.

Viewer 2026.02 – “Flat” UI, Font Changes

  • This viewer is to be part of the Lab’s “first impressions” push to make SL resonate more with incoming new users and hopefully encourage them to keep logging in.
  • This first impression work is on multiple fronts, and for the 2026.02 viewer will be a switch to the “flat” UI seen in the Project Zero (viewer in a browser) version which comprises things like a font change, a colour scheme change,  and generally giving the viewer a more “modern” look and feel.
  • The font update:
      • Should not impact people’s use of unicode.
    • Will require XUI updates which will likely require updates for TPVs using their own custom XUI – TPVs are advised to keep an eye on Discord and Github for more information on these changes as they develop, and to particularly track this github issue.

General Viewer Notes

  • Linux support will likely ship as a part of the in-progress SLua beta viewer.
  • The viewer development roadmap is still being worked on in terms of fixes and updates and actioning feature requests, the focus being to work these into the viewer without disrupting major initiatives the Lab is looking to develop (such as the “first impressions” drive).
  • 2026.02 might include some screen space reflections (SSR) updates to help improve the appearance of Linden Water under PDR/HDR.
  • The avatar appearance fixes contributed by Kitty Barnett and intended to make the current outfit folder more reliable when changing outfits, messing with outfits, etc., may get to see the light of day in viewer 2026.03 – but this had yet to be confirmed.

Grid-Wide WebRTC Deployment – Initial Announcement (OSD Meeting)

  • The Lab is currently looking at a March deployment of WebRTC voice across the grid.
  • The schedule is not firmly set as yet, but will follow the usual server-side deployment routine: first to one (or more) simulator RC channels, then to all simulator RC channels (if not all rolled at once), and then a week after this, deployment to the Main simulator channel.
  • The important point in this is that once grid-wide, WebRTC will completely supplant Vivox Voice, and those who use Voice by who are not running a WebRTC voice capable viewer (which generally means anyone not on a non-PBR supporting viewer) will be unable to use Voice.
    • This does not mean that the Vivox service will be immediately shut-down. It will remain an option for the Lab to re-enable until such time as LL is confident in the WebRTC service and no surprises have come to light.
  • There is one remaining WebRTC critical issue in the viewer that makes the experience not great for a small body of users:
    • People with certain network characteristics may see a dropout because the WebRTC provider is not properly handling renegotiation.
    • LL has a fix which should be deployed with viewer 2026.01. However, TPVs wishing to merge it now can do so via Pull Request 5126.
  • In the meantime, the beta for WebRTC has expanded – see this official blog post for details.
  • Roxie Linden also indicated that LL is experimenting with speech-to-text using WebRTC, but does not as yet have anything available for public demonstrations.
  • The issue of Linux builds not using Pulseaudio but with the WebRTC code crashing on start-up was reiterated at the meeting. Whilst this might not be a widespread issue, the feeling was that it should be looked at; however, if the pool of impacted users is liable to be very small, it will not be seen as a reason to block / delay WebRTC deployment as a whole and any fix is liable to be prioritised in terms of resources / impact of the issue, post-deployment.

General Discussion – Both Meetings

  • Avatar support related:
    • Shape key support and / or custom bone hierarchies – seen as complex area of work, and not being looked at.
    • While the current avatar does technically use shape keys, it is very different to how modern blend shapes are used.
    • SL’s internal format also doesn’t store bones.
  • Questions were raised on the status of game_control. This is more a subject for the Simulator User Group meetings, where Leviathan Linden indicated he was trying to resume work on the code. However, it was also indicated during this meeting that Leviathan had again been “borrowed” to work on other code.
  • Despite rumour to the contrary, Puppetry is not currently set for revival or on the current 2026 roadmap.
  • Geenz noted that while work on things like new tools, updates to the GLTF uploader, etc., are not “done”, the focus for the time being in more on dealing with technical debt together with the aforementioned “first impressions” initiative, etc.
  • Questions were asked on auto / planar-aligning PBR materials  – see: Aligning Faces when using PBR and Planar face alignment with PBR GLTF materials. This is something the Lab has yet to resolve, and has offered a contribution bounty for any developer who is able to provide a solution. Geenz also indicated he would try to get bugs like this better prioritised.
  • A general discussion on ideas for improvements to chat, including: ability to have a “last unread” indicator in chat when logging-on; having the chat rings on the mini-Map on by default, some idea about a special chat tab that would allow region-wide chat (presumably at the region owner’s discretion to enable), ability to correct text in chat / IM after sending(!), etc.
  • The You Tube embedding issues was again raised (see here for more), with a possible (if hacky) workaround. LL are looking to You tube to address the problem, as they created it.
  • There was a general discussion on the complexities of Land Impact, particularly – but not restricted to – mesh objects. In short, LI is a complicated subject, and not easily addressed; hence why the Lab backed away from the subject recently. This also strayed into the equally complicated realm of LOD generation.
    • On the subject of LOD generation, it was suggested that the Lab should look to implement a LOD generator and then inform creators LODs have to be generated  to fit a defined set of criteria – or defaults will be forced.
  • A discussion on the choice of VHACD over HACD as a replacement for Havok in mesh decomposition. The latter is seen as more mature, but LL opted for VHACD is a “middle ground” solution as it is more regularly maintained, it is also apparently more reliable when dealing with the “weirder meshes” some SL creators produce, when compared to something like CoACD. However, Geenz indicated it would be “nice” to have “swappable”  convex decomposition solutions at runtime.
  • A further request for Error creating thumbnail” message on SL wiki, breaking images  to be addressed.

Next Meetings