Lua Scripting
in progress
Signal Linden
Second Life's interactive objects rely on LSL—a basic scripting language largely unchanged since 2003. This limits creators’ ability to build advanced, dynamic experiences. By introducing Lua, a powerful and widely adopted language, we can modernize scripting and unlock new creative possibilities.
- Broadens Second Life’s creator base to more easily include developers from Lua-heavy platforms (e.g., Roblox, Garry's Mod).
- Reinvigorates existing creators who’ve struggled with LSL’s limitations.
- Enables advanced features like mobile-focused development kits and robust 3D content manipulation (e.g., GLTF).
Objectives
- New Audiences: Attract creators from popular Lua-based UGC platforms.
- Easier Scripting: Leverage Lua’s built-in features, large support community, and ample learning resources.
- Re-Engage Creators: Provide a smooth transition from LSL with bridging functionality, encouraging return visits.
- Advanced Features: Introduce long-requested language improvements (e.g., map-types, index operators).
- Richer Experiences: Allow for more complex, dynamic scripts to increase retention and drive engagement.
- Reduced Technical Debt: Replace LSL's difficult-to-maintain system with a modern, flexible alternative.
- Education Opportunities: Offer a full-featured language that helps new programmers build real-world skills.
Links
- Lua FAQ - Read this if you have questions about "Why Lua?"
Log In
Angie McGregor
Signal Linden Will Lua scripting allow an object to determine which direction an avatar is facing?
Thalyn Sabre
Basic but accessible. Another stupid move from Linden Lab to make SL "Pro business" only!
Thhis a joke to read you are comparing SL to Roblox (GAME for psycho kids!) or Garry's Mod (SANDBOX for fun people, because SL insn't fun anymore.. "Business business business"... and communatarism everywhere with fake "inclusivity" for people speaking "ENGLISH ONLY" ....) while in reality, SL in now compared (as less nice than) to Sims 4 and GTA RP... because 90% of your new "customers" come to RP.... but with prices and physical limitations (totally crazy in 2025!) and the graphic engine asking for 3000$ PC just because 0 optimization about avatar (and that Linden Lab give up the war against lag!) while my ten years PC turn GTA Online in ultra/60FPS (and every other new games in High (60FPS min) !
Linden Lab believe to compet with ferrari and lambo while in fact, you are seen as a pedal car, and "LUA" will not change anything.
Liden Lab miss the blockchain and cryptocurrency opportunity, missed the VR and Enhanced/Augmented Reality, you have missed the "metavese" turn and you continue to sink, believing that (the only good) creators of Garry's Mod (Roblox are GAMERS and stupid kids!) will come on SL for fun and/or make RP with your high prices and this stupidity of 5 different shapes (an avatar cost 20-50€ now. It's not competition, it's atomization : everyone lose in the end. Let's come back "Project Mesh"!). Garry's MOD is free, and a SIM equivalent to SL "holds" on a server at $20/month (another good thing, give up by Linden Lab : SIMs on dedicated personal server)!
I stop here, you don't care. You still prefer listen "low level business money makers".... rather than real CREATORS BUILDERS (as ALWAYS, when you given the "Mentor" statuts only to big sims owners unable to BUILD something.... rather helpfull people....)!
Thalyn Sabre
Linden Lab have never supported Blender 3D for example while it's very accessible for everyone but still continue to promote paid/pro solutions like Maya, C4D and co. And dare pretend to be "open source friendly' (like Apple or google, only when it can give you free and cheap solutions... otherwise, you promote not better "closed solutions" because former "friends from College"...), with now 99% of heavy Mesh in SL build by students in 3Dmodel universities who doesn't care about SL, just there to fill their "marketplace" with their unoptimized sh... (and quit once they have a real job.....)!
Without talking about opportunist selling solutions at 40-100€ to create AN avatar because Linden Lab killed the excellent MeshProject, while if LL would have invest some money in Blender and OPEN Source (instead to just act like a USER of open source solutions just to save money, not to help the open source world!), EVERYONE could be creative on SL !!
Now, place to "pro-coders"... with the choice to make everything inaccessible for everyone....
Angie McGregor
Thalyn Sabre Lua has one of the easiest learning-curves of most modern scripting languages. This is only a benefit to creators who have struggled trying to learn LSL, including myself. I have recently started learning Lua for different purposes, and I'm excited at the prospect of knowing that the skills I'm learning now will also benefit my Second Life experience.
Personally I'm glad that LL completely avoided the whole cryptocurrency scam culture. A Second Life swarming with crypto-bro grifters sounds like hell to me. I will agree with you that they were idiots for not making an offer to buy Oculus before Zuckerberg did.
Signal Linden
Merged in a post:
Better Scripting Language
Janet Rossini
Since we're in this for the long term, please consider adding a more modern scripting language, such as Lua or Python, with support for such amazing new things as objects and arrays.
Signal Linden
in progress
Signal Linden
This is a bit of a belated post, as Lua scripting development has already begun.
Vulcan Viper
How about using something along the lines of Unreal Engine?
Nelson Jenkins
Wasn't Lua rumored to be on the horizon for client-side scripting? I think a lot of the problems with LSL stem from it being entirely server-side, so if you want to make anything comparable to other popular user-scripted games (like, say, Roblox) you've got to do a lot of work scripting HUDs that run server-side for no real reason. There's a reason virtually no other game handles everything server-side. It's just not scalable.
Nelson Jenkins
Eating my words a bit with the announcement that Luau is in testing and server-side Lua scripts are on the horizon...
tarisfeiri Resident
Personally I'd prefer a variant of ECMAScript over C#. ECMA is super easy to pick up, has very clear constructs and syntax, and is one of the most widely used standards - making it very easy to adopt.
That said, LSL isn't entirely bad - or wasn't, for its time - with a few caveats.
The biggest is complete inconsistency of method (function) names, parameters, and behaviors.
Second complaint is naming of native methods (functions). Why prefix everything with "ll".. it's just noise and makes it hard to read.
Third would be lack of lack of proper associative arrays, objects, and methods related to handling them.
Fourth would be the entire "blue menu window with buttons".. the need to handle it via channel listeners, and the entire way it is constructed.
And fifth.. I think we all can agree that the scripts could use much better garbage collection.
WolfGang Senizen
tarisfeiri Resident
Problems with adopting various languages including ECMAScript are answered in the "why lua" link provided in the original post. Especially the chart here https://ll-pwiki-assets-production.s3.amazonaws.com/images/7/7b/Lsl_vm_comparison.png
Inconsistency of naming could be addressed with LL's lua implementation, there is no strict need to use the same names, but that's their call, I agree it should be cleaned up a little if possible.
The ll prefixing or some sort of prefixing will likely stay, and make even more sense in LUA as the luau comes with a "standard library of sorts" so all ll specific functions will probably live inside some sort of namespace or object or be prefixed to distinguish them from Standard lua functions
Lua provides tables, which are associative, and has many methods for working with them.
The blue menu is something LL are possibly addressing on the side and not really part of this project, maybe with client-side scripting.
The luau vm that LL is planning to deploy for lua in sl, has pretty good GC afaik.
Gwyneth Llewelyn
I was going to write a long essay on why Lua is the way to go for an embedded language, but WolfGang Senizen already gave the major argument for picking Lua(u) over anything else over there: Lua (which, btw,
predates
ECMAscript...) was designed
to be an embedded language inside a larger system. There is no doubt in my mind that this is the main reason why you can finetune all those zillions of virtual machine/embedded wannabes and they simply can't compete with something that was thought, from the very beginning, to be
an embedded language inside a VM, and run as fast and efficiently as possible
.Everything else are, just, well, hacks. Even ECMAscript is just layers and layers and layers of complexity placed on top of what was
supposed
to be a basic scripting language to turn your HTML links red when you hovered over them — and not the insane mess we have today. Oh, sure, ECMAscript is comparatively easy to pick. But so is Lua. It's actually simpler
, because it was designed
to be
simple (as opposed to ECMAscript, which started simple and became overbloated after just a few iterations... as more and more and more things were stacked on top of a programming language never designed to do what it is now being used for).Theoretically, you
could
use some sort of macro pre-processor to hide the ugliest bits of Lua (such as the Pascal-like begin...end
constructs, the weird not-equal operator, and the crazy idea that indexes ought to start with 1
and not zero); after all, what matters here is not how 'pure' Lua is (thus, Luau — a strongly typed dialect, which makes it much
easier to write a good
compiler, JIT or otherwise), but how well its VM engine runs. And compared to everything else... well, Lua beats everything out there easily. You could
design a programming language from scratch to address the problem, but it would not
be the mess that JavaScript is. In fact, I bet that it would resemble Lua — at least, if you want to have the same kind of flexibility that Lua provides — with just some syntax sugar thrown on top of it.Gwyneth Llewelyn
The approach taken by LL is even more sensible. When we switched from the Linden-designed LSO VM to Mono, many of us thought, 'oh wow, one day we'll be able to use C# instead of LSL!' And, in fact, for a while, this possibility
was
experimented in OpenSimulator (which, after all, also
adopted Mono to provide VMs for its dialect of LSL). Nothing much came out of that, essentially because running full C# programmes compiled to Mono inside a virtual world environment is just not something plausible. It's possible
, aye, at least in theory, but you'll have to deal with all the levels of complexity posed by C# itself, and C# is possibly the 'easiest' objective-oriented descendant of C that is still around (in the sense of being the one with less functionality and/or ambiguities left for the compiler to figure out).That's why we will
first
have a LSL-to-LuauVM JIT compiler, and only over time will full Lua(u) support be gradually introduced, both being much more easily maintained, by having a unified bytecode, and the same library (or — hopefully! — many
libraries, using only those that are required for a specific script). This will even allow those preferring to code in LSL to be able to call user-submitted Lua libraries, for instance (granted, LSL lacks a mechanism to 'import' external libraries, but there are always superfast LinkMessages that can provide an API between LSL and a Lua library, if needed).How exactly the functions (and possibly classes) will be named in Lua, when calling library functions common to LSL, is a bit irrelevant, IMHO. I agree that prefixing everything in the library with
ll
is a bit annoying, but, alas, that was the best approach to take, taking everything else in account (namely, familiarity with the function names, especially those which have been around since the dawn of time...Kathrine Jansma
LSL isn't totally bad. Some quality of life additions would help to make it more accessible, but given the limited memory space, extensive object orientation is probably not that useful.
So yes, some more modern datatypes would be nice. Maybe some syntactic sugar to make common idioms easier on the eyes.
For example, i would love to see something like golang channels to simplify communication between scripts. Or some built in state machine support thats more useful.
If the environment wasn't as resource constrained as it is, one could talk about stuff like Transpilers as those are common in the Javascript world. But if every byte counts, you do not want the bloat they add.
Crush Cutie
A "better" scripting language would make LSL prone to "better" modern programming practices .. which are entirely centered around pointless abstraction under the guise of readability. This produces bloated inefficient code that is both huge and slow.
This is why we need a dozen cores that can hit 5GHz just to look at web pages.
LSL best practices are centered around minimizing bytecode. More actual code in less space that runs as fast as the system will allow. The cost is "readability".
I don't want different semantics, I want better profiling, tooling and built in functions that shortcut common operations .... and pointers.
Codex Alpha
Crush Cutie The move could be to try to attract new users that have grown up programming in LUA from World of Warcraft addons, to Minecraft, to Roblox of course.. get even a small percentage of those (5.5 MILLION CONCURRENT TODAY) users who want to graduate to a more adult platform.. could change things big time.
For me, I have perhaps an intermediate experience with LSL, but always feel I'm wasting my time - when sometimes I would like transferable things, but yes sometimes simple is nice, as my experience with C# so far is "wow so bloated and ugly" vs my C experience - which is "ahh so simple, so dangerous, but so powerful" :D
Crush Cutie
Codex Alpha I don't think "Hey, we have _____ scripting now!" is really much of a rallying call.
The draw would need to be functionality. "Hey, SL can now do _____ !"
Load More
→