2026 week #36: SUG meeting summary

The Simulator User Group meeting place at Longfellow

The following notes were taken from the Tuesday, September 1, 2026 Simulator User Group (SUG) meeting. These notes form a summary of the items discussed, and are not intended to be a full transcript. A video of the meeting by Pantera is embedded at the end of this summary – my thanks to her 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 “Leviathan Office 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

  • No deployments this week, but all simhosts will be restarted.
  • The Nectarine update is due to be deployed to the BlueSteel RC channel on Wednesday, September 9, 2026 providing it encounters no issues during it time with QA.
  • The next update after that is codenamed Olive – details still TBD.

General Updates

  • Rider Linden is still working on a new version of the VSCode plugin.
    • He confirmed that the next update to the Lua Editor viewer (with Linux support) should see it officially become the 26.4 viewer and upped to a beta / RC version (a pre-release version of 26.4 is available on Github, but not that this will have a limited lifespan).
  • Leviathan Linden indicated that game_control is now “done” in terms of current development work:
    • Server-side support has been merged into the upcoming Nectarine simulator update.
    • The viewer-side code is now ready for merging into the main viewer Develop code base, although at the time of the meeting, this had yet to be done.
    • As a result of this, Leviathan plans to “get back to” his other workload – including a fix for the mesh face mismatch issue, the way avatars are now drifting more than should be the case when on a moving surface and the “crouch-drift misfeature” – see my notes from the last Leviathan Office hours for more on these latter issues.
    • Another item Leviathan Linden hopes to address is the Feature Request for llGetRegionWorldMapTile.
  • Monty Linden, speaking on Harold’s behalf on Lua:
    • There has been a Discord discussion on robustness around yielding and other concerns. As a result, Harold has posted a PR to Github, and is seeking feedback / comments.
    • Outside of this, work is focused on trying to find the difficult bits that are still outstanding to give a smooth ride to release, and it is planned to mov up to Luau 0.732.
    • There is currently no new Lua simulator available, although one is in development.
    • This news was followed by a general discussion on Lua issues, experiences with debugging scripts, capturing error information, etc., – please refer to the video.
  • Pepper Linden’s region crossing improvements should be (if not already) seeing a limited deployment to the Snack RC channel on the Main grid (Agni).
    • This sparked a general discussion on region crossings.

General Discussion

Please refer to the video for details on the following:

  • Kyle Linden threw out a request to anyone producing Lua content: if they are willing to share their work with the Marketing team, they may get featured in a Spotlight piece.
  • Leviathan Linden noted that whilst SVG/SVG text on a prim (see this Feature Request as an example) has been much-discussed in meetings, it is not something LL senior management is not particularly seized with.
  • The request was (yet again) made for larger region sizes – there are no plans for any such work to be undertaken for the foreseeable future.
  • A general discussion on programming languages which – outside of Lua /LSL had no major relevance on SL.

Date of Next Meetings

  • Leviathan Linden: Tuesday, September 8, 2026.
  • Formal SUG meeting: Tuesday, September 15, 2026.

2026 week #35: SL CCUG meeting summary

Hippotropolis Campsite: venue for CCUG meetings
The following notes were taken from:

  • My chat log and audio recording  of the Content Creation User Group (CCUG) meeting of Thursday, August 27, 2026.
  • Please note that this is not a full transcript of the meeting but a summary of key topics.
Table of Contents

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.
  • Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

General Viewer Notes

  • 26.3, as the default viewer has a  “pretty good” low crash rate.
  • It is hoped that the 26.4 Lua Editor viewer with Linux support will be moving to beta/RC status “pretty soon” – a beta/RC version is currently with QA for testing.
    • The idea being to have this available as server-side Lua support is made available on the Main (Agni) grid.
    • LL is actively building Linux versions of all viewer (alpha/project and beta/RC) moving forward.
    • There is still some back-end work to complete for Linux support (e.g. updating the viewer download pages (main and Alternative, etc.), to reflect the availability of Linux and to have the relevant URLs, etc.).
  • Work has resumed on the Graphics Care Package (GCP) viewer, with the focus on bug fixes and cleaning-up regressions. This latter work includes clean-up issues around mirrors, with some long-standing mirror-related bugs also to be worked on.
    • There is further clean-up work to be done in general before a alpha/Project version of the GCP viewer appears with an official version number.
    • An alpha version of GCP will not mean it is feature complete; further updates, etc., will be made whilst it is soaking as a alpha/Project viewer, the release being to allow those who wish to to try the viewer and provide feedback.
  • One element under review with regards to inclusions in GCP (and Second Life as a whole) is materials Transmission.
    • One potential use for this would be to give any in-world surface the cosmetic appearance of water which could be “seen” as such through the appropriate scripting support  – e.g. volume detect, or this Feature Request to get the face details of an in-world object.
      • Note this is not about giving surfaces / prims the same properties as Linden Water – that is a far more complex ask.
    • Transmission had been promised in the past, but there are concerns over impact performance, so its inclusion in SL is still under internal review and testing. If the impact is too greater for many systems, it is unlikely to be implemented; if its impact can be moderated through the use of a toggle in the viewer, then it might be considered.

General Discussions

  • With regards to Linden Water:
    • We currently have water exclusions surfaces (objects which can “hide” areas of Linden Water when looking on it from above. This is useful for things like keeping Linden Water out of the hulls of boats, etc., when viewed from above, but if the camera moves below the surface, the visual effects of Linden Water (hazing, etc.) will still be apparent.
    • Given this, there has been a long-standing request for water exclusion volumes which would completely hide Linden Water howsoever the volume is viewed from within (above, below, etc.).
    • Whilst LL is aware of this, the development of water exclusion volumes is not currently being targeted.
  • The PBR “terrain painting” project Cosmic Linden was once working on, circa 2023/24 remains “on the shelf” for now.
    • This led to a general discussion as to what form this project would take if it were to be re-started (e.g. supporting permissions, limits to use (e.g. supported at parcel level, or limited to region level), etc.
    • However, as these discussion were mostly theoretical at this point, and it is unclear if current priorities, etc., would allow for the project to be dusted-off and restarted. As such, all such discussions were largely academic at this point.
  • There was a question on improving sound quality in SL (e.g. higher bitrate sampling, etc.). Currently, there is not work in the pipeline for this due to other priorities.
    • This led to a general discussion on sounds and Voice in SL – matters of attenuation, roll-off (or lack thereof), as well as general sound quality, all of which was user-led with little linden input / feedback.
  • Maxwell Graf demonstrated a viewer-side project he has been working on for functional water caustics using EEP lighting / settings together with a projector with a frame-based animation with a negative cut-out to shine the light through it (+ objects to create volume).
    • He noted that scaling the idea beyond anything like fish tank or pond could be problematic, although the process does not require any scripted update mechanism, it is purely based on the animation playback and interaction with the appropriate EEP lighting.

Next Meeting

2026 week #35: SUG Leviathan Hour: game_control / region crossings

The Simulator User Group meeting place at Longfellow

The following notes were taken from the Tuesday, August 15, 2026 Simulator User Group (SUG) off-week meeting (the “Leviathan Office 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. No video this week, as Pantera is on vacation.

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 “Leviathan Office 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 News

  • On Tuesday, August 25, 2026, the SLS Main channel was restarted without update.
  • On Wednesday, August 26, 2026, the RC channels will likely be restarted without any deployment.

Game_Control

  • Leviathan Linden is “almost done” with a revamp of game-control.
  • A pull request has been cut to the server updates, and the hope is that this will be added to the upcoming Nectarine server update. This will likely include a new UDP message for game_control so that all simulators will be aware of it before the viewer-side code is released.
  • The viewer updates should similarly be going into the viewer Develop repository in the near future.
  • Leviathan is changing how game_control event is accessed for scripts: scripts now need to llRequestPermissions(PERMISSION_GAME_CONTROL) to get game_control events, similar to how control events work.
    • He also noted that with this change, attachments and seats permission requests will be auto-accepted (the scripts will need to ask for the permissions, but no pop-up will show on the viewer for those objects).
    • The main benefit of this latter change  is it will be possible to remote-control objects with game-control input (but disconnected objects will cause the pop-up, and it will have to be accepted manually).
    • It was noted that this change might have to be included in the llRequestExperiencePermissions() protocol.
    • These changes are not currently live on any simulator.

Region Crossings

  • Pepper Linden’s work on improving region crossings should be seeing a limited deployment to the Main grid via the Snack RC channel, most likely alongside the upcoming deployment of the Nectarine simulator update is deployed to the other RC channels.
  • This test deployment is the result of concerns that the updates might result in a need for a roll-back should they might impact other region crossing changes which have been made.
  • If Pepper’s updates work on Snack without any roll-back, then a broader deployment to RC channels can be considered.
  • More information on this will be provided at the next Simulator User Group meeting on Tuesday, September 1, 2026.

Avatar Movement

  • Leviathan has been working on Avatar movement, one outcome of which has been the “breakage” of the ability to “crouch-slide” (crouching and then tapping the forward/rotate keys to cause an avatar to couch and slide along the ground).
    • He notes he is sympathetic to the complaints this has caused (presumably primarily from within the combat community), and indicated he is going to revisit the changes.
  • Alongside of this has been reports that avatars are sliding a lot more when on a moving surface than used to be the case. This might also be related to Leviathan’s updates, so he will be looking at this issue as well.
  • A general discussion on holding down the spacebar being used to slow an avatar being bump-pushed caused Leviathan to mention he would like to find a mans to enable an avatar “slow walk”
    • The use of spacebar to slow an avatar being bump-pushed only works if the keyboard is not prioritised for text input rather than also being used for movement (e.g. using the WASD keys for movement); it also sees the avatar appearing to “walk” at a normal pace whilst being pushed.
    • It was noted at if a “slow walk” option was introduced, it would be useful to a) have a means of varying an avatar’s walking speed based on factors (e.g. avatar height), and b) have walking speed accessible to scripted control.
    • Leviathan acknowledged both of these point but if he is able to work on the idea, the initial focus would be on developing an option for a slow walking pace, noting that this would be useful for game_control, given this currently uses the existing locomotion graph.

General Discussion

  • No updates on issues such as the mesh face count mismatch, new LSL commands, network improvements, etc.
  • The multiple issues experienced on Sunday, August 23, 2026 appear to have been related to a significant database outage.

Meetings

  • Formal SUG meeting: Tuesday, September 1, 2026.
  • Leviathan Linden: Tuesday, September 8, 2026.

2026 week #34: SL Open Source UG Summary

Hippotropolis Theatre: home of the OSD/TPVD meeting
The following notes were taken from:

  • My chat log of the Open-Source User Group (OSUG) meeting held on Friday, August 21, 2026, together with my chat log of that meeting.
  • No video this week as Pantera is on vacation.
Table of Contents

Meeting Purpose

  • The Open Source User Group (OSUG) meeting is an 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  26.3.0.31203661088, August 10, promoted August 17 – quality of life improvements; performance improvements; bug fixes – NEW.
  • Second Life Lua Editor Alpha viewer 26.3.0.32302693173, August 21 – NEW.

Viewer Notes

  • The Lua Editor viewer is now classified the 26.4 viewer in the release pipeline.
    • The Project / alpha version of this viewer was updated on August 21, 2026.
    • This viewer will be the first official viewer-in-flight will see the return of Linux support for the official viewer.
  • A caveat with Linux was given that LL will “be giving the Linux viewer as much QA love as Mac and Windows”.
  • Graphics Care Package:
    • Geenz has been bug fixing but still has “some work to do on getting mirrors into a good place”, particular around avatar rendering in mirrors.
    • Screen Space Reflections (SSR) also have some further updates, with some enhancements to transparent SSR.
    • The plan remains for the GCP viewer to remain a Project / alpha viewer for some time once available to allow for feedback. 

Other Items

  • Game_control: Leviathan Linden has been engaged in other simulator work, so no further moves on this work, simulator or viewer, for reporting at this meeting.
  • Roxie Linden noted that “Some good work on evaluating models for transcription is still going on”.
  • Transparent Media on a Prim (MOAP) – the ability to have parts of a MoaP surface be transparent rather than the whole thing – this is still sitting with LL’s internal processes, so no updates in terms of security updates, etc.
    • However, there is a possibility this work could be included in the 26.4 GCP viewer; this appears to be dependent on resources and  – particularly – performance impact (so even if shipped, it might be disabled by default).
  • Callum Linden is working on Chrome Embedded Framework (CEF) updates.
    • There was a general discussion on CEF and its associated Dullahan process – particularly the number spawned by the viewer (which can be a lot due to the nature of CEF) and reports that not all Dullahan process may be getting killed / culled when the viewer no longer needs them / has been closed.
  • There was a general discussion on SSR and rendering  which got into the long grass over approaches, options and performance. In short, Geenz is trying to enhance performance for a more general use of SSR (many have used it primarily to improve the look of Linden Water, although the moiré effect introduced with PBR rendering has tended to reduce this use in recent viewers).

Next Meeting

2026 week #34: SUG meeting summary

The Simulator User Group meeting place at Longfellow

The following notes were taken from the Tuesday, August 18, 2026 Simulator User Group (SUG) meeting. These notes form a summary of the items discussed, and are not intended to be a full transcript. No video for this meeting – Pantera is on vacation.

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 “Leviathan Office 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

  • No deployments this week, but all simhosts will be restarted.

General Updates

  • Rider Linden is focused on the next version of the VSCode plugin (for which he’s asked for anyone willing to help document to contact him)  and a further update to the Lua editor viewer.
  • Leviathan Linden has been focused on anti-griefing / crash mitigation work.
  • Monty Linden is hoping to get back to his work on EventQueueGet.
  • Kyle Linden repeated his call for those wishing to help edit the SL Wiki to contact him.
  • Harold Linden (Lua):
    • Is working on migrating most of the Luau-specific interruption and script serialization logic from the closed server repo to the SLua repo.
    • Is also , taking the time to re-engineer things in a way that makes script bytecode-sharing and improving our garbage collection strategy easier.
    • Hopes this work will make individual server releases less bound to particular SLua repo versions by moving the “hairy” parts of the integration to SLua itself, so keeping a nice interface.
    • Those who want to do benchmarking / local running of scripts will find this work “extremely useful since you’ll be able to implement a runtime environment that’s much closer to how your scripts actually run on the server”.
    • Once this work is done, Harold plans to cut a new Lua simulator release.
    • Simulators running the Lua code are still “remarkably stable”.
  • Pepper Linden continues to work on some region crossing code, and the hope is to move their work forward as a project simulator, and progressing it through the release mechanism.

General Discussion

  • The subject of a scripted means to toggle Animesh objects on/ off and enabling attachments on Animesh objects raised at the previous CCUG meeting was raised here, as requested at that meeting.
    • This included referencing New LSL llAnimeshEnabled(integer enabled); Toggle Animesh Property on/off.
    • Rider Linden indicated he was broadly in favour of the approach – with the caveat that care would have to be taken if how it works due to concerns of object return if enabling one or more Animesh objects via script (thus increasing their Land Impact by around 16) could trigger parcel object return.
    • The suggestion was to have a switch in the function so that if enabling an Animesh object (and thus increasing its LI) which would cause any start-up of an Animesh object to fail if the change in LI risked triggering object return.
  • The above triggered a discussion on the additional LI penalty on Animesh and its need & validity, together with the ordering object return.
    • There was some confusion on the subject of attachments – with it initially being mistaken for avatars being able to wear Animesh attachments (which is supported) and the request for Animesh objects supporting their own attachments via their skeletons.
    • The latter was proposed for “Animesh 2.0” (aka Project Muscadene) which also promised body shape and  physics support for Animesh, but this died before fully implemented when attention turned to updating Avatar complexity  / Land Impact calculations – which also subsequently died.
    • The discussion on object return related to exceeding a parcel’s Land Capacity. Currently the last object(s) rezzed will be returned if the limit it exceeded. However, if the limit is broken whilst editing an object (because it crosses between accounting models and it’s LI increases), then there is an argument to say it is the object being edited which should be returned, not the last item(s) rezzed.
    • These discussions continued through most of the rest of the meeting with no firm decisions made.
  • Folded into part of this was a question on synchronising inventory on Aditi (the beta grid) and the Main grid. This should be a matter of logging-in to Aditi and then waiting for the next automated synchronising process, run (IIRC) at around 02:00 SLT each day.
  • There was also a general discussion on scripting which, given I’m not scripter, I’m not even going to attempt to translate!

Date of Next Meetings

  • Leviathan Linden: Tuesday, August 25, 2026.
  • Formal SUG meeting: Tuesday, September 1, 2026.

2026 week #33: SL CCUG meeting summary

Hippotropolis Campsite: venue for CCUG meetings
The following notes were taken from:

  • My chat log and audio recording  of the Content Creation User Group (CCUG) meeting of Thursday, August 13, 2026.
  • Please note that this is not a full transcript of the meeting but a summary of key topics.
Table of Contents

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.
  • Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

General Viewer Notes

    • The 26.3 RC/ Beta was updated at the start of the week, and looks set for promotion to release status in week #34 (commencing Monday, August 1, 2026). As a maintenance / bug fix update, this includes a number of WebRTC fixes.
    • Linux support: LL is currently merging Linux “across the board”, and this should see Linux support in the Develop branch, so that it is a part of all future viewer builds.
    • This has meant the the resumption of work on the Graphics Care Package (GCP) viewer with the fixes and improvements around PBR and correcting issues within it as far as possible was slightly delayed – but it will now include a Linux build.
      • There are still a number of bugs to be addressed prior to GCP reaching a project / Alpha release, and once it is listed on the Alternate Viewer page as such, it will remain in soak for an extended period to allow feedback to be gathered.
      • The issuing of the GCP viewer will mark the first step in the graphics pipeline modernisation work which has been raised at both CCUG and Open Source Development meetings, but as a first step, the changes should be transparent to most people.
    • There will be a further project / Alpha update to the Lua Editor viewer, prior to that progressing to RC / Beta, most likely as viewer 26.4.

Mesh and LODs

  • Level of detail (LOD) is a technique used in computer graphics to optimize rendering by reducing the complexity of 3D models as they move further away from the camera so as to improve overall performance while maintaining visual quality. As a very basic description, this is achieved by “swapping” highly detailed (high polygon) models for models with a lower level of detail (fewer polygons) as the viewing position (camera) moves away.
  • For various reasons (cost, complexity, land impact, ease of defeat, etc.), LOD optimisation within Second Life has been something of a contentious issue – with a core part of this being the automatic LOD generation capability within the viewer can easily be defeated / even when used, produces generally bad results.
  • With a focus now turning towards improving the use of mesh in Second Life, Geenz noted that the issues of LODs is one that could perhaps be addressed. He suggested one of three particular approaches:
    • A drag-and-drop capability that allows a model sans LODs to be dropped into it, and without further prompting, the LODs are automatically generated.
    • A similar capability, but where the model and its associated LODs are dropped into it – but if the LODs do not achieve certain metrics, new LODs are automatically generated in place of them; or
    • The current approach is continued, with all of its issues (including creators including n/cards telling users to ramp-up rendering in their viewer to “see a product at its best” because no LODs are supplied / to defeat camera distance decimation (and hurt viewer performance).
  • Given the emergence of greatly improved LOD generation tools such as Mesh Optimiser, Geenz is currently leaning towards the middle of these three options, as it a) allows creators to generate their own LODs; b) ensures that everything is metrics based: if the generated LODs meet the required metric, they are used;  if not auto LODs are generated to meet the criteria and are used instead.
  •  IF such an approach were to be taken, it was acknowledged that consideration would have to be given to potential impact, including whether or not the new LOD system would retroactively apply to content already uploaded or not; the risk of new LODs causing higher Land Impact, resulting in objects being returned, etc.
  • The use of an auto LOD generation tool did receive some positive feedback.
  • This is however, just an initial discussion, not a statement of intent – feedback is being sought and content creators are encouraged to offer such through the usual channels (e.g. Discord) and via future CCUG meetings.

General Discussions

  • Script toggle for Animesh:
    • A request was made for a scripted capability for toggling the state of an Animesh object “on/off” automatically or manually.
    • A number of reasons for this were put forward from simplifying the update process for Animesh objects through to reducing simulator resource use.
    • The request appears similar to this one: New LSL llAnimeshEnabled(integer enabled); Toggle Animesh Property on/off, and it was suggested the requestor review that Canny for applicability & also raise the subject at the Simulator User Group meetings.
  • The above re-opened the topic of enabling wearables / attachments on Animesh objects; this had been something that might be developed under “Animesh 2.0”, after the original release of Animesh in Second Life.
    • However, that project largely got put on hold due to other priorities taking precedent – such as the announced, then much delayed and ultimately stalled and shelved project(s) to re-visit land impact costs, avatar rendering costs, etc.
    • Geenz has suggested he’ll look internally for information on “Animesh 2.0” and the reasons why it was held over and then then left.
    • Also suggested was the idea that rather than trying to address specific Animesh updates, it might be better to pursue a more structured approach to attachment hierarchies and the support of custom skeletons, as doing so would allow for a more broader set of use-cases to be met – although achieve a full system of hierarchal support on the server-side would not be straightforward.
  • A general discussion on the reasons behind working towards custom skeletons / rigs, attachment hierarchies etc., and the potential benefits of supporting custom skeletons / rigs and the complexities of maintaining a given level of continued support for older capabilities under the expectation that any changes made will not prevent older approaches (in this case the current avatar skeletal rig) from working.
  • In terms of mesh improvements, Geenz broke down what is being considered into three project areas:
    • Building-out the foundations in terms of glTF 2.0 specification support – with controls to ensure a consistent approach to data, etc.
    • Support for blend shapes, building off of the current under-the-hood blend shape support. Feedback was requested on what content creators would like to see with blend shape support (e.g. having blend shapes addressable via LSL / Lua).  Again, feedback welcomed via meetings and channels such as Discord.
    • Support for custom rigs.
  • Note: at this point, my recording software decided to disconnect from SL, as as I was AFK, I failed to notice it had, and so have no contextual audio for the last 20 minutes of the meeting, hence ending this summary here.

Next Meeting