Month: October 2025

October 2025 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, September 25th 2025 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.1065 (A) / 0.1.1065 (iOS) – October 20.

Updates:

  • Fixed a bug with object loading
  • Added a new 25m draw distance option (Menu > Settings > General > Max Draw Distance) – default is 40m.
    • There have been some reports of this resetting to the default if 25m is set, and then another application is opened on a device. This is under investigation.
  • Improved framerate on lower-end devices
  • Rendering resolution now adjusted on the fly to keep things running smoothly. The app looks at your framerate over the last 10 seconds and automatically lower or raise resolution to maintain at least 20fps (or 80% of your framerate cap, whichever is higher). You might notice a short dip when loading new areas, but it quickly recovers.
  • Added a new “unloader framework” that decides which items should be temporarily removed if the system runs low on memory. Instead of deleting them, it safely suspends them so they can return once memory becomes available again.
  • A performance index now estimates your device’s power using real-world benchmarks. Default settings—like draw distance (how far you can see) and max avatars (how many avatars are shown) —automatically scale to fit your device’s capabilities.

Performance Updates

[Video: 2:06-5:58]

  • The initial October update (560) caused a performance regression on some Android devices, prompting further releases during the month with a focus on re-upping the performance on “lower-end Android devices” (although this in itself covers a wide spectrum of hardware and devices due to the way various devices might be configured by the manufacturer to prioritise things like battery life).
    • The biggest change in this regard is that the the rendering resolution is based on frame rate when initially loading a scene, the idea again being to speed-up the load time.
    • In addition, and again particularly with Android, changes were made to the number of rendering passes being made, together with some simplification within the shaders to again help boost performance.
    • Android testing indicated that these changes should hopefully see around a 20-25% performance boost for most of the affected hardware, which should help alleviate some of the pain users may have been feeling earlier in the month.
    • Those who did experience performance issues on the earlier October releases for Android are encouraged to try the October 20th release, and see if their issues have been resolved (and if not, to please provide feedback).
  • Additionally, changes have been made to how out-of-memory situations are handled.
    • Previously, if the app showed signs of running out of memory, it would attempt to start deleting content held in memory (but not necessarily seen on-screen) to try to stay ahead of the curve and prevent the entire app from crashing due to running out of memory.
    • However, any such content deleted from cache in this way was essentially “gone”; it could not be reloaded, even if the app had available memory to do so.
    • Changes at the start of October altered this behaviour to enable content to be automatically re-loaded, and this has all been synced-up withing the memory management code to make sure that content is reloaded as soon as there is memory available.

Upcoming Work: Texture Memory Use

[Video: 6:12-9:00]

  • For convenience “and a number of other factors” SL Mobile has been “pretty much” loading textures at one fixed resolution (with the exception of avatar textures). This means that the app does not take into consideration things like the size of an in-world object in order to determine a suitable texture resolution.
  • Work is now in-hand to switch-over to a new texture resolution mechanism which allows textures to be loaded at resolutions based on the surface area of an object (what LL is calling “variable textures”).
  • This also means larger objects will get more texture memory allocated to them, whilst very small objects (e.g. a ring, a button, etc.) will get loaded at the absolute lowest resolution.
  • The overall goal is to allocate available texture memory more efficiently than currently is the case, and allow for adjustments to texture memory to be made on the fly as an avatar / camera moves around a scene, with texture memory use changing as any particularly object gets re-sized larger or smaller within the scene.
  • Work on this has been in progress for the last couple of months, and is now a focus for the next beta release, and will be coming the Alpha version of the Mobile app for wider testing prior to release.
  • It is hoped that by carrying out this work, more memory will be made available for future use – such as
  • supporting PBR materials.

SL Mobile New Starter Experiences

[Video: 12:15-19:48]

  • Already available to those in the SL Mobile alpha programme are four new starter experiences, and soon to be released within the beta versions. Specifically developed in collaboration with various SL creators, these are intended to offer new users coming into SL via the Mobile app with high-quality experiences, intended to be “fast, social, photogenic, and touch-friendly” (that is, interactive).
  • The four experiences are:
    • Scaredycat’s Funhouse (by MadPea) – a gamified experience involving catching little kitties.
    • Midnight Pulse (by Bad Unicorn) – a nightclub-style experience.
    • Chronicles from the Backwaters (by Arcback / Altscape) – a “dark, gritty, interactive novel”.
    • The Mobile Learning Centre (by Second Life Studios) – designed to teach people how to move within and use the Mobile app.
  • These have been built as a result of insight gained during the continued development of SL Mobile (e.g.  because new users are looking for “snackable” experiences within the app to engage them), and have been informed by the manner in which people are using SL Mobile, together within its ouch-based UI, and things like the form factors of various mobile devices, and how people tend to use their mobile devices and apps in general (e.g. taking photos / selfies, creating shareable moments, etc.), and trying to lean into that kind of device usage.
  • New users coming into SL for the first time using SL Mobile will be able to select the experience that most interests them as a part of the join process.
  • Existing users will find the experiences can be accessed via the Lobby.
  • As these experiences become more widely available, the plan is to iterate upon them whilst also monitoring them for how they are used and the kind of metrics they produce in terms of engagement, re-use, popularity, etc.
  • The initial focus of this monitoring will be new user retention over the first 24 hours / first week, then expanding to look at month over month stickiness; if / when people make the move from Mobile to Desktop.
  • Alongside of this will be on-going monitoring of general performance within the different experiences and what improvements can be made to them / to SL Mobile as a whole.

Q&A Session

[Video 21:32-End]

  • Bring the Map to SL Mobile: while the web-based SL maps (maps.secondlife.com) have been made mobile device responsive, they have not been directly added to the SL Mobile app as yet as there is not a lot of utility in doing this at this point in time due to limited functionality within the web-based maps toolset.
  • Memory fragmentation:
    • Some users with multiple accounts (notably subscription accounts) have noticed decreasing SL Mobile loading performance when successively logging-on different accounts (e.g. working through the accounts each day to claim Streaks rewards).
    • This is caused in part by the way current versions of Unity work, which leaves small fragments of memory remaining marked as allocated unless an app is completed cleared from memory (swipe up) after use. These fragments then “break up” the larger pool of memory to eventually leave insufficient amounts of contiguous free memory available for other accounts to use when logging-in, thus increasing their load times.
    • It is believed that Unity 7 will offer a better garbage collector for clearing memory, thus preventing this kind of fragmentation from occurring, and this will become available when the SL Mobile is moved to this version of Unity at some point in the future.
    • For the time being, the easiest way to avoid the issue by those encountering it is to swipe up on logging-out of the app, thus removing it completely from memory, and then re-launching it to log-in on the next account (or, if using other apps at the same time, closing them and swiping up to remove them from memory, so as to prevent them causing fragmentation / using memory SL Mobile might otherwise access).
  • Localisation for SL Mobile in support of non-English speaking users is on the roadmap, but has yet to be scheduled as a tranche of work.

Date of Next Meeting

  • Check the SL Public calendar for details. At the time of writing, no meetings had been schedule for November or December.

2025 week #44: SUG meeting summary

Posted on by Inara Pey

Paradise Of Fantasy, August 2025 – blog post
The following notes were taken from the Tuesday, October 28th, 2025 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

  • On Tuesday, October 28th, the SLS Main channel was restarted without any deployment.
  • On Wednesday, October 29th:
    • The BlueSteel RC channel should be updated with a new simulator update (Imbu). This “has a couple of performance memory fixes in the simulator. It fixes an issue with region names that contain a ‘.”
    • The remaining RC channels will (I believe) be restarted without any update.

SLua Work

  • Harold Linden continues to work on the SLua implementation, focusing on some minor API changes, which he initially defined as: “just tons of lingering issues to file off sharp edges on APIs to make them do what people would reasonably expect.” Later in the meeting, he further expanded on the first of these changes thus:
I was looking to clear up one of the big warts of LSL: “keys” are not strictly UUIDs, they’re strings in disguise. That means the UUIDs that vary only in casing are considered unequal, which is very weird if you’re used to more modern UUID APIs. The only cases where people generally want that behaviour is in llMessageLinked() / ‘link_message()’ so you can pass an extra string as ‘id’, but it causes weird unexpected issues elsewhere. In SLua, I’d like to make ‘UUID()’ return nil if the passed-in string is not a valid UUID, like the existing Lua functions do, and make [the] ‘link_message()’ ID field just a string, because people mostly mash arbitrary strings in there. … All APIs that accept key or string in SLua are implicitly a union of ‘string | UUID’, and that doesn’t change. 
    • This approach was welcomed by the majority of scripters at the meeting.
    • As a part of this discussion, it was suggested that SL could benefit from an improved llMessageScript, such as llMessageScript(scriptname,data), and Harold Linden indicated that something like this is being planned.
  • The other API change Harold is working on is the removal of ‘integer()’, which he views as having been only a temporary requirement, but is now no longer needed as he has “fixed up all the bridges to existing LSL functions to tolerate a Lua number”. As such, he regards it as a nuisance to developers as it is likely to slow scripts and make them hard to optimise, as the Luau optimiser doesn’t know about it.
  • Harold also noted that he is not opposed to “adding stuff” to LSL on SLua (e.g. such as a table type), however, given the amount of foundational work that’s considered a higher priority, this is unlikely to happen soon (if at all).
    • Rider Linden also noted that such work would not be a small task, and as such, nothing is currently on the drawing board as yet.
  • Yardang, one of the SLua regions on Aditi has been down for possibly as long as a week. Rider Linden has requested that anyone testing SLua who notes any if the the associated regions appears to be down to contact him in-world.
  • Rider was engaged in a couple of technical debt projects over the course of the past week but is now now working on the official native VSCode plugin for LSL and SLua once more. The hope is to have this deployed in the upcoming week, although it will need further tweaking when the next version of the SLua project viewer is issued.
  • The first half of the meeting included a general discussion /catch-up on the above and related work, including:
    • The plugin should support linting (check a script for errors without running it) and also downloads the current language definition from the viewer and formats it so Luau-LSP and Selene can use it.
    • Wolfgang Senizen has also produced a VSCode plugin + documentation for use with SLua, although notes this will likely be discontinued when the official plugin is made available, and he will shift to contributing code to that project.
    • A note that LSL/SLua functions cannot be directly called from outside of the simulator (e.g. via a web page), but “in theory” it might be possible to create an RPC (bot) service of some kind to achieve the same.
    • Harold Linden reiterated that LL is working on a new LSL / SLua web portal, which will include documentation and code examples, etc.
  • The latter part of the meeting focused on suggestions for future SLua support, and discussions on the use of JSON / LLSD – please refer to the video for details.

In Brief

  • Harold and Leviathan Linden have been working on fixes for script scheduling (“do with have to do anything for this script / are we allowed to run it?”), and which should reduce script times on a simulator “a reasonable amount”.
  • Additionally, Leviathan Linden is working on fixing more memory leaks within the simulator code, noting that those fixed in the upcoming Imbu release are “small potatoes” compared to what the Lab thinks is out there.
  • Leviathan is also hoping to get back to the game_control work in the the near(ish) future, noting, “I have a link to the Linux viewer branch (which is almost deliverable) and I will be building on top of that”.
  • Given the lateness of the year and the limited time for further simulator updates, it is unlikely there will be further work on region crossings during 2025.

Date of Next Meetings

  • Leviathan Linden: Tuesday, November 4th, 2025.
  • Formal SUG meeting: Tuesday, November 11th, 2025.

† 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.

2025 SL viewer release summaries week #43

Posted on by Inara Pey
Logos representative only and should not be seen as an endorsement / preference / recommendation

Updates from the week through to Sunday, October 26th, 2025

This summary is generally published every Monday, and is a list of SL viewer / client releases (official and TPV) made during the previous week. When reading it, please note:

  • It is based on my Current Viewer Releases Page, a list of all Second Life viewers and clients that are in popular use (and of which I am aware), and which are recognised as adhering to the TPV Policy.
  • This page includes comprehensive links to download pages, blog notes, release notes, etc., as well as links to any / all reviews of specific viewers / clients made within this blog.
  • By its nature, this summary presented here will always be in arrears, please refer to the Current Viewer Release Page for more up-to-date information.
  • Outside of the Official viewer, and as a rule, alpha / beta / nightly or release candidate viewer builds are not included; although on occasions, exceptions might be made.

Official LL Viewers

  • Default viewer 2025.07 7.2.2.18475198968 – Apple Silicon Support – dated October 16 –  No Change.
    • This viewer now ships as a “Universal Binary” that contains both the Intel and Apple Silicon versions of the viewer. It should give performance gains on the Apple Silicon version in particular.
    • Also includes various WebRTC improvements and bug and crash fixes.
    • Known issues:
      • This version does not support convex decomposition for physics meshes with Apple Silicon. This will be hopefully be corrected in a future update or release, possibly with the help of a code contribution.
      • Navigation buttons in the in-viewer browser are no longer present for marketplace and search – these will be restored in a future update.
      • Apple Silicon does not support pathfinding tools.
      • Subtle rendering differences might be noticed on certain configurations and EEP environments.
    • Github Changelog.
  • Second Life Project Lua Editor Alpha (Aditi only), version 7.1.12.14888088240, May 13 –  No Change.

LL Viewer Resources

Third-party Viewers

V7-style

  • Megapahit viewer version – 7.2.2.54709 – October 23 – changelog.

V1-style

Mobile / Other Clients

  • Radegast client version 2.49.488, October 25 – release notes.
  • SL Mobile (Beta) version 2025.1065 (A) / 0.1.1065 (iOS) – October 20.

Additional TPV Resources

Related Links

The Outer Garden’s Lumen Tide in Second Life

Posted on by Inara Pey
The Outer Garden annex **Lumen Tide**, October 2025 – click any image for full size

Just before I took my break from blogging at the start of October 2025, I received a suggestion that I visit the latest chapter of Bisou Dexler’s Outer Garden region builds. While I was able to hop over and grab some photos, I wasn’t at the time able to get an actual blog post written up prior to taking that break.

The Outer Garden is a place I’ve been visiting on a semi-regular basis for over a decade, my first visit being way back in February 2015. As such, I was keen to cover this latest chapter – called The Outer Garden annex **Lumen Tide** – so here, a little belatedly, is my piece.

The Outer Garden annex **Lumen Tide**, October 2025

Occupying a Homestead region, The Outer Garden annex – as the name suggests – is a separate setting to The Outer Garden. It sits as a dreamlike night setting, offered as a love sonnet from Bisou to Aki69. Overhead, a starry sky split by the arc of a Milky Way-like band brings night to the setting, whilst beneath it, an infinite sea sparkles from horizon to horizon, shallow waves washing over the region itself and tickling the feet of visitors as they arrive.

Across this expanse of water lie star-like lanterns, each one glowing with colour and giving the impression it has fallen from the sky overhead. In support of this, smaller versions of these lanterns either hover just above the water, or slowly drop towards it, their gentle descent here and there contrasting with the rapid, bright lines of falling meteors or mixing with the yellow phosphoresce of swirling fireflies (been sure to have particles enabled in your viewer!).

The Outer Garden annex **Lumen Tide**, October 2025

However, the most startling and engaging elements of the setting are perhaps the drifting celestial jellyfish as they swim and float through the air, sometimes vanishing into the water, sometimes rising from it; together with the golden crescent lying just below the surface of the water towards the middle of the region.

At first resembling an underwater sandbar, it is only when one swings the viewer camera up over the setting that the “sandbar” reveals itself to be a crescent Moon, casting its own light up into the setting, adding a further layer of fantastical beauty to the design.

The Outer Garden annex **Lumen Tide**, October 2025

Throughout all of this can be found multiple places to sit and / or dance. The former take the form of little fishing stools sitting over the submerged Moon, through various boats and gondolas scattered over the water, to a bed suspended overhead (and perhaps easily missed if not actively looked for).

Music for the setting appears to be provided via You Tube, but whether it was an issue with my connection or something else, the music refused to play via the Media button. This being the case, I’m including this link to the list in case you visit hand have the same issue, so you can play the tracks in the background when exploring.

The Outer Garden annex **Lumen Tide**, October 2025

As a sonnet to Aki69, further depth is given to The Outer Garden annex by way of most of the elements within the region being creations from Aki69’s store, together with a short poem dedicated to aki69 by Bisou. The latter is offered both through the region’s About Land setting and Bisou’s profile picks:

When stars reach the twilight sky
Life’s wings rise from the water
Wearing fragile phosphorescence, spilling into the air

I forget even my casting
And listen to the wind pause

The moon emerges, night exhales
In that instant, life’s magic ignites
And the world holds its breath

Now, it feels
As if it’s just the two of us in this world.

The Outer Garden annex **Lumen Tide**, October 2025

Peaceful, beautifully created, and with a richness of love and tranquillity, The Outer Garden annex **Lumen Tide** is an ideal place for all romantics to visit.

SLurl Details

Space Sunday: of Artemis 3 and NASA administrators

Posted on by Inara Pey
Artemis Human Landing Systems (HLS): is Blue Origin’s Blue Moon (l) likely to usurp SpaceX’s Starship HLS (r) for Artemis 3? Credit: Blue Origin / SpaceX

What has long been recognised by many who follow the US-led Project Artemis programme to return humans to the Moon now appears to be becoming recognised within the upper echelons of NASA’s management. Namely, that the biggest hold-up to the programme’s primary goal of safely landing a crew on the surface of the Moon and returning them to lunar orbit remains the inability of SpaceX to meet NASA’s – or even its own – time frames and deadlines in the development its Starship-derived Human Landing System (HLS) vehicle.

SpaceX was awarded the contract to develop the initial vehicle intended to deliver crews from cislunar space to the Moon’s South Pole and then return them back to cislunar space over five years ago, in May 2020. At the time, the announcement was controversial for a numbers of reasons:

  • It was both a last-minute entry into the competition to provide NASA with a suitable HLS vehicle, and the most technically complex of the three major proposal which went forward to the final selection process, requiring up to 14 launches of the SpaceX Starship / Superheavy system just to get it to lunar orbit.
The SpaceX HLS system for Artemis 3, comprising an orbital “refuelling depot” (far left) plus multiple Starship tanker launches (centre left) and the Starship HLS itself in order to deliver a 2-person crew launched by SLS / Orion (centre) to / from the surface of the Moon, with Orion returning them to Earth with their fellow Orion crew (right). Note that while only 4 “tanker” launches are shown in this graphic, given current projected Starship payload capacities, the number is more likely to be 8-12 such launches. Credit: SpaceX
  • Despite NASA stating two options for the initial HLS would be selected, only the SpaceX option was carried forward in the so-called “Option A” contract, with NASA providing SpaceX with an initial US $2.89 billion for vehicle development, with both Blue Origin and Dynetics effectively being frozen out.
  • The driving force behind the decision to go exclusively with SpaceX was NASA associate Administrator Kathryn Lueders, who had a long-standing relationship with SpaceX, and who subsequently retired from NASA in 2023 to join SpaceX. Whilst highly speculative in nature, there have been fingers pointed towards this chain of events as being more than coincidental.
  • The decision to go with SpaceX alone for at least the Artemis 3 mission (the first planned crewed landing) was upheld by the US Government Accountability Office (GAO) in July 2021 after both Blue Origin and Dynetics filed complaints about the handling of the contract on NASA’s part. This decision came in spite of NASA’s own Office of Inspector General (OIG) having already reporting that the agency’s own estimates for the development time frame for HLS (four years) was entirely unrealistic, and that due to its complexity the SpaceX HLS approach would potentially result in the most severe of anticipated delays in HLS development, requiring up to 4 additional years of development and testing in order to be flight-ready.
  • In December 2023, a NASA Key Decision Point (KDP) review for Artemis 3, intended to assess whether or not the programme was on course to meet its intended targets, rated SpaceX as having only a 70% of achieving a required uncrewed demonstration test flight of their HLS vehicle (including landing it on the Moon and returning it to lunar orbit) by February 2028, some two years behind the Option A contract goal of flying this mission in mid-2026.

Oddly, both SpaceX and NASA placed part of the blame for the delay to the demonstration test with on-going (at the time) issues with the Orion crew capsule heat shield – even though Orion is an entirely separate vehicle to HLS, and does not form part of the contracted SpaceX HLS demonstration flight.

Further, while SpaceX has pointed to the 30 HLS development milestones it has achieved, these relate to hardware needed for power generation, communications, guidance and navigation, propulsion, life support, and space environments protection, rather than the vehicle as a whole, with some of these milestones either relating purely to the definition of some of this hardware, rather than any form of development and / or integrated testing.

Whilst SpaceX points to having achieved some 30 hardware milestones for its HLS vehicle, several of these milestones refer to system definitions, rather than hardware development, whilst other elements – such as the elevator system required to get the down the 30 metres separating the vehicle’s crew section from the surface of the Moon – has largely been driven by NASA rather than SpaceX. Credit: NASA / SpaceX

By the start of 2024, concerns around SpaceX’s ability to actually deliver on their promises for their HLS vehicle were such that Jim Free, the man then at NASA charged with overseeing the Artemis programme, was openly talking in terms of potentially swapping the Artemis 3 and Artemis 5 missions, the latter intended to be the first use of the Blue Moon HLS system in development by Blue Origin, and which at the time was seen as much further along in its development cycle than the SpaceX system.

Whilst Free has since retired from NASA, the acting administrator for the agency, Sean Duffy, echoed Free’s point of view on October 20th, 2025, indicating that he is now open to reviewing the Artemis 3 HLS contract. In particular, he has also suggested shifting to using Blue Origin’s Blue Moon lander on the basis of growing scepticism that SpaceX will have their HLS system ready for Artemis 3 by 2028/29.

Whilst Artemis 3 remains mired in conflict, Artemis 2, the first crewed mission for the programme using NASA’s Space Launch System (SLS) and Orion, achieved a further milestone on it wat to the launch pad on October 20th, 2025, when the Orion vehicle, encased in its launch shroud and topped by the Launch Abort System, was lowered from a high bay within the Vehicle Assembly Building (VAB) at Kennedy Space Centre, Florida, and mated to its adaptor on the top of the SLS rocket. Artemis 2 is currently expected to launch in March 0r April 2026 on a 10-day mission around the Moon. Credit: NASA

Unsurprisingly in this age of politics by insult, Duffy’s comments were met with childish name-calling on the part of the SpaceX CEO. To be sure, Duffy is perhaps not the best qualified to be leading NASA even on an interim basis (and has made a fair number of gaffes as head of the Department of Transportation); but as per the reasons noted above, there is good reason to question whether SpaceX can meet its obligations for HLS even within the revised times frame for the Artemis 3 mission (which is now looking to a possible 2028 launch).

Nor did the SpaceX CEO limit his scorn to Duffy; in the same string of social media posts he took aim at Blue Origin, claiming the company “has never delivered a payload to orbit, let alone the Moon” (which he later refined to mean “useful payload”). Given that the launch vehicle for Blue Moon – Blue Origin’s New Glenn rocket – both successfully achieved Earth orbit and deployed a payload demonstrator on its maiden flight, both of which Starship has yet to do in a single launch despite (at the time of writing) 11 flights, this critique came over as little more than a petulant outburst than a reasoned defence of Starship HLS.

Following Duffy’s statements – which appear to also be driven in part by concerns over China’s stated aim to place taikonauts on the Moon by 2030 – speculation was rife in some circles as to whether NASA might seek to an alternative to SpaceX and Blue Origin as the Artemis 3 HLS provider. This speculation encapsulated both the idea that NASA might try for a “home-grown” HLS, or bring-in another company – such as Lockheed Martin (which has made no secret of its desire to supply an HLS alongside of its Orion crew vehicle) – to provide a suitable HLS.

However, given the lead-times involved in seriously moving forward with either of these options (which would likely see Artemis 3 pushed back well beyond a 2029), coupled with the costs involved when the Trump Administration is aggressively trying to reduce NASA’s budget, it would seem unlikely that either of these options would be seriously taken-up. As it stands and in the wake of Duffy’s comments, NASA has confirmed that both Blue Origin and SpaceX have been given until October 29th, 2025 to submit “accelerated proposals” for HLS development, but no other proposals for “alternate” HLS vehicles are currently being sought.

Exactly where this will all lead is also open to debate. As does, ironically enough, the overall leadership of NASA. Whilst only appointed Acting Administrator for the agency, Duffy has spent some of his time in the role floating the idea that NASA should be folded into his Department of Transportation. Were this to happen, it would effectively cement his position as the person in overall charge of the agency and its budget – although the idea has already received widespread pushback from the US space industry as a whole. At the same time, the White House has indicated it is possibly going to re-nominate Jared Isaacman for the role of NASA Administrator.

As I reported at the time in this pages, Isaacman was on the verge of being confirmed to the role earlier in 2025, when Trump’s White House abruptly withdrew his name as their nominee following a public spat between Trump and the SpaceX CEO (with whom Isaacman has had a close working relationship for several years), who at the time was coming to the end of his tenure as a “special advisor” to the White House. However, on October 14th, it was revealed that the Trump Administration has again been in talks with Isaacman about a potential resumption of his nomination to lead NASA, which he apparently is still interested in doing.

2025 week #43: SL Open Source User Group meeting summary

Posted on by Inara Pey
Oscarton Forest Park, August 2025 – blog post †

The following notes were taken from my chat transcript + the video recording by Pantera (embedded at the end of this summary) of the Open Source User Group (OSUG) held on Friday, October 24th, 2025. My thanks to Pantera as always for providing it.

Meeting Purpose

  • 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.
  • Dates and times are recorded in the SL Public Calendar, and they are generally conducted in text chat.
  • The notes herein are a summary of topics discussed and are not intended to be a full transcript of the meeting.

Official Viewers

  • Default viewer 2025.07 7.2.2.18475198968 – Apple Silicon Support – dated October 16 –  No Change.
    • This viewer now ships as a “Universal Binary” that contains both the Intel and Apple Silicon versions of the viewer. It should give performance gains on the Apple Silicon version in particular.
    • Also includes various WebRTC improvements and bug and crash fixes.
    • Known issues:
      • This version does not support convex decomposition for physics meshes with Apple Silicon. This will be hopefully be corrected in a future update or release, possibly with the help of a code contribution.
      • Navigation buttons in the in-viewer browser are no longer present for marketplace and search – these will be restored in a future update.
      • Apple Silicon does not support pathfinding tools.
      • Subtle rendering differences might be noticed on certain configurations and EEP environments.
    • Github Changelog.
  • Second Life Project Lua Editor Alpha (Aditi only), version 7.1.12.14888088240, May 13 –  No Change.

Viewer Updates

  • 2025.07 has seen an uptick in crash rates as a result of some WebRTC changes, and LL is working to resolve this. As such, TPVs looking to ship WebRTC / updates are advised to keep an eye on the Develop branch for relevant commits to integrate into their viewers if they would prefer to avoid the 2025.07 issues.
    • As apart of the overall WebRTC project, a server-side update is anticipated as being ready for release in the next 1 to 2 weeks, with fixes for some issues and some new features.
  • Viewer 2025.08 will be a maintenance update with a focus on resolving crash issues, with the hope it may also include some log-in time improvements for those with very large inventories.
  • Work is progressing on a contributed Linux update, details in this Github PR, which LL is hoping to “land” this year.
  • A new SLua project viewer is in the works. This should include Rider Linden’s work on an official native VSCode plugin for LSL and SLua, as noted in my more recent Simulator User Group meeting summaries.

In Brief

Please refer to the video for the following:

  • A general discussion on the viewer UI and making it easier for new users to quickly discover how to mute those using Voice in order to be obnoxious / harass, without necessarily requiring guidance from a mentor / friend on how to do so.
    • The above also broadened into a more general conversation on improving the chat functionality in the viewer in general (e.g. Voice controls + the conversations floater, etc.).
    • Also touched on was the on-going work with Project Zero (viewer in a browser) to reconstruct the viewer UI (or elements thereof) with a HTML/React-style approach – although this is being done without any intent to “break” the existing UI approach within the viewer.
    • As Geenz Linden noted (and the meeting chat demonstrated), views on the viewer UI and things like the conversations / chat floaters (or CHUI – Conversation Hub User Interface, to use the terms employed when the overhaul Viewer 2 chat UI was first introduced back in 2011) tend to be highly subjective when opinions are voiced. As such the suggestion was made to use the Feedback Portal to offer feature requests on what might be done to improve text chat & its UI elements (and Voice chat), and to upvote features thought to be worthwhile.
  • The second half of the meeting included a lot of general discussion on what might be done to “improve” the viewer experience in general, together with a side discussion between Geenz Linden and Henri Beauchamp on the alpha-gamma fix for legacy objects rendering by PBR + improving the appearance of water on PBR rendering.
    • A very short-form summary of these latter two items is to note server-side work is required for the alpha-gamma fix, but is currently stalled, whilst water is awaiting the updates to SSR (screen space reflections), which has yet to be prioritised for a future viewer release.

Next Meeting

† 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 gathering of people every week. They are taken from my list of region visits, with a link to the post for those interested.