We lead Lua scripting implementation for Second Life -- Ask Us Anything!

[u/slhamlet]

EDIT, Nov 12: Thanks everyone for the great questions! Will do another AMA soon-ish as Lua gets closer to official launch in SL!

Hi /lua! We’re Kyle (u/KyleLindenSL), Harold (u/HaroldCindy/) and Hamlet (u/SLHamlet) of Linden Lab, the company which publishes the long-running user-created virtual world Second Life. 

We’re currently updating the platform to run Lua scripts and are excited to see what Lua developers (and Luau creators from Roblox) build with it in SL.

For background, Second Life has been online a bit longer than Roblox and while we have a smaller user base, SL is still a very active virtual world, and has a large ecosystem of community creators who sell their virtual content (fashion, animations, vehicles, games, etc.) as a side hustle or a full-time income. 

Here’s more info about what we’re doing with Lua on 80 Level: https://80.lv/articles/second-life-wants-its-23-year-old-world-to-be-a-modern-game-platform

And a feature breakdown on our site: https://secondlife.com/create#scripting

Lua is now in live beta in SL if you want to check it out. Just need to install SL and teleport here: https://maps.secondlife.com/secondlife/Lua%20Beta%20Landing/121/141/23

We’re hoping Lua will help modernize SL as a UGC platform and grow the economy. 

So if you’re curious… ask us anything! (We’ll be checking this thread over the next few days.)

[u/geekteam6]

What are the biggest differences with running Lua in Second Life vs. other platforms?

[u/HaroldCindy → u/geekteam6]

Great question!

I go into it a little bit in https://www.reddit.com/r/lua/comments/1xryyj5/comment/19se3ief07kf8/, but the short version is that Second Life is a collaboratively-developed world where all script and object state persists across server restarts, or when objects move to a part of the world on another server. Scripting is most commonly done live in-world with an editor built into the Second Life client, though you can also use the VS Code integration. You can script objects live in-world while chatting with your friends. That all comes with a lot of interesting implementation challenges other platforms don't have or don't address.

I spent quite a lot of time making this persistence layer transparent to creators, and scripters don't have to do anything special to take advantage of it. Even very obscure user-visible behavior like iteration order over items in the unsorted key-value portion of a table is preserved when scripted objects move servers. That particular behavior ensures that for looping over a table's contents won't change order unexpectedly and lead to hard-to-diagnose bugs.

Additionally, we needed to be mindful of the fact that scripts run in a multi-author environment, where a fair scheduler tries to make sure all objects get an equal share of the pie. It needs to be difficult for scripters to monopolize the server's memory / CPU. Because it's very easy for scripters to accidentally do something like write a string.find() pattern that takes seconds to complete, it was necessary for me to rewrite a number of the Lua stdlib functions to support yielding mid-function if / when they run out of time, so that the work can be resumed in a later server frame.

This doesn't solve the problem of problematic string.find() patterns, but it makes it a performance problem for that particular script rather than hanging the entire simulation process. The apparent behavior of all these rewritten functions is the same to scripters, it just makes it easier for us to force user-written scripts to play nice in a world shared with others.

The idea is that to scripters, there's very little difference between writing Lua for Second Life versus anything else (minus the SL-specific APIs), and we handle the dirty work of runtime state serialization and fair script runtime scheduling for creators. The integration is pretty lightweight, so you can generally take a library off LuaRocks or what-have-you that supports Luau and just use it as-is, supposing it doesn't use loadstring() or Roblox APIs or something.

[u/dfavefenix]

When do you plan to release the final version of Lua out of beta, and how will it affect Lua in terms of places with 100 players in the same land? Will the maximum number of players per land ever be increased? Thanks!

[u/KyleLindenSL → u/dfavefenix]

I believe that we'll ship Lua when it's ready. Of course we have milestones and aspirational launch dates, but I think the closest I'd come to answering "When?" is early next year. The current Lua Beta is still shaking out bugs and making sure LSL to Luau compiled scripts function accurately. The gains of running LSL scripts in Luau should be very enticing and we predict many people, that have the permissions, will want to recompile their old scripts with Luau for improved performance.

Even while in Beta the community has started teaching each other how to make the jump to Lua and places like Builders Brewery are hosting classes in-world regularly.

I'm optimistic that once wide spread adoption of Lua in Second Life has taken place, those regions nearing the 100 resident limit will see some performance improvements as the simulation has spent fewer frames executing Lua scripts or at the very least more Lua scripts are run per frame.

I would love to see a future where we can have more than 100 residents in a region but It's hard to say when that might happen. Meanwhile though you can put 4 regions next to each other and have a 400 resident party at the intersection of the 4. For the curious we have a 3 x 3 grid of 9 Lua Beta sandbox regions open to everyone who wants to try Lua in Second Life.

[u/0xc0ffea]

Gaming focused platforms offer a broader set of capabilities with fewer (if any) constraints on what can be influenced / penalties for specific function calls.

Currently when planning game projects, Second Life doesn't get a seat at the table and a different syntactical interface alone doesn't address the shortcomings / platform idiosyncrasies.

Is there a roadmap to build out the Second Life offering to be more inline with game development needs and expectations?

[u/KyleLindenSL → u/0xc0ffea]

Hi 0xc0ffea, Second Life is the virtual world that has allowed content creation beyond the scope of just “gaming” and has the rare ability to allow content creators to build in-world, real time and not miss a moment of the social aspects. That sets us apart from other platforms, I think, in a positive way by staying connected.  

If creators want that game development experience we are taking steps in that direction with the VSCode plugin. It will let creators focus on writing code inside a familiar IDE and still let them test and iterate live in Second Life. For those that don’t want to be interrupted while developing, we’ve always had a do not disturb mode. ;)

We have made progress in other areas of the platform too, which have direct benefits towards making game creation in Second Life better. We upgraded much of the scripting supporting Combat over a year ago and just today finished rolling out new region crossing improvements. Among many other use-cases for region crossings, you can now drive, fly, spin, sail … whatever floats your boat …  through our public roadways without disruption, truly taking advantage of this expansive world.  

Since Second Life is one contiguous real time world, this means cross-region game play will now be more reliable than ever. People have often asked “Can you make a bigger region in SL?” and I now ask “If region crossings are seamless, do you need a bigger region?” 

There is always a roadmap, what is on it must contend with many of the other business/platform needs ahead of us each year. For example, I’m turning my attention to improving groups next. 

[u/Snownel → u/KyleLindenSL]

C'mon Kyle, let's be honest here, region crossings are never "seamless" even with the rollout yesterday... to answer your question, yes, a simulator that treats multiple 256x256m regions as one is a critical and oft-requested gamedev option unless you want to waste time trying to figure out how to get scripts to reliably communicate cross-border. And that's assuming all the regions are online and stable.

Driving games, for example, are basically non-starters compared to any other 3D engine unless you either drive around in a tight circle or expect to bounce against a border depending on how long it takes seated avatars to move to the other simulator. This has been a problem for me for well over 15 years now and I haven't been able to get a stable game running as a result. The new crossing improvements improve rubber-banding problems at the expense of messing with your trajectory because the object bounces along the border until it's cleared to cross. That's tolerable for boats and planes, but still pretty rough for road vehicles.

The problem isn't performance, either, it's space - a 1024x1024m region that supports 100 people and 30k prims would be just as performant as a 256x256m one, because the dimensions are arbitrary. I don't see why there is any technical reason a region needs to be 256x256m except for grid layout. Imagine if every chunk in a Minecraft world were hosted on a different AWS host - can you honestly say walking around would be a "seamless" experience?

[u/0xc0ffea → u/KyleLindenSL]

We have made progress in other areas of the platform too, which have direct benefits towards making game creation in Second Life better. We upgraded much of the scripting supporting Combat over a year ago and just today finished rolling out new region crossing improvements. Among many other use-cases for region crossings, you can now drive, fly, spin, sail … whatever floats your boat … through our public roadways without disruption, truly taking advantage of this expansive world.

The scripting side is only half the equation.

Second Life focuses on "the shared experience" rather than the "player experience". Everyone seeing exactly the same comes before the player's personal perspective.

Even simple mechanics like being able to change object visibility on a per player basis are impossible. Such as collectable objects that vanish when collected by one player, but remain for players who haven't.

Case in point, in a multiplayer FPS game, if the player views themselves getting the headshot, that counts.

In Second Life, the client view lags behind actual which only exists on the server. Round trip latency and processing delays robs the player preventing virtually all gaming. It doesn't matter how good the combat scripts are if it's practically impossible to PVP.

Firestorm's ability to draw janky "Avatar Hitboxes" that lead avatar movement (under Dev>Render Metadata>) are mandatory for the few PVP activities present in SL. These are not present in other viewers.

As for region crossings and vehicle use, the experience presented by Second Life is a far cry from what can be found in actual games. Cars not drifting off into the sun following a failed region boundary crossing is the bare minimum. The actual driving experience is excruciating and no amount of script alone can address that.

People have often asked “Can you make a bigger region in SL?” and I now ask “If region crossings are seamless, do you need a bigger region?”

The suggestion being they can now just have more than one region. Sorry, have you seen how much you charge for regions?

The request for a bigger region isn't just about having "moar land". It's about having a larger space operating on the same shared physics process and script engine.

has the rare ability to allow content creators to build in-world, real time and not miss a moment of the social aspects. That sets us apart from other platforms, I think, in a positive way by staying connected.

Second Life's social tooling has been allowed to languish for well over a decade. The primary social contact point is now Discord.

It's really not uncommon for a users second life social graph to be mostly external to second life.

[u/zebragrrl]

It seems like this project has been lingering for years at this point, announced at least as early as summer 2024, and only just now showing up as a 'limited release' on a few isolated regions, with a special viewer.

• Is there a Viewer capable of participating in this live beta that runs on Linux yet? MacOS?

• How big is the team working on this project?

• How many Linden Lab employees are working on this implementation, versus how many external contractors?

• What can users expect going forward as issues inevitably arise?

• Can users expect long term support and revision to functions the way we saw with the Linden Scripting Language? That is to say, will there be sufficient Linden Lab staff 'on the payroll' when unexpected issues arise (as we saw with Mono) and someone needs to go in at a moment's notice and insert a hotfix or throttle to stop an exploit, griefing angle, sim crashing process, permissions exploits, etc?

• What new functions are being added for scripting purposes, outside of traditional LSL commands? What new functionality does Lua bring to SL outside of potential processing speed increases?

[u/KyleLindenSL → u/zebragrrl]

Hi zebragrrl, That’s a great list of questions. Before I dive in, I’d like to acknowledge that it has taken two years to get here and part of the reason is that we are doing the opposite of “go fast and break things”, this update to our scripting systems cannot go wrong. We have too much user generated content to protect. I hope you don’t disagree that playing it safe is the right course of action.

• Yes! We started supporting Lua script editing in Second Life viewer 26.4, which also supports Mac and Linux. It is the default release and my be downloaded here https://releasenotes.secondlife.com/viewer/26.4.0.37384746592.html

• We have a primary contractor HaroldCindy who is a part of this AMA and is supported by the rest of our Server and Viewer team. You’re right that the team has many competing priorities, and this project has many reasons for caution. We’re excited to be at the point where we can engage the broader creator community, because we are so sure that this is a big leap forward. 

• We are blessed to be working closely with scripters in the community who raise all issues early and often, and which we address quickly as we iterate towards gridwide release. 

• Yes, we went into this new Lua endeavor with every intention of supporting its growth with the Luau project upstream and taking in new requests and finally submitting those back to Luau so the projects stay in sync and this is going to be core functionality for SL forevermore. 

• HaroldCindy is eager to tackle your questions about functionality, so look below for the rest!

[u/Eclectika → u/KyleLindenSL]

Don't sweat the 2 years. Mesh, voice and everything else took forever too, so you're in good company. anyway afaik, SL isn't out of beta yet anyway (I think we're into our third decade of waiting for that to happen) so everything is fine. (also, your comment to me has been deleted so can't read it all but hedging with a 'should' is always best practice when talking about code development)

[u/HaroldCindy → u/Eclectika]

That was my comment, it accidentally got removed by the spam filter. The mods put it back https://www.reddit.com/r/lua/comments/1xryyj5/comment/19sg74uz9sobp/

[u/HaroldCindy → u/KyleLindenSL]

u/zebragrrl To follow onto this:

It seems like this project has been lingering for years at this point, announced at least as early as summer 2024

I was working on it much longer before that! Releasing two years from announcement is actually quite a reasonable timeline for this kind of project though, if you look at other virtual worlds who've rewritten their scripting implementations post-launch.

That is to say, will there be sufficient Linden Lab staff 'on the payroll' when unexpected issues arise (as we saw with Mono) and someone needs to go in at a moment's notice and insert a hotfix or throttle to stop an exploit, griefing angle, sim crashing process, permissions exploits, etc?

Short answer: Yes, there will be appropriate staffing.

Long Answer: A big reason why I originally pitched Luau to LL rather than something else was specifically because it would be reasonably maintainable by a small team. Second Life is a platform with very specific and unusual needs from a scripting engine where the scripting is core to the platform, but LL is also not a programming language company, nor do I think it should be one.

Luau (or any other Lua) is the perfect choice for a company in LL's position. Mono is wayyyyyyy more complex than any Lua implementation that I'm aware of, and that complexity isn't something you want to have to "own" as a small team.

What new functions are being added for scripting purposes, outside of traditional LSL commands? What new functionality does Lua bring to SL outside of potential processing speed increases?

The biggest value Lua provides is not necessarily new user-facing functionality, but exposing the existing functionality in a way that's more efficient and doesn't make scripters too depressed to even script. In terms of functionality, LSL already has very rich APIs that Lua will inherit.

But there are certainly many new scripter-facing features. I've been scripting in LSL for 15 years at this point, the biggest "feature" for me is not having to write 50 lines of timer-management code to do basic things.

Scripters now have things like coroutines, closures, a key-value type, recoverable errors, fancy JSON support, tons of stuff. Most of this is table stakes for any modern programming language, so it feels silly to even mention them, but it demonstrates how much LSL was lacking.

Lua makes it much much easier for scripters to go from idea to implementation, and that's something even non-scripters can be happy about.

[u/Eclectika]

so does this mean every LSL script that has survived everything else LL has done to *ahem* improve the user experience is now going to die unless rescripted in Lua?

[u/rob_0 → u/Eclectika]

No according to: https://wiki.secondlife.com/wiki/Lua_FAQ#Can_I_keep_using_LSL?

[u/Eclectika → u/rob_0]

I had to laugh when I read:

'Yep! LSL should work exactly the same as before'

bolding is my emphasis.

Hopefully it will go well.

[u/HaroldCindy → u/Eclectika]

I wrote that, "should" is my favorite word as an engineer, sorry. 😛 Yes, LSL will absolutely work the same as before. Failure to work the same as before is a bug that will be addressed, and I personally address those issues.

If it's reassuring at all, I have maintained LSL tooling for myself for many years, and spent several years collecting all the weird quirks of LSL. I spent a lot of time writing an LSL compiler that could target Lua bytecode specifically so that people who prefer LSL, or need to maintain legacy content would be happy. I care very deeply about keeping existing content working now and into the future.

There's an extensive conformance test suite that ensures our new LSL implementation behave the same as LSL on Mono. The acceptance criteria for the new LSL implementation is 100% "whatever Mono does". Some choice test scripts to see what kind of things we verify and how are float_precision.lsl and lval_to_lval.lsl.

Fun Fact: The first script run on my development region on the SLua VM was an LSL script, and the first proper Lua script wasn't run until a couple months later.

[u/Eclectika → u/HaroldCindy]

I'm sure it will be fine. I seem to remember there were issues where the intro of mono broke stuff but it's so long ago now I can't remember specifics.

Interesting times ahead.

[u/KyleLindenSL → u/Eclectika]

To confirm what has been asserted. Yes, LSL and Lua scripts running side by side even in the same objects. If you are so inclined you can recompile LSL into Lua, there are benefits to do so, like more memory and performance, so as long as you have the permissions to recompile you may.

[u/BismuthManicotti]

So overlooking the elephant in the room on when.

Is this just on the one region or is it on like, the beta builds like LeTigre or BlueSteel?

I prefer to break things as a beta tester on my own home region.

Second, which clients support this?

[u/KyleLindenSL → u/BismuthManicotti]

Hi! The Lua Beta is currently on over 70 regions, some are dev and QA, but many are early adopters helping us beta test on their private regions already. The good news is that you can be a part of that Beta test too. Please submit a Support Case at https://lindenlab.freshdesk.com/support/tickets/new with the ticket type Land & Region > Other Land, then request that your region be moved to the "Luau Channel". Please note that we can only do this for private regions at this time.

Our current Second Life release viewer already supports Lua script editing. You may may download that here: https://releasenotes.secondlife.com/viewer/26.4.0.37384746592.html

[u/BismuthManicotti → u/KyleLindenSL]

Awesome. My housemates and I have a region. I'll request it so I can start breaking things.

[u/AceFrentis]

longtime lsl scripter here, been at it since around 2009. how does link_message work between an lsl script and a lua script in the same linkset, same as before or is there a new way for them to talk? got a pile of old rental and door scripts i dont really wanna touch but id love to write new stuff in lua right next to them

[u/Background-Rock-7737 → u/AceFrentis]

Same as before.

[u/HaroldCindy → u/AceFrentis]

As mentioned, it will work the same as before. The way that I integrated Lua, its external behavior is almost identical to existing LSL scripts. You can link message between LSL and Lua, reset scripts with LSL commands, use things like `llRemoteLoadScriptPin` to load an LSL or Lua script into a remote object, etc.

SL has 2 decades worth of LSL content, and being able to integrate Lua scripts with existing content is an explicit goal.

[u/bogdanelcs]

Is it stock Luau, or modified? And how are you budgeting memory and CPU per script now that Lua scripts aren’t squeezed into LSL’s tiny limits?

[u/HaroldCindy → u/bogdanelcs]

It's a modified Luau called SLua. Most of the modifications are related to runtime state serializability, runtime and memory limits for scripts. There's also a handful of modifications to make certain library functions (table.find, string.gsub, etc) yieldable mid-execution. Those tiny limits still exist (though they're related a little), Lua is just more efficient within those tiny budgets than Mono was.

For users, it's basically the same as Luau, but for embedders there's a lot of tooling to set strict limits for scripts and to allow their state to persist across server restarts.

[u/Fit-Vehicle8964]

why did you chose Lua? or more specifically, Roblox' Luau?

[u/KyleLindenSL → u/Fit-Vehicle8964]

Great question, we actually put a lot of thought into what scripting language we would go with next. We have 20+ years of content that needs to keep running while we introduce something better, faster and stronger. We looked at several options and honestly let a feature matrix help us make that decision based on our needs. We needed a VM that was battle tested that could run side by side with LSL and that LSL could be compiled into. Luau was the VM that ticked all the boxes. We even made that decision transparent on a FAQ. https://wiki.secondlife.com/wiki/Lua_FAQ#Okay,_but_seriously,_why_Lua_specifically?_Because_it's_popular_for_games?_Because_%3Cother_platform%3E_uses_it?_Why_not_%3CX%3E?

[u/HaroldCindy → u/KyleLindenSL]

To add more detail to this, the content creation flow in Second Life imposes a lot of different requirements that most other users of a scripting engine would not need, and these were easiest to implement with Lua (specifically Luau). Unlike Roblox or most other UGC platforms, scripting is done live in-world, there is no separate editor interface. Additionally, users are generally allowed to write scripts that run on their own avatar's "attachments" that continue to run in others' worlds.

Scripts in Second Life have also historically supported objects roaming across world instances without any explicit (de)serialization step for script state. When a scripted object crosses a region border, scripts have their runtime state transparently wound up by the server, and it is shipped to the new region. The receiving region deserializes the script runtime state, and execution continues as if nothing happened (at least, that's the intent!)

This means that we need a scripting runtime that allows lightweight sandboxing (to prevent users messing with each others' scripts or the world itself), is able to prevent resource abuse (via memory limits and script runtime limits that inject yields when a script runs too long) and that uses a language creators like. The ability to transparently transfer script state across is something I've only seen in a handful of Minecraft mods and Second Life's existing scripting system, so a scripting engine that would be flexible enough to implement this was needed.

As you can see from the matrix in the above linked FAQ, Luau was the only one that really satisfied all of those constraints. Having been working with Luau for 3 years at this point, I can confidently say that Luau was the right choice. I had done some OpenResty work in the past, but I gained a lot of appreciation for Lua's elegance, particularly metatables and their associated VM implementation simplicity throughout this project.

If you're part of a small team with a product where user scripting is integral to the experience, Luau makes it very painless to write the hooks you need for any kind of unusual integration needs that you might have. It helps the lot that there's a lot of talented people at Roblox working on Luau, and that Roblox's scripting needs aren't entirely dissimilar from Second Life's.

If you'd like to see more about the nuts-and-bolts of how those integration needs were addressed, Second Life's Luau VM fork called "SLua" is open source at https://github.com/secondlife/slua. SLua's diff from upstream Luau is intentionally kept small to not fragment the ecosystem, but there's quite a lot of logic related to individual scripts' runtime / memory limits and script state serialization that might be interesting to people.

[u/sylvolas]

Linden labs as a word has been stuck in my head for 5+ years after seeing a DNSL video where he trolled this lady and her amusement park.

He’d ask a question about the amusement park or its rules, and every other answer she’d snap at him and say “LINDEN LABS-“ followed by some citation of your rules or something to that effect.

I’m sure this is not an appropriate contribution to the thread, but in short your game has made for a lot of great videos imo.

[u/ResponseFluffy271]

What's are some things you can do with Lua that you can't do with LSL?

[u/Background-Rock-7737 → u/ResponseFluffy271]

Have multiple timers running without needing any workarounds.

[u/Snownel → u/ResponseFluffy271]

Native support for multi-dimensional arrays (tables), better JSON support, coroutines/async/await, first-class functions, UTF-8 strings (Mono is UTF-16), much more memory, much better performance...

[u/Legion_Of_Many]

Thanks for making this available guys. I have been able to integrate into my project with this source.

[u/AutoModerator]

Hi! It looks like you're posting about Roblox. Here at /r/Lua we get a lot of questions that would be answered better at /r/RobloxGameDev or the Roblox Developer Forum so it might be better to start there. However, we still encourage you to post here if your question is related to a Roblox project but the question is about the Lua language specifically, including but not limited to: syntax, language idioms, best practices, particular language features such as coroutines and metatables, Lua libraries and ecosystem, etc. Bear in mind that Roblox implements its own API (application programming interface) and most of the functions you'll use when developing a Roblox script will exist within Roblox but not within the broader Lua ecosystem.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Downvoted-Dork]

I think we should ban posts talking about Roblox or gmod at this point

[u/Nescolet]

Do you plan to host your own coding AI chatbox specially trainned to code (and teach) SLua (maybe available only while user is inworld within the script window) or maybe feed SLua documentation and examples to a specific AI of your choice so users can know in advance which AI is better at teaching/coding SLua?