Category: SL User Group 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, thanks 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 issue 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

January 2026 SL Web User Group

Posted on by Inara Pey
The Web User Group meeting venue, Denby

The following notes cover the key points from the Web User Group (WUG) meeting, held on Wednesday January 14th, 2025. These notes form a summary of the items discussed and is not intended to be a full transcript. Pantera’s video is embedded at the end of this article, my thanks to her for providing it.

Meeting Overview

  • The Web User Group exists to provide an opportunity for discussion on Second Life web properties and their related functionalities / features. This includes, but is not limited to: the Marketplace, pages surfaced through the secondlife.com dashboard; the available portals (land, support, etc), and the forums.
  • As a rule, these meetings are conducted:
    • On the first Wednesday of the month and 14:00 SLT.
    • In both Voice and text.
    • At this location.
  • 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.

Updates

  • The past month hasn’t been very active for the web team due to the holiday season. There has been a focus on internal updates, security patching, and clean up.
  • Some of the above include:
    • Additional security features around marketplace to increase security and add resilience.
    • Version upgrades to LL’s internal services for security upgrades.
    • Upcoming security feature to nudge residents to update and verify their email address on file.
  • There is also something of a focus on trying to clear-up outstanding Canny issues (so maybe this and this will get addressed?).
  • There is a hope that the focus on back-end services, whilst not necessarily visible to users will this help to see the overall experience of using the Marketplace, etc., become far smoother with fewer outages, issues with people being overcharged for product listing enhancements (PLEs), etc.
  • A significant push for 2026 will be “first impressions” / the new user experience -trying to further improve things so that incoming users have a generally positive experience which encourages them to keep logging-in.

In Brief

  • Kali Linden departed the Lab around the end of November / beginning of December to become VP of system security at a new start-up. Many thanks to her in absentia for all her work a LL.
    • As a result of this, the Lab’s web engineering are operating on a “shared ownership” basis until someone can be hired-in to fill Kali’s role.
    • Kali’s departure also means that some of the planned roadmap for web properties (e.g. the Marketplace UI overhaul) are being reassessed in terms of what can / should be achieved, etc.
  • There have been reports of the SL forums running “slowly” for people in the UK (and Europe?). The Forums are operated by a third-party supplier, and somewhat outside of LL’s direct control. This has been escalated to the forum vendor, but not other updates at present.
  • A request was made to be able to transfer L$ amounts between accounts / to others via a user’s secondlife.com Dashboard – with suitable security in place.
    • This was seen as an “interesting” idea, but would likely require some additional security – such as being tied-into MFA.
    • No commitment was made towards implementing the idea at this time, because further investigation on requirements, etc., would be required.
    • A suggestion was made to set a limit on how much a user directly transfer – or allowing a user to set a limit on the amount (e.g. account-to-account, rather than via a vendor or similar system) at any one time, in order to safeguard accounts against being emptied if successfully hacked. This was also seen as potentially interesting, but could be a  dynamic / fluid set of rules.
  • LindeX use, transaction fees, etc., came up for discussion (although perhaps better placed at the content Creation meeting, where people who routinely cash-out from SL are liable to be in attendance).
    • A loose consensus at the Web meeting was that greater clarification should be given as to what can be paid for directly using L$ / the USD wallet &without incurring additional processing fees (e.g. some users apparently think they have to convert L$ to dollars in order to pay their tier, etc.).
    • A clearer break down of the current transaction fees in a single place (buy for L$, credit processing for cashing-out, cost for subscribers, etc.) could perhaps be given within the Dashboard.
  • A discussion on SL maps – including searching by region name, improving World Map tile resolution, enhancing the map capabilities in general, etc.
    • A fair point was made that the maps are a core way of expressing the size and persistence of SL – yet the capability and the functions around it are perceived as being of little interest to LL management when it comes to prioritising updates, etc., with the focus appearing to be only on areas that directly affect commence in SL.
    • Maps are a vital component in the “first impression” aspect of Second Life – if incoming users can be encouraged to understand the SL is bigger than the welcome hubs and the selected destinations beyond them – and that they can, using the maps – explore on their own / in conjunction with the Destination Guide, then there is a motivation for them to keep logging-in and to start exploring.

Next Meeting

  • Wednesday, February 4th, 2026.

2026 week #1: SUG meeting summary

Posted on by Inara Pey
Natthimmel: The Keepers of Twin Lights, St. Castoris, December 2025 – blog post

The following notes were taken from the Tuesday, January 6th, 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 appear to be undergoing restarts this week, with no deployments.

Game Control

  • Leviathan Linden had planned to try to port game_control back into the develop-Linux branch, but was beaten to the line bye Rye of the Alchemy viewer, show has submitted a Pull Request.  Rye’s submission looks good, but has yet to be built.
  • This means that if the Linux build passes muster, it can join with the Windows and Mac builds and be passed into the main develop branch.
    • However, it has been a report of issues with Rye’s build on systems not using Pulseaudio, which tend to crash on start, so this will have to be investigated, although the overall impact on Linux users was the subject of debate.

SLua Work

  • No indication on when the SLua viewer will be promoted to release status – but that is a question more for viewer meetings.
  • Harold Linden noted his personal “to do” list for SLua is mostly around improving testing / allocation strategy in general, and noted that it is currently growing as LL find usability issues they think are worth pushing the viewer release back for, in order to get them included.
    • One of the things Harold would particularly like to see working is setting link primitive parameters “in a sane way to be less-bad by the time we go general availability for sure”.
    • He also noted he’d like a `require()` function that works correctly with the built-in editor as well.
  • Harold further noted that there is some rearchitecting that needs to go on behind the scenes, and the viewer definitely needs to be in a better state prior to promotion.
  • This led to a further conversation of possible SLua inclusions / updates, and on things like script scheduling – LSL vs. SLua (should be no difference), and script execution.
    • Harold further noted he is refactoring the script scheduler is he goes to try to improve things but in terms of scheduling and execution, and so the simulator isn’t spending “a lot of time figuring out that it has nothing to do”.
    • Multi-threading isn’t seen as an answer for this, because some scripts may be waiting on work being carried out by scripts currently running, and multi-threading could being this dependency.

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

  • As well as working on Game Control (documentation here), Leviathan Linden has been trying to track a crash/corruption bug he accidentally introduced into the development simulator branch. The impact of this should be very limited – has only thus far shown up on the SLua test regions.
  • Leviathan also noted that there are been no progress on:
    • Experimenting with adjusting avatar bounding box size.
    • Enabling avatars to turn to face the direction of travel of travel when walking backwards (on the official viewer).
    • No progress on fixing the mesh mismatch issue.
  • Monty Linden warned that the Lab is coming up on the “annual simhost certification dance”, and will be part of the 2026.01 “Kiwi” release.
    • This should be invisible to everyone with one weird exception: The ‘TLS Web Client Authentication’ in the EKU is now *strongly* deprecated at all certification authorities. Monty noted that “No one should care unless they extended/ported the SL viewer’s fussy cert code that checks the server part of this”.
  • Henri Beauchamp (Cool VL Viewer) put forward a lengthy outline for solving the issues of avatars already in a region appearing as clouds to those newly arriving – which appears to be a largely server-side issue. He has developed a viewer-side workaround, and proposed a server-side messaging fix which would negate any need for viewer-side workarounds.
    • Both Leviathan and Monty Linden have an interest in trying to eliminate cloud avatars, and Leviathan indicated he would look at Henri’s proposed fix.
    • This extended into a discussion on solving the issues of missing attachments on visible avatars when people TP into a region, etc.

Date of Next Meetings

  • Leviathan Linden: Tuesday, January 13th, 2026.
  • Formal SUG meeting: Tuesday, January 20th, 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.