Lua FAQ - Revision history

Maggie Linden: Maggie Linden moved page SLua FAQ to Lua FAQ over redirect: Terminology update

2026-04-07T20:44:43Z

Maggie Linden moved page SLua FAQ to Lua FAQ over redirect: Terminology update

← Older revision	Revision as of 13:44, 7 April 2026
(No difference)

Gwyneth Llewelyn: Added inline syntax highlighting, updated a few external links, added to category

2025-10-20T08:44:37Z

Added inline syntax highlighting, updated a few external links, added to category

← Older revision		Revision as of 01:44, 20 October 2025
Line 3:		Line 3:
	=== Can I keep using LSL? ===		=== Can I keep using LSL? ===

	Yep! LSL should work exactly the same as before, and a lot of testing work has been done (and is being done) to ensure that is the case. Even if you’re an LSL pro and rely on things like <~~code~~>(some_list != [])</~~code~~> for getting the list length, or strange things like <~~code~~>((largestring="") + largestring)</~~code~~>, you’re fully covered. Those still work, and now have optimized implementations.		Yep! LSL should work exactly the same as before, and a lot of testing work has been done (and is being done) to ensure that is the case. Even if you’re an LSL pro and rely on things like <syntaxhighlight lang="lsl2" inline>(some_list != [])</syntaxhighlight> for getting the list length, or strange things like <syntaxhighlight lang="lsl2" inline>((largestring="") + largestring)</syntaxhighlight>, you’re fully covered. Those still work, and now have optimized implementations.

	In fact, LSL will get better than ever before, running faster, and using less memory! The generated bytecode for an LSL script in Lua is generally half the size of a Mono script, and most strings take up half as much memory by virtue of using UTF-8 instead of UTF-16.		In fact, LSL will get better than ever before, running faster, and using less memory! The generated bytecode for an LSL script in [https://lua.org Lua] is generally half the size of a Mono script, and most strings take up half as much memory by virtue of using UTF-8 instead of UTF-16.

	We’ve taken a lot of care in writing the new LSL compiler to make the scripting experience for people who prefer LSL better than it was before.		We’ve taken a lot of care in writing the new LSL compiler to make the scripting experience for people who prefer LSL better than it was before.
Line 15:		Line 15:
	For more advanced features, the idea is that there should still be a path for exposing them to LSL. Obviously, with Lua it’s possible to have object-oriented APIs that would not be possible in LSL, but those objects will generally be written in a way that calling a method on a “special” object we introduce in Lua will really boil down to a function call that can be expressed in LSL.		For more advanced features, the idea is that there should still be a path for exposing them to LSL. Obviously, with Lua it’s possible to have object-oriented APIs that would not be possible in LSL, but those objects will generally be written in a way that calling a method on a “special” object we introduce in Lua will really boil down to a function call that can be expressed in LSL.

	Not a real example, but <~~code~~>some_object:giveInventoryList("folder_name", inventory_list)</~~code~~> might really boil down to a <~~code~~>llGiveInventoryList(some_object_id, "folder_name", "inventory_list");</~~code~~> call. In that way, most additional Lua functionality will be a fancy “easier” wrapper around functions shared with LSL!		Not a real example, but <syntaxhighlight lang="lua" inline>some_object:giveInventoryList("folder_name", inventory_list)</syntaxhighlight> might really boil down to a <syntaxhighlight lang="lsl2" inline>llGiveInventoryList(some_object_id, "folder_name", "inventory_list");</syntaxhighlight> call. In that way, most additional Lua functionality will be a fancy “easier” wrapper around functions shared with LSL!

	The caveat is if functions are added that use new types that aren't in LSL (like functions that take in a <code>key -> value</code> map) likely won't be exposed to LSL, as there's no way to represent them in LSL anyway.		The caveat is if functions are added that use new types that aren't in LSL (like functions that take in a <code>key -> value</code> map) likely won't be exposed to LSL, as there's no way to represent them in LSL anyway.
Line 288:		Line 288:
	While this might look unreasonably large, this is also pretty similar to how <code>async</code> C# functions that have <code>await</code>s get compiled. The code required to allow a function to pause in the middle to let other things run is necessarily very large, and our Mono bytecode instrumentation is essentially a special variant of that which optimizes for cases where the function won't have to pause. Try pasting the following code into sharplab.io (while decompiling to IL) and you'll see something very similar:		While this might look unreasonably large, this is also pretty similar to how <code>async</code> C# functions that have <code>await</code>s get compiled. The code required to allow a function to pause in the middle to let other things run is necessarily very large, and our Mono bytecode instrumentation is essentially a special variant of that which optimizes for cases where the function won't have to pause. Try pasting the following code into sharplab.io (while decompiling to IL) and you'll see something very similar:

	<~~pre~~>		<syntaxhighlight lang="C#">
	using System.Threading.Tasks;		using System.Threading.Tasks;
	public class Example {		public class Example {
Line 302:		Line 302:
	}		}
	}		}
	</~~pre~~>		</syntaxhighlight>

	The Lua bytecode ends up being a lot smaller, because the Lua scripting engine itself knows how to handle this case, and doesn't need to add any special code to your scripts to allow them to be paused and resumed in the middle of a function.		The Lua bytecode ends up being a lot smaller, because the Lua scripting engine itself knows how to handle this case, and doesn't need to add any special code to your scripts to allow them to be paused and resumed in the middle of a function.
Line 324:		Line 324:
	=== How does interoperation with LSL work? ===		=== How does interoperation with LSL work? ===

	Everything that you expect from LSL should have some equivalent in Lua. There’s <~~code~~>key</~~code~~>s, <~~code~~>rotation</~~code~~>s and <~~code~~>vector</~~code~~>s and something like <~~code~~>some_vec * some_rot</~~code~~> in LSL is the exact same in Lua scripts.		Everything that you expect from LSL should have some equivalent in Lua. There’s <syntaxhighlight lang="lsl2" inline>key</syntaxhighlight>s, <syntaxhighlight lang="lsl2" inline>rotation</syntaxhighlight>s and <syntaxhighlight lang="lsl2" inline>vector</syntaxhighlight>s and something like <syntaxhighlight lang="lsl2" inline>some_vec * some_rot</syntaxhighlight> in LSL is the exact same in Lua scripts.

	All LSL functions will be available in Lua, and something like <~~code~~>llSay(0, “hi!”)</~~code~~> is just <~~code~~>ll.Say(0, “hi!”)</~~code~~> now. What about <~~code~~>llSetPos(llGetPos() + <0, 0, 1>);</~~code~~>? Just <~~code~~>ll.SetPos(ll.GetPos() + vector(0, 0, 1))</~~code~~>.		All LSL functions will be available in Lua, and something like <syntaxhighlight lang="lsl2" inline>llSay(0, “hi!”)</syntaxhighlight> is just <syntaxhighlight lang="lua" inline>ll.Say(0, “hi!”)</syntaxhighlight> now. What about <syntaxhighlight lang="lsl2" inline>llSetPos(llGetPos() + <0, 0, 1>);</syntaxhighlight>? Just <syntaxhighlight lang="lua" inline>ll.SetPos(ll.GetPos() + vector(0, 0, 1))</syntaxhighlight>.

	No special magic required here, and you can write whatever fancy wrappers you want around the existing LSL functions. We’ll be looking at how residents actually write these wrappers to inform the design of “official” higher-level Lua APIs, so we’re excited to see your ideas!		No special magic required here, and you can write whatever fancy wrappers you want around the existing LSL functions. We’ll be looking at how residents actually write these wrappers to inform the design of “official” higher-level Lua APIs, so we’re excited to see your ideas!
Line 390:		Line 390:
	But let’s not forget one of the most important cases where SL is unique: Scripts can move into your inventory, across region boundaries, etc, without having to care too much that it even happened. Even if your script runs forever in a single function, that’s totally fine! For example, this is a valid LSL script:		But let’s not forget one of the most important cases where SL is unique: Scripts can move into your inventory, across region boundaries, etc, without having to care too much that it even happened. Even if your script runs forever in a single function, that’s totally fine! For example, this is a valid LSL script:

			<syntaxhighlight lang="lsl2">
	default {		default {
	state_entry() {		state_entry() {
Line 398:		Line 399:
	}		}
	}		}
			</syntaxhighlight>

	All it does is run forever in the same function, incrementing a number in the floating text above an object. It still works if you take the object into your inventory, it still works if you move the object to another region, as a scripter you don't really have to care except in limited circumstances.		All it does is run forever in the same function, incrementing a number in the floating text above an object. It still works if you take the object into your inventory, it still works if you move the object to another region, as a scripter you don't really have to care except in limited circumstances.
Line 407:		Line 409:
	We have a version of this in our Mono scripting engine, which was all written in-house. It works very well for LSL, but it has trouble with more complex structures. As it turns out, taking all the state of a running program, serializing it, then transparently deserializing it is a difficult problem, even with data that <i>looks</i> simple.		We have a version of this in our Mono scripting engine, which was all written in-house. It works very well for LSL, but it has trouble with more complex structures. As it turns out, taking all the state of a running program, serializing it, then transparently deserializing it is a difficult problem, even with data that <i>looks</i> simple.

	Suppose we have something like <~~code~~>Dictionary<SomeObject, int></~~code~~> that we use as a counter for how many times we've seen each <code>SomeObject</code>. What do you do if the <code>GetHashCode()</code> bucketing changes after the script deserializes and the memory increases? Can you prevent that from happening? Will live <code>IEnumerator</code>s still work correctly? How can you be sure of this? .NET makes no guarantees about any of this behavior, and good luck digging through the .NET source code to figure out if any of this is even the case.		Suppose we have something like <syntaxhighlight lang="C#" inline>Dictionary<SomeObject, int></syntaxhighlight> that we use as a counter for how many times we've seen each <code>SomeObject</code>. What do you do if the <code>GetHashCode()</code> bucketing changes after the script deserializes and the memory increases? Can you prevent that from happening? Will live <code>IEnumerator</code>s still work correctly? How can you be sure of this? .NET makes no guarantees about any of this behavior, and good luck digging through the .NET source code to figure out if any of this is even the case.

	What about types that aren't marked <code>[Serializable]</code>, including types in the standard library? Can people just not use those? Do we have to write special custom serializers for them? Could they just randomly break when the script is deserialized and we accept that as a consequence?		What about types that aren't marked <code>[Serializable]</code>, including types in the standard library? Can people just not use those? Do we have to write special custom serializers for them? Could they just randomly break when the script is deserialized and we accept that as a consequence?
Line 439:		Line 441:
	=== Are you going to be using Lua 5.1? Why not 5.4? ===		=== Are you going to be using Lua 5.1? Why not 5.4? ===

	We're using Luau as the base, which is ''compatible'' with Lua 5.1 but not necessarily Lua 5.1. It includes various features of PUC-Rio's Lua implementation up to and including 5.4. The Luau Compatibility reference is a good guide for which features are taken from which versions of PUC-Rio Lua: https://luau~~-lang~~.org/compatibility		We're using [https://luau.org Luau] as the base, which is ''compatible'' with Lua 5.1 but not necessarily Lua 5.1. It includes various features of PUC-Rio's Lua implementation up to and including 5.4. The Luau Compatibility reference is a good guide for which features are taken from which versions of PUC-Rio Lua: https://luau.org/compatibility

	=== Are there going to be integer types in SL's Lua implementation? ===		=== Are there going to be integer types in SL's Lua implementation? ===

	We have added 32-bit integers but they are strictly for compatibility with existing LSL APIs where integer type identity is important within a list (<~~code~~>llSetPrimitiveParams()</~~code~~> and friends.) They don't have a literal form in Luau scripts and in general you should just use regular Lua numbers if you care about performance, since the Luau VM optimizes for their use, but technically you can use them. The Luau project discussions have some explanation as to why integers aren't a first-class user-facing type in Luau https://github.com/luau-lang/luau/discussions/242#discussioncomment-1707387.		We have added 32-bit integers but they are strictly for compatibility with existing LSL APIs where integer type identity is important within a list (<syntaxhighlight lang="lsl2" inline>llSetPrimitiveParams()</syntaxhighlight> and friends.) They don't have a literal form in Luau scripts and in general you should just use regular Lua numbers if you care about performance, since the Luau VM optimizes for their use, but technically you can use them. The Luau project discussions have some explanation as to why integers aren't a first-class user-facing type in Luau https://github.com/luau-lang/luau/discussions/242#discussioncomment-1707387.

	==== Are integer operations supported at all, then? (i.e. bitwise operators) ====		==== Are integer operations supported at all, then? (i.e. bitwise operators) ====

	Yes, through the <~~code~~>bit32</~~code~~> library. In fact, ''more'' integer operations than are currently supported in LSL, like logical shift right and rotate operations. See https://luau~~-lang~~.org/library#bit32-library .		Yes, through the <syntaxhighlight lang="lua" inline>bit32</syntaxhighlight> library. In fact, ''more'' integer operations than are currently supported in LSL, like logical shift right and rotate operations. See https://luau.org/library#bit32-library .

			[[Category:Lua]]

Signal Linden: Signal Linden moved page Lua FAQ to SLua FAQ

2025-03-21T17:12:18Z

Signal Linden moved page Lua FAQ to SLua FAQ

← Older revision	Revision as of 10:12, 21 March 2025
(No difference)

Signal Linden at 20:17, 18 September 2024

2024-09-18T20:17:18Z

← Older revision		Revision as of 13:17, 18 September 2024
Line 320:		Line 320:
	=== Are my existing LSL scripts going to run on Lua Automatically? ===		=== Are my existing LSL scripts going to run on Lua Automatically? ===

	While we can ~~run~~ LSL in Lua now, and the idea is to eventually phase out Mono, there’s no immediate plans to transparently migrate existing scripts over to Lua. There are ideas about how this could be done safely without breaking existing content, but we want to make sure we have everything right before we start work on this.		While we can test running LSL in Lua now, and the idea is to eventually phase out Mono, there’s no immediate plans to transparently migrate existing scripts over to Lua. There are ideas about how this could be done safely without breaking existing content, but we want to make sure we have everything right before we start work on this.

	=== How does interoperation with LSL work? ===		=== How does interoperation with LSL work? ===

Signal Linden at 05:50, 7 August 2024

2024-08-07T05:50:01Z

← Older revision		Revision as of 22:50, 6 August 2024
Line 436:		Line 436:

	If you're so inclined, you can go as far as to take the Luau transpiler and hack it up to support <code>!=</code> and <code>//</code> comments and really whatever you want. So long as it can take that source and output it to standard Lua, you're good.		If you're so inclined, you can go as far as to take the Luau transpiler and hack it up to support <code>!=</code> and <code>//</code> comments and really whatever you want. So long as it can take that source and output it to standard Lua, you're good.

			=== Are you going to be using Lua 5.1? Why not 5.4? ===

			We're using Luau as the base, which is ''compatible'' with Lua 5.1 but not necessarily Lua 5.1. It includes various features of PUC-Rio's Lua implementation up to and including 5.4. The Luau Compatibility reference is a good guide for which features are taken from which versions of PUC-Rio Lua: https://luau-lang.org/compatibility

			=== Are there going to be integer types in SL's Lua implementation? ===

			We have added 32-bit integers but they are strictly for compatibility with existing LSL APIs where integer type identity is important within a list (<code>llSetPrimitiveParams()</code> and friends.) They don't have a literal form in Luau scripts and in general you should just use regular Lua numbers if you care about performance, since the Luau VM optimizes for their use, but technically you can use them. The Luau project discussions have some explanation as to why integers aren't a first-class user-facing type in Luau https://github.com/luau-lang/luau/discussions/242#discussioncomment-1707387.

			==== Are integer operations supported at all, then? (i.e. bitwise operators) ====

			Yes, through the <code>bit32</code> library. In fact, ''more'' integer operations than are currently supported in LSL, like logical shift right and rotate operations. See https://luau-lang.org/library#bit32-library .

Signal Linden at 22:56, 9 July 2024

2024-07-09T22:56:16Z

← Older revision		Revision as of 15:56, 9 July 2024
Line 348:		Line 348:

	We’ll have code demonstrating "proper" usage of Lua around the time that the public beta starts.		We’ll have code demonstrating "proper" usage of Lua around the time that the public beta starts.

			=== Why Lua? I wanted C#! ===

			Great question!

			The server Lua scripting initiative actually started off as an attempt to get C# working on Second Life, basically as a revival of the work started in the 2000s. The initial thought was “this should be pretty easy, most of the work was already done getting everything onto Mono!” A lot of effort was put in over several months to:

			* Understand the Mono and .NET Core runtimes
			* Observe how other Engines and Virtual Worlds have embedded C# and scripting in general
			* Understand how recent advancements in scripting technologies (like WebAssembly) might make this integration easier
			* Whether unique properties of how scripting / content creation works on Second Life would make this harder to implement

			Unfortunately, the reasons we were ultimately unable to do this were very technical, so there’s no side-stepping a whole lot of tech-speak here, but there were several key properties that made integrating C# in Second Life rather difficult to implement:

			==== Sandboxing with reflection is hard ====

			Previous proof-of-concept code for C# in Second Life relied on CoreCLR sandboxing in Mono. This approach has fallen out of favor in recent years, because similar approaches led to many, many security holes in Java’s browser plugin. This sandboxing method is not possible in .NET Core, and has been totally removed.
			Since this sandboxing is no longer in .NET, we need to rely on the ability to look at code to determine if it looks “dangerous” before running it. Some people have done this, but it can only be done properly by disabling reflection, which is a core part of C# and .NET! Without reflection, you’re unable to use the fancy third-party Newtonsoft.JSON libraries or whatnot that you would have otherwise been able to use.

			Big portions of .NET’s standard library use reflection in a way that would be unsafe to expose to residents for scripting facilities, so you essentially have to maintain a list of functions and classes that are “safe” to use, and write alternatives to functions that are “unsafe” to call, but provide useful functionality. At this point, the scripting language that you’re exposing is a pretty bare-bones C# that needs to be scripted fundamentally differently from how you would write C# in Unity, for example.

			Allowing the use of modern C# features would require migration off of Mono and onto .NET core, which would be more involved than integrating Lua. Mono is in maintenance mode at the moment, and only supports the legacy .NET framework
			Ensuring that we’re able to correctly limit each script’s memory usage in a low-impact way is a bit of an unsolved problem in .NET Core. Generally, memory allocation tracking is something that you only do for debugging, but we need to do it for all scripts! What happens if you declare a static global in a C# script? Is the memory usage counted against all scripts of that type? Do all scripts share the data in that static variable?

			What about if there’s a function in the standard library that keeps a static cache of data? How do we penalize (or not penalize) scripts for allocations that they didn’t even control? How do we make sure that data remains consistent across script unloads / reloads?

			These are problems that most people embedding C# don’t need to solve, and the solutions that do exist are not generally workable into Second Life’s scripting model without multiple months of work. Most other virtual worlds do script sandboxing on a per-parcel or per-region level and put everything into the same logical scripting sandbox, which Second Life does not do. People would be rightly annoyed if someone’s HUD or attachments caused their parcel to go over the memory limit and things stopped working.

			==== Making everything micro-threaded with extreme size constraints is hard ====

			We need to be able to temporarily pause scripts in the middle of running an event handler so we can ensure we fairly schedule code execution. Previously, we wrote a script to do some quite clever binary instrumentation of .NET assemblies to inject yield points. This works quite well for for LSL scripts, but there are issues with C# in particular.

			One is that it doesn’t handle the <code>try</code>/<code>finally</code> construct in C#. While not impossible to handle, this would be a difficult undertaking. Something that would be much more difficult is allowing pausing execution inside a constructor or other such special constructs in C#. While the stack induction and bytecode manipulation done by our current system is very cool, it is quite complex to update, relies on outdated tools that don’t work with new .NET versions, and necessarily requires making the bytecode quite a bit larger than it would otherwise be by injecting hooks.

			But that’s not a huge deal, our .NET instrumentation library was written when <code>async</code>/<code>await</code> was not a thing in C#, so we should be able to inject <code>async</code>/<code>await</code> into user-provided source code instead to make it possible to transparently pause scripts right? Ehhhh, sort of. There are certain functions that cannot be made <code>async</code> in C# without breaking things. Object constructors are one of those, we have no way to pause and resume inside those. The situation is similar inside <code>ToString()</code> overloads. If we make a user-provided <code>ToString()</code> overload async, it’ll just never get called in cases where ToString() would normally get called! And what about implementing <code>IEnumerable.GetIterator()</code>? That might work… if you did a lot of work of replacing <code>IEnumerable</code> with <code>IAsyncEnumerable</code>., and <code>foreach</code> with <code>await foreach</code>... sometimes.

			Suffice to say, that if you go this route, you end up with something that’s sort-of C# but is missing a lot of things people expect of C#, and may not behave the same as the regular C# that it pretends to be.

			==== Saving script state ====

			But let’s not forget one of the most important cases where SL is unique: Scripts can move into your inventory, across region boundaries, etc, without having to care too much that it even happened. Even if your script runs forever in a single function, that’s totally fine! For example, this is a valid LSL script:

			default {
			state_entry() {
			integer i;
			while(TRUE) {
			llSetText("Run Number " + (string)(i++), <1,1,1>, 1);
			}
			}
			}

			All it does is run forever in the same function, incrementing a number in the floating text above an object. It still works if you take the object into your inventory, it still works if you move the object to another region, as a scripter you don't really have to care except in limited circumstances.

			That's a pretty contrived example, but there are tons of scripts with a structure like this! Probably a more common example is a math-heavy function that just takes a while to run. Under the current model, you can interrupt what's going on by just picking up the object, then plop it back down later and let it continue on. There are a number of ways you can handle this without serializing the whole runtime state, like raising an exception in the middle of executing the function, but what are the chances that people will handle this correctly? How many command-line scripts have you used that do something really weird when you pressed <code>CTRL+C</code>?

			To keep things simple for creators, we wanted to keep this nice property of LSL in whatever language we chose. This seemingly simple feature requires a lot of work because, think about it, how many programming languages let you seamlessly halt a program in the middle of it doing something, move it over to another computer, then resume whatever it was doing? Can you do that without doing a full-memory snapshot that would be gigabytes in size? That's not really a thing that people generally do, but it's required for us to not have sharp edges on our script creation experience!

			We have a version of this in our Mono scripting engine, which was all written in-house. It works very well for LSL, but it has trouble with more complex structures. As it turns out, taking all the state of a running program, serializing it, then transparently deserializing it is a difficult problem, even with data that <i>looks</i> simple.

			Suppose we have something like <code>Dictionary<SomeObject, int></code> that we use as a counter for how many times we've seen each <code>SomeObject</code>. What do you do if the <code>GetHashCode()</code> bucketing changes after the script deserializes and the memory increases? Can you prevent that from happening? Will live <code>IEnumerator</code>s still work correctly? How can you be sure of this? .NET makes no guarantees about any of this behavior, and good luck digging through the .NET source code to figure out if any of this is even the case.

			What about types that aren't marked <code>[Serializable]</code>, including types in the standard library? Can people just not use those? Do we have to write special custom serializers for them? Could they just randomly break when the script is deserialized and we accept that as a consequence?

			As you can see, there are a lot of hidden sharp edges involved in transparently moving scripts across servers, and the general answer provided when you ask about doing this is "That's very hard, make users write more intricate scripts that explicitly handle their own serialization and save their own state." This is fine if most of your users are professional programmers, not so if you have a mix of professional programmers and regular users who just want an object that counts how many people have clicked on their head.

			==== Wrapping it up ====

			This is a very small subset of the issues we ran into while trying to design a satisfactory C#-based scripting system that fits Second Life's needs. Seriously, there's about 20 pages of notes.

			Meanwhile, Lua makes most of these things easy. Want to halt a script mid-execution? Okay, set an interrupt handler. Want to serialize your script while it's running and have it move to another server? Okay, there are libraries that have existed for decades that can do this. Fable's save file system was based on this. Quite a lot of scripting engine integration problems we have that would rise to the level of extremely difficult and relatively novel Computer Science research in .NET (and by extension, C#) are relatively simple to do with Lua.

			=== Okay, but seriously, why Lua specifically? Because it's popular for games? Because <other platform> uses it? Why not <X>? ===

			Actually, no. Neither other users of Lua, or a specific love of the language had anything to do with the decision. If you prefer a different programming language, there's a good chance we considered it. We actually looked at quite a lot of different languages and their associated engines, including JavaScript and WebAssembly, Lua was considered fairly late in the process. The ones below are just a small subset of the ones that we looked at:

			[[File:Lsl_vm_comparison.png\|1000px]]

			As you can see, Luau was the only scripting runtime that fulfilled all of our requirements for a scripting engine within Second Life, and we arrived at it quite late in the decision process. We wanted something that we knew could deliver a high-quality scripting experience to creators, and we believe that Lua can best provide it.

			=== I genuinely hate Lua and refuse to use it ===

			A lot of people feel the same about LSL! Kidding aside, this is a totally defensible position, Lua can be a quirky language. Yes, it's strange that array indices start at 1. Yes, sometimes you can forget that you join strings with <code>..</code> and not <code>+</code>. It can take some getting used to.

			A big part of the reason why we're using Luau is due to the quality of the scripting engine itself, not specifically the language. A lot of issues people had with older versions of Lua have been addressed in Luau, and ones that haven't been for one reason or another can be easily dealt with since we have such a high degree of control over the scripting engine now. Luau is very easy to modify. If we find that there are real quality-of-life issues with Lua that people run into while writing scripts, we can just change how it works, assuming the benefits outweigh the cost of breaking interoperability with Lua scripts from elsewhere.

			But hey, maybe you really still hate the idea of using Lua. That's fine! The nice thing about having Lua instead of just LSL is there are a number of languages that can compile down to Lua code that could potentially work in Second Life! People have done work to get TypeScript and C# compiling to Lua, and it works pretty well for them, and there's also more exotic languages like MoonScript that target Lua specifically. See this GitHub repo for a listing: https://github.com/hengestone/lua-languages

			If you're so inclined, you can go as far as to take the Luau transpiler and hack it up to support <code>!=</code> and <code>//</code> comments and really whatever you want. So long as it can take that source and output it to standard Lua, you're good.

Signal Linden at 19:09, 9 July 2024

2024-07-09T19:09:14Z

← Older revision		Revision as of 12:09, 9 July 2024
Line 50:		Line 50:
	This compiles to the following Luau bytecode (subject to further optimization):		This compiles to the following Luau bytecode (subject to further optimization):

	<pre>		{\| role="presentation" class="wikitable mw-collapsible autocollapse mw-collapsed"
			\| <strong>Lua bytecode</strong>
			\|-
			\|<pre>
	Function 0 (_floudSubtract):		Function 0 (_floudSubtract):
	SUB R2 R0 R1		SUB R2 R0 R1
Line 63:		Line 66:
	RETURN R2 1		RETURN R2 1
	</pre>		</pre>
			\|}

	Okay, that's pretty decent. Some places where things could be more optimized, but no big deal. The equivalent Mono bytecode is (and bear with us, this is long:)		Okay, that's pretty decent. Some places where things could be more optimized, but no big deal. The equivalent Mono bytecode is (and bear with us, this is long:)

Signal Linden at 16:56, 3 July 2024

2024-07-03T16:56:43Z

← Older revision		Revision as of 09:56, 3 July 2024
Line 336:		Line 336:
	Most everything will be there, except for two notable exceptions:		Most everything will be there, except for two notable exceptions:

	- <code>getfenv()</code> / <code>setfenv()</code> / <code>_ENV</code> are not accessible because they necessarily make the script harder to optimize. Usually people only use this for mocking in test code, and this can be accomplished by passing in a parameter with a table of function references rather than pretending you have different global variable values for certain functions.		* <code>getfenv()</code> / <code>setfenv()</code> / <code>_ENV</code> are not accessible because they necessarily make the script harder to optimize. Usually people only use this for mocking in test code, and this can be accomplished by passing in a parameter with a table of function references rather than pretending you have different global variable values for certain functions.
	- <code>loadstring()</code> is not supported since it has a huge impact on performance. For those not familiar, this is equivalent to eval() in other languages. Every single time you call <code>loadstring()</code> the compiler has to go over what you passed in, compile it, and then load the generated bytecode. The Lua compiler isn’t particularly fast, and doing this can cause your script to halt in a way that we can’t interrupt to give other scripts time to run. This is a big part of why <code>eval()</code> and <code>loadstring()</code> are generally considered poor programming practice.		* <code>loadstring()</code> is not supported since it has a huge impact on performance. For those not familiar, this is equivalent to eval() in other languages. Every single time you call <code>loadstring()</code> the compiler has to go over what you passed in, compile it, and then load the generated bytecode. The Lua compiler isn’t particularly fast, and doing this can cause your script to halt in a way that we can’t interrupt to give other scripts time to run. This is a big part of why <code>eval()</code> and <code>loadstring()</code> are generally considered poor programming practice.

	The one real use-case we could think of for <code>loadstring()</code> is a debugger, and we’re looking at implementing a “real” debugger that lets you step through your code. Note that this won’t happen with the initial release, but watch this space!		The one real use-case we could think of for <code>loadstring()</code> is a debugger, and we’re looking at implementing a “real” debugger that lets you step through your code. Note that this won’t happen with the initial release, but watch this space!

Signal Linden at 20:01, 2 July 2024

2024-07-02T20:01:29Z

← Older revision		Revision as of 13:01, 2 July 2024
Line 320:		Line 320:
	=== How does interoperation with LSL work? ===		=== How does interoperation with LSL work? ===

	Everything that you expect from LSL should have some equivalent in Lua. There’s <code>key<code>s, <code>rotation</code>s and <code>vector</code>s and something like <code>some_vec * some_rot</code> in LSL is the exact same in Lua scripts.		Everything that you expect from LSL should have some equivalent in Lua. There’s <code>key</code>s, <code>rotation</code>s and <code>vector</code>s and something like <code>some_vec * some_rot</code> in LSL is the exact same in Lua scripts.

	All LSL functions will be available in Lua, and something like <code>llSay(0, “hi!”)</code> is just <code>ll.Say(0, “hi!”)</code> now. What about <code>llSetPos(llGetPos() + <0, 0, 1>);</code>? Just <code>ll.SetPos(ll.GetPos() + vector(0, 0, 1))</code>.		All LSL functions will be available in Lua, and something like <code>llSay(0, “hi!”)</code> is just <code>ll.Say(0, “hi!”)</code> now. What about <code>llSetPos(llGetPos() + <0, 0, 1>);</code>? Just <code>ll.SetPos(ll.GetPos() + vector(0, 0, 1))</code>.

Signal Linden at 20:01, 2 July 2024

2024-07-02T20:01:01Z

← Older revision		Revision as of 13:01, 2 July 2024
Line 307:		Line 307:

	In general, C# doesn't aim at producing very small bytecode for async functions, which is important for something like Second Life where you might have thousands of different individual scripts running within a region. Luau does generate small bytecode, while still having decent performance, making it a good choice for Second Life. And hey, strings are UTF-8 in Lua instead of UTF-16 as in Mono, so they use much less memory for most data as well.		In general, C# doesn't aim at producing very small bytecode for async functions, which is important for something like Second Life where you might have thousands of different individual scripts running within a region. Luau does generate small bytecode, while still having decent performance, making it a good choice for Second Life. And hey, strings are UTF-8 in Lua instead of UTF-16 as in Mono, so they use much less memory for most data as well.

			=== Are we going to get a higher memory limit in scripts? ===

			Not at first, Luau uses less memory than Mono, so you shouldn't really miss it. You're not going to start hitting script memory limits just because you converted your script to Lua. Using Lua proper should allow you to more precisely control memory usage in your scripts, e.g. by being able to handle memory allocation errors in <code>pcall()</code> and access to the mutable <code>buffer</code> class for byte-packing.

			There is some interest in giving specific scripts a little more memory if they're designated "high priority", like a main "game manager" object for an experience, but there are no specific plans for this at the moment.

			=== Are my existing LSL scripts going to run on Lua Automatically? ===

			While we can run LSL in Lua now, and the idea is to eventually phase out Mono, there’s no immediate plans to transparently migrate existing scripts over to Lua. There are ideas about how this could be done safely without breaking existing content, but we want to make sure we have everything right before we start work on this.

			=== How does interoperation with LSL work? ===

			Everything that you expect from LSL should have some equivalent in Lua. There’s <code>key<code>s, <code>rotation</code>s and <code>vector</code>s and something like <code>some_vec * some_rot</code> in LSL is the exact same in Lua scripts.

			All LSL functions will be available in Lua, and something like <code>llSay(0, “hi!”)</code> is just <code>ll.Say(0, “hi!”)</code> now. What about <code>llSetPos(llGetPos() + <0, 0, 1>);</code>? Just <code>ll.SetPos(ll.GetPos() + vector(0, 0, 1))</code>.

			No special magic required here, and you can write whatever fancy wrappers you want around the existing LSL functions. We’ll be looking at how residents actually write these wrappers to inform the design of “official” higher-level Lua APIs, so we’re excited to see your ideas!

			=== Can I mix LSL and Lua in the same script? ===

			No, although most things should be a direct translation. At some point we may make a tool to help you do this, but there are no specific plans at the moment.

			If your object has multiple scripts, you can mix LSL and Lua within the same object, though.

			=== Can we use all of Lua? Is anything not there? ===

			Most everything will be there, except for two notable exceptions:

			- <code>getfenv()</code> / <code>setfenv()</code> / <code>_ENV</code> are not accessible because they necessarily make the script harder to optimize. Usually people only use this for mocking in test code, and this can be accomplished by passing in a parameter with a table of function references rather than pretending you have different global variable values for certain functions.
			- <code>loadstring()</code> is not supported since it has a huge impact on performance. For those not familiar, this is equivalent to eval() in other languages. Every single time you call <code>loadstring()</code> the compiler has to go over what you passed in, compile it, and then load the generated bytecode. The Lua compiler isn’t particularly fast, and doing this can cause your script to halt in a way that we can’t interrupt to give other scripts time to run. This is a big part of why <code>eval()</code> and <code>loadstring()</code> are generally considered poor programming practice.

			The one real use-case we could think of for <code>loadstring()</code> is a debugger, and we’re looking at implementing a “real” debugger that lets you step through your code. Note that this won’t happen with the initial release, but watch this space!

			One thing that is planned, but will likely not be in the initial release is the coroutine library. This is one we’d really like to have in there, so you can do fancy things like have multiple “timers” in a script by just having coroutines that sleep every so often, but multiple running coroutines within the same script doesn’t fit well with the existing scripting architecture the Second Life server uses. Rest assured, this will be in there soon™ after Lua is released, but in the meantime you can still use something like the <code>Promise</code> chaining that JavaScript uses to write asynchronous event handlers.

			We’ll have code demonstrating "proper" usage of Lua around the time that the public beta starts.