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
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.
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 _____ !"
Woolfyy Resident
Knowing that LSL scripting is focused on having everybody being able to script ... better stay on the existing language. It just needs a few more functions to get better. Such requests for new languages always make me think to some developers that i met on different groups who want to do Java in LSL because they learnt Java outside of LSL and don't want to spend time learning LSL.
Peter Stindberg
I kind of like the old-school limitations of LSL. It keeps you on your toes, makes you find unique and original ways to solve problems, and keeps the playing field levelled. The recent devolpments we saw for the past 2-3 years are very promising. Allowing for Python or C# will lure people into writing sloppy, bloated code and bring with it all sorts of problems currently not present, for the dubious benefit of making it a bit more easy and flexible.
Load More
→