2026 week #26: SL Open Source meeting

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

  • My chat log of the Open-Source Developer (OSD) meeting held on Friday, June 26th, 2026, together with my chat log of that meeting.
  • Pantera’s video of the meeting (embedded at the end of this article) – my thanks to her for providing it.
Table of Contents

Meeting Purpose

  • The OSD meeting is a combining of the former Third Party Viewer Developer meeting and the Open Source Development meeting. 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: Flat UI – 26.2.0.25386466510,  -“flat” UI and font update, dated May.
  • Second Life Project Viewers – Lua Editor Alpha viewer 6.1.0.23768336784, April 29.

Viewer Notes

  • 26.3 is still slated to be the next viewer to be issues, but when is currently TBD.
  • Lua (with Linux support) will be the next viewer after 26.3.
  • The next major update after Lua is likely to be vcpkg (under-the-hood viewer packaging), but this is probably going to be late summer before this surfaces.
  • Some upcoming viewer-side WebRTC updates:
    • libwebrtc is to be updated to m144
    • The issue with p2p/adhoc/conference calls dropping when opening Voice Preferences is getting a fix.
    • (Also, on the back-end, the WebRTC Voice-to-text experimentation is continuing.).
  • Geenz Linden is working on a pipeline split in the background that should make getting off of OpenGL generally easier. This won’t move the needle over night, and thus far is mostly code clean-up.

OpenGL, Vulkan

  • The majority of the meeting was a discussion on succeeding OpenGL, with a focus on Vulkan.
  • Geenz noted:
    • There are “a few plans brewing for Vulkan/Metal/D3D12 support”. For MacOS a rendering hardware interface (RHI) to target Metal.
    • Broadly speaking, there does not appear to be anything “super high risk under Vulkan”, but the Lab still needs to approach things with care.
    • Based on available stats, the number of people using “pre-Vulkan” hardware is no longer extensive & the viewer also logs the number of people using systems capable of Vulkan support.
    • However, the problem is not so much who can / is using Vulkan, but rather how up-to-date are people’s drivers and, “are there any landmines lurking in that specific driver/hardware combo” because SL still has to support hardware that doesn’t get driver updates, etc.
    • The work he did for masked water in things like boat hulls should be relatively easy to port.
  • One of the major questions with Vulkan support will be can users’ hardware support modern Vulkan extension (such as bindless, which is liable to be a major optimisation for SL if it goes the Vulkan route).
  • In terms of the general plan for switching APIs away from OpenGL, Geenz noted:
Right now the plan is vaguely shaped as: split out LLPipeline and related components (including the draw pools), setup a general interface for the viewer “core” to talk to “a renderer”, amber the OpenGL renderer beyond minor development as our “classic” renderer, and have a separate renderer that at first will be off by default until we’re confident we’ve taken care of everyone’s bugs sufficiently. The devil is in the details of course, but generally we want to avoid another PBR-shaped release where we’re having to speed towards shoving everyone onto something that needed more feedback before it released. So, people get a choice for a while with the target for the new stuff being “similar+”
  • So short term at least people with be able to switch between renderers, where “short term” is likely measured in years.
  • The chances are as LL gain confidence in different set-ups they will start enabling it by default for certain detected hardware.
  • Concern was raised that a switch-over could result in a “ALM moment” (ALM=Advanced Lighting Model) where peopl didn’t use the renderer because of the way it changed the appearance of scenes. However, the changing of APIs / providing different rendering APIs shouldn’t be such as issue, as scenes should look pretty much the same either way.

Other Items

  • The question of gathering region data for the purposes of producing things like 3D terrain maps was again raised. This has been passed around the majority of User Group meetings in a attempt to understand any limitations on the use of bots for this purpose. Ideally, the data would come directly from LL; however Geenz noted that LL cannot provide the data in its raw form, but it might be possible to get height / elevation data into the Map service.

Next Meeting

2026 week #24: SL Open Source meeting

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

  • My chat log of the Open-Source Developer (OSD) meeting held on Friday, June 12th, 2026, together with my chat log of that meeting.
  • Pantera’s video of the meeting (embedded at the end of this article) – my thanks to her for providing it.
Table of Contents

Meeting Purpose

  • The OSD meeting is a combining of the former Third Party Viewer Developer meeting and the Open Source Development meeting. 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: Flat UI – 26.2.0.25386466510,  -“flat” UI and font update, dated May.
  • Second Life Project Viewers – Lua Editor Alpha viewer 6.1.0.23768336784, April 29.

Viewer Notes

  • 26.3 is still slated to be the upcoming performance viewer, but people are currently spread out on some other priorities such as the new compositor work which will hopefully pave the way for XUI moving onto its own thread.
  • Currently, the Lua editor is getting reworked into a “sooner rather than later release”, which means a Linux flavour of the official viewer will finally get released.
  • The next major update (after Lua?) is probably going to be vcpkg (under-the-hood viewer packaging), but this is probably going to be late summer before this surfaces.
  • The Graphics Care Package (GCP) viewer is now anticipated as not happening “for the next few months”.
  • Overall, LL is working on refining the release train and figuring out what is to move forward, with Geenz Linden noting:
We’re trying to be a bit more flexible with our releases, and we’re having a ton of internal discussions about how we want to move forward with things like feature releases. So we might have something split those up along the way, we’ll see.

Other Items

  • Roxie Linden noted:
    • That there are some WebRTC Voice fixes on the current simulator RC version.
    • There are some potential CEF/Dullahan improvements in the wings.
    • There are some server-side solutions for Voice-to-text transcription being evaluated.
  • There are reports that changes to MapBlockRequest blocks limit (so it only accepts requests for up to 64 blocks on the current simulator RC release, when it used to accept up to 256 block requests) has broken the World Map in some viewers.
    • This is currently being discussed internally, and there may be more news on this by the time of the next Server Group Meeting (if not before then).
  • There was a general discussion on which Linux distro will be used for the official Linux viewer, the favoured approach currently being “something Arch based”.
  • A general discussion on scripting, notably around the availability of Lua scripting in viewers + back-end compilation, and which bumped into Mono and LSL scripting, ran through the second half of the meeting – please refer to the video.
  • A concern was raised over Firestorm’s introduction of an option to disable the masking of URLs in the viewer, and how it could break some content. The general feedback from the Lab is that the feature exists as a toggle and does not break the shared experience, ergo, they have no problem with it. However, Geenz is happy to raise concerns (both for and against) internally.

Next Meeting

2026 week #22: SL Open Source meeting: Chat Modernisation

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

  • My chat log of the Open-Source Developer (OSD) meeting held on Friday, May 29th, 2026, together with my chat log of that meeting.
  • Pantera’s video of the meeting (embedded at the end of this article) – my thanks to her for providing it.
Table of Contents

Meeting Purpose

  • The OSD meeting is a combining of the former Third Party Viewer Developer meeting and the Open Source Development meeting. 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: Flat UI – 26.2.0.25386466510,  -“flat” UI and font update, dated May.
  • Second Life Project Viewers – Lua Editor Alpha viewer 6.1.0.23768336784, April 29..

Viewer Notes

  • Per the above, 26.2 remains the release viewer.
  • 26.3.0 – performance improvements – work continues on this, but it is not ready to be issued as yet.
  • The order of progress for all other viewers currently available (Lua Editor) or in development (Graphics Care Package; maintenance release) remains fluid.

Chat Modernisation – IM Conversation Histories

We’ve been working on improving text chat, especially as we have moved from a desktop-only to a multi-platform product. We’re making important improvements to how text chat works behind the scenes. One of the biggest changes: We’re improving how conversations are maintained across devices.

– Grumpity Linden, May 29th, 2026

  • The Lab is working to make person-to-person IM chat histories persistent regardless as to how they are accessed – whether switching from one viewer to another or from a viewer to SL Mobile and vice-versa – so that up to the full history of a conversation can remain available, making it easier to pick up conversations wherever you log-in.
  • For clarity:
    • Nearby Chat history is not a part of the work, nor (for the foreseeable future) is Group chat (although this may change at some point).
    • The core functionality of messaging will remain unchanged: how live IMs are sent and received via UDP pathways is not changing.
    • Nearby chat logs will remain available just as they are at present.
    • It is only how (and how much of) IM histories are served to the viewer that is changing.
    • This work is in its early stages, and some of it might change in view of on-going feedback, etc.
  • Under this changes:
    • IM histories will be served encrypted over HTTPs, and the data store will have encryption at rest — allowing your data to stay completely private and secure.
    • For security reasons:
      • Only users opting-in to the Lab’s Multi-factor Authentication (MFA) will be able to access their complete IM histories.
      • Those who remain opted-out of MFA will only be able to see the last few days of chat histories.
      • This is to reduce risks of privacy breaches if a non-MFA account is hacked. Additionally, the number of days back and history fetch will go, will be determined by the server.
  • Partially because of the MFA dependence, LL is intending to expand options for using MFA (e.g. e-mail, SMS, etc.). However, these new options may not be available prior to the new chat history capability going live.
  • During the meeting there were numerous security concerns raised – particularly around store IM histories as Personal Identifying Information under regulatory requirements such as the EU’s GDPR, the degree of access LL might have to IM histories, even if encrypted.
    • Some of these were addressed to a degree (e.g. yes, histories would be deleted along with other PII data in response to a request under GDPR).
    • Some questions passed unanswered, potentially because they may require further internal discussion at LL.
  • As a semi-side note, it was indicated that one potential outcome of the overall Chat Modernisation work is that a some point in the future, it should become possible to have simultaneous log-ins from different devices.
    • So, for example, someone could be logged-in viewer their desktop but need to go AFK from their computer. They could then open SL Mobile on their mobile device and continue to follow a conversation without going through a log-out / log-in situation. They could then switch back from their mobile device to the desktop on their return.

Other Items

  • The legitimate use of bots for grid data gathering was again raised, together with what data may or may not be deemed acceptable for gathering, and guidelines on how such bots should be used in order to avoid sudden bans.
    • Geenz Linden noted that in terms of making aspects of region data available more readily to assist with things like 3D terrain (region) map creation, etc., there is interest in trying to implement an engineering-based ability. However, this is not something actively being developed at this point.
  • A brief discussion towards the end of the meeting on EEP bugs (which are likely to be addressed in viewer 26.3), with a note that PBR Sun / Moon will be part of the GCP viewer.

Next Meeting

2026 week #20: SL Open Source (TPVD) meeting summary

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

  • My chat log of the Open-Source Developer (OSD) meeting held on Friday, May 15th, 2026, together with my chat log of that meeting.
  • Pantera’s video of the meeting (embedded at the end of this article) – my thanks to her for providing it.
Table of Contents

Meeting Purpose

  • The OSD meeting is a combining of the former Third Party Viewer Developer meeting and the Open Source Development meeting. 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  – One-Click Installer – 26.1.1.23806384790 – April 10 – No change.
  • Second Life Release Candidate (RC) viewer: Flat UI – 26.2.0.25386466510, May 15 -“flat” UI and font update – NEW.
  • Second Life Project Viewers – Lua Editor Alpha viewer 6.1.0.23768336784, April 29..

26.2.0 – “Flat UI”

  • A new beta RC was issued on May 14th – see the list above for details.
  • Unless a significant blocker arises, this viewer is likely to be promoted in week #21 (commencing Monday, May 18th, 2026).

26.3.0 – Performance Improvements +

  • 26.3 is still in progress. The new texture streaming updates should be merged already.
  • Work is continuing on getting the async inventory updates included.
  • Geenz Linden is working to get the new material and texture batching work in a good state for it as well.
  • A beta /RC viewer should be appearing on the Alternate Viewers page “soon”.

26.3.1 Maintenance Update

  • The second of the maintenance viewer updates – bug fixes, etc., – is now in preparation.
  • Expect to see this appearing on the Alternate Viewers page “soon” as well.

Graphics Care Package Viewer

  • This is somewhat “on hold” at present, but work will hopefully resume in the near future, as there are a number of bug reports stacking up.
  • There is a reported mirror breakage within the GCP viewer.

Linux Support

  • Linux support in the official viewer is to return with the Lua viewer.
  • LL is targeting the more common Linux systems for support.
  • There is a noted issue with Linux systems without PulseAudio crashing WebRTC versions of the viewer. It has been requested that the WebRTC SDK is fixed to correct this issue, or to provide fallback code PulseAudio to ALSA.
  • It was noted that is a patch or PR was supplied to address this issue, LL would consider it, but LL currently doesn’t have the internal resources to implement a fix themselves.

WebRTC Update

  • As noted in recent user group meeting summaries, WebRTC is now grid-wide and Vivox is effectively retired for Voice. So those using voice on a Vivox-only viewer will now need to update to a WebRTC-capable viewer.
  • WebRTC updates will continue as required, and deployments are carried out separa6tely to the week grind simulator deployment / restarts.
    • Viewers running the latest client-end of WebRTC should not be affected by this, as they they will disconnect from one voice server in the cluster ahead of it going down for update, and automatically reconnect to an operating server in the cluster.
  • In terms of updates, currently the WebRTC team is updating the 3p-webrtc-build branch, and is hoping to look at a code contribution that will enable them to support more recent versions of WebRTC.
  • A patch has also been forwarded to the team to deal with a Linux viewer freeze at shutdown in WebRTC. This also has yet to be looked at.
  • No decision has been taken as to any new capabilities will be added to WebRTC going forward, although voce-to-text transcription (with the potential for multi-language support) remains on the list.
    • There is a lot to be decided on the transcription front: addressing privacy-related concerns, how it is enabled/disabled for people, UX elements, etc.

General Discussion

  • LL is retiring the use of the Opire bounty platform for viewer development code bounties.
    • The major reason for this is that it has led to a spate of bot-generated submissions, many of which are not related to any of bounties, causing headaches in trying to identify valid bounty code submissions.
    • The bounty programme is being re-thought rather than discontinued, and further updates on changes to the bounty programme will be made public once they have been agreed and are available.
  • A discussion on an approach to mirrors for Linden Water, including:
    • A suggestion that 512×512 mirrors could be used to achieve the required results with less VRAM usage.
    • Geenz Linden’s view that mirror probes are currently exposed as a texture array, which needs to be of uniform size, unless bindless, which doesn’t work for Mac OS (until LL moves to a more modern API such as Metal Vulkan). However, he is considering making an exception to the need for the uniform size requirement for a special Water probe type, with its own sampler – although a problem here is the viewer is close to the limit of samplers for Mac OS.
  • Requests have been made to update the official support for CEF to a more recent version. There is an internal project to update CEF / Dullahan within the official viewer.

Next Meeting

2026 week #16: SL Open Source (TPVD) meeting summary

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

  • My chat log of the Open-Source Developer (OSD) meeting held on Friday, April 17th, 2026, together with my chat log of that meeting.
  • Pantera’s video of the meeting (embedded at the end of this article) – my thanks to her for providing it.
Table of Contents

Meeting Purpose

  • The OSD meeting is a combining of the former Third Party Viewer Developer meeting and the Open Source Development meeting. 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  – One-Click Installer = 26.1.1.23806384790 – April 10 – NEW.
  • Second Life Release Candidate (RC) viewer: Flat UI – 26.2.0.24254827122, April 15 -“flat” UI and font update – NEW.
  • Second Life Project Viewers:

26.2.0 – “Flat UI”

  • Now at RC status, per the Above list.
  • More updates to be made to this prior to promotion.
    • LL is working through some font kerning problems that were seemingly made much more obvious with the new font choice.
    • It was also noticed that the official viewer has been rendering fonts ever so slightly different from FS – which kicked off the above investigation.

26.3.0 – Graphics Care Package

  • The is the viewer previously known as the SL Visual Polish (SLVP) viewer.
  • The performance tweak has been ported over, and the team is now looking at additional performance work.
    • Async inventory is being parted out into easier to review chunks.
    • LL is also looking at some CPU and GPU wins overall – Geenz Linden is working on getting texture batching working for the PBR and Blinn-Phong paths. There is potentially more work on these lines, and these will likely be incorporated prior to passing the viewer to QA.

Lua Viewer

  • The Lua Alpha update that it had been hoped would surface around the start of April is now being aimed for some time in week #17.
  • The current lean at the Lab is to move this viewer through to RC status and then release before the 26.3.0 GCP viewer, but no firm decision has been made.
  • Again, this viewer will also be the first new Linux release from LL.
  • As a reminder: LL have officially dropped “SLua” (“SL Lua”) and just going with “Lua”.

WebRTC Deployment

  • The WebRTC deployment is still underway. No firm end-date as yet, although it should now be across all simulator RC channels.
  • Anyone experiencing Voice issues with WebRTC is asked to file a bug report.

General Discussion

  • The vcpkg updates for the viewer build process will not be surfacing until “after Lua at the very least”.
    • Geenz estimates it will likely not emerge until late summer, due to dependencies on work being completed vis. KDU and the removal of the Havok sub-libraries from the viewer.
    • In terms of the latter: VHACD will replace the convex decomposition for mesh upload, and server-generated path-finding mesh will replace the Havok path-finding mesh loaded by the viewer for visualisation.
    • A major reason for removing the Havok sub-licences is the impact they have on TPVs, who have to go through the process of obtaining and signing sub-licence agreements via LL, which complicates the open-source environment.
    • In this respect, if LL had a truly open-source replacement for KDU on the graphics side, they would look to make similar moves there as well.
  • Physics shapes and why and what the viewer can do with them became a topic for conversation at around the half-way point in the meeting, and this continued for around 10 minutes.
  • During the above there was a general discussion on the mesh uploader and clarifying LOD numbers for those coming into mesh creation.
  • A question was asked on interpreting section 8 part of the Unauthorized Uses of Linden Lab’s Trademarks policy – a question perhaps best dealt with via a support Support Ticket.
  • A request was made for TPVs to receive stats reports once more (use, crash rates, etc). Geenz noted in reply:
Some of that is a bit of a black box to us as far as your specific crash rates, as for viewer usage we’re bottlenecked by a single person is responsible for that so it doesn’t always get done. I’ve been hoping to get a more automatic solution for this for a while, but our metrics folks have been booked up with other things for a good bit now.
  • The question was asked about the possibility of viewer-side Lua for building custom UIs to replace some of the HUD systems people use, and whether work on this is still moving forward. Geenz repliedwith:
That’s been on the shelf for a while. Dunno if or when we’re gonna bring that one back – I think what we’d need to really look at bringing that back with a significant amount of interest is gonna be how people would want to use [it]. There’s a lot of criteria that goes into making product level decisions like that, and with the viewer side Lua stuff it was increasingly being looked at something for internal use than something like a content feature.
  • The question was asked if the puppetry project was once and for all “dead”, to which Genenz again replied:
Lots of things were learned from that project, but I wouldn’t say it’s dead necessarily. Just not a priority. There’s a lot of things that would need to happen for puppetry, and I think it’s really increasingly more of a “when we need <x> we’ll work on that part of it” sort of thing. Because like joint streaming is just generally kind of useful, but we don’t have an immediate need for it. But who knows – maybe some day. Hell, if there’s any interest in having a proper poser viewer-side that ticks all of the privacy and consent boxes that might be a potential path. But we’re nowhere near there yet.

Next Meeting

2026 week #14: SL Open Source (TPVD) meeting summary

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

  • My chat log of the Open-Source Developer (OSD) meeting held on Friday, April 3rd, 2026, together with my chat log of that meeting.
  • Pantera’s video of the meeting (embedded at the end of this article) – my thanks to her for providing it.
Table of Contents

Meeting Purpose

  • The OSD meeting is a combining of the former Third Party Viewer Developer meeting and the Open Source Development meeting. 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  – Legacy search; WebRTC improvements; QoL improvements – 26.1.0.22641522367 – March 12.
  • Release Candidate viewer – one-click installer = 26.1.1.23806384790 – March 31 – NEW.
  • Second Life Project Viewers:

Viewer 2026.01.01 – One-Click Installer / Velopack

  • Now available as a RC viewer – see above.
  • This could be promoted as early as week #15, depending on how it performs (crash rates, etc.), over the next few days..

Other Viewers

  • 2026.02 – “Flat” UI and Splash Screen Refresh – this is due to have an Alpha update issued on April 3rd.
  • The Lua Alpha viewer is also due to have an update issued on April 3rd.
    • Note, LL are now officially dropping “SLua” (“SL Lua”) and just going with “Lua”.
Example of the upcoming flat UI. Via: Geenz Linden / Github #4681/2
  • The viewer formerly known as the Second Life Visual Polish viewer (SLVP) is now known as the Second Life  Second Life Graphics Care Package.
    • The hope is to get that into alpha soon – but only after we get the necessary server work done and get some regions up on ADITI.

WebRTC Deployment

  • The WebRTC deployment has hit a “hiccup”.
  • As a result the deployment has slowed, with WebRTC liable to remain only on the RC server channels (Le Tigre, BlueSteel, Magnum, etc.) and covering about14% of the Main grid until the problem is resolved.
  • Anyone experiencing Voice issues with WebRTC is asked to file a bug report.

General Discussion

  • There is an increasing issue of AI driven pull requests.
    • This appears to be a case of people trying to make claims via the bounty programme for code submissions without actually putting any effort into the work.
    • Commenting on the matter, Geenz Linden noted:
If you’re using LLMs to submit pull requests, that’s not an automatic no. However, blatantly vibe coded submissions, submissions that are effectively taking stuff from other viewers without any kind of attribution or permission and so on, and anything that just generally reads as super low effort just to claim a bounty is likely to be closed without comment in a worst case, or otherwise scrutinized in order to ascertain the individual’s understanding of what that code actually does vs. how much is just prompting to see if they can land something. We don’t want to shut down utilizing AI in people’s processes, but certain things are gonna get PRs shut down or scrutinized more heavily. So please keep this in mind.
    • This called into question the value of the bounty programme, with the fair point being made that TPV developers have spent years developing code for their viewers and submitting much of it to LL without any thought of reward other than improving people’s SL experience.
    • Geenz further noted the the bounty programme is due to get reviewed “sooner [rather]than later”, although it is likely “some form” of it will be kept, as it has also led to useful code contributions – such as those for getting the Linux viewer back into the frame (due to surface with the Lua viewer) and the viewer vcpkg work.
    • The suggestion was made that a contract programme – whereby an external coder is contracted to produce work – might be more beneficial than the current bounty programme. Again, this was pretty much the case for Linux and vcpkg.
    • A further suggestion was made to offer general bug / feature request bounties in L$ only – potentially making them less attractive to those trying to bend the system and earn US $ using AI LLMs.
  • The question was asked if Leviathan Linden’s work on server-viewer messaging would be surfacing in one (or an) Alpha viewer soon – the reply was that discussions on where and when to place this work are still ongoing, in order to ensure the viewer work and server work appear pretty much together.
  • Suzanna’s excellent write-up on the latest Lua release gained a further shout-out. On this (again):
    • This release will be deployed to Aditi (the Beta grid) first for testing.
    • It requires all Lua scripts to be recompiled in order to keep working.
  • Tis last 10 minutes of the meeting was spent discussion whether “SLua” should be retained as the name for the Lua project, or if “Lua” was better (certainly more widely recognised) given it is an implementation of Luau.

Next Meeting