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 _____ !"
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.
o
omoMMomo Resident
The logical upgrade would be actual C# since LSL already runs on Mono.
Keen Starforge
omoMMomo Resident: This was at one point a planned feature, and personally I wouldn't mind being able to just directly code C# https://nwn.blogs.com/nwn/2021/04/second-life-scripting-lsl-c-sharp-jim-purbrick.html
Bleuhazenfurfle Resident
Woolfyy Resident: SL isn't the only "game" that needs to run user-written scripts on the server — but it is the only one running LSL — and the main one I've had the most personal experience with, used C# (haven't touched it in a few years, really should take another look sometime). I was there when they first introduced scripting, and it was kinda crap; locked down to the point it was barely better than LSL.
Until one of the players wrote a new scripting engine as a mod, demonstrating it can actually allow most of the language, using the built-in tooling, and most of the basic libraries, with less constraints, and actually performed better than their heavily locked down one. So they ditched their own and went with the new one, resulting in an overall improvement; scripts could do far more, with fewer resources, and less resources wasted fighting the system for "safety" (which actually introduced more safety problems than it solved). Mostly, it's just about limiting the libraries on offer, so you're not giving the users direct access to memory or the OS.
For the noobs, the learning curve _was_ a little steeper (C# is a bit on the verbose side), but there's also
way
more learning resources available, and with decent examples to work from, it's not as scary as it looks. Most noobs build scripts by copy-and-pasting from examples just the same, so I'd suggest that for someone who's still learning, who barely knows the language yet, the two aren't really all that different. The extra words that still don't make any more sense, barely matter… But the scope later on is _much_ wider. Object members help, too, because it tends to group functionality in a way that (usually) makes more sense (LSL tries, with it's llList2xxx and stuff), and accessing a prims properties with a dot, would be _way_ easier to grasp than llSetPrimitiveParams and friends.Also you get lazy "developers" in LSL, too, I've seen plenty of horrible scripts, but worse, LSL _forces_ you to do really dumb things, because it simply doesn't give you a whole lot of choice.
Load More
→