📃 SLua Alpha

The compiler on agni is not doing as much constant-folding and dead-code elimination as the CLI tools. Take this script: print(gcinfo()) local a = "a" .."a".."a".."a".."a".."a".."a".."a".."a".."a" .."a".."a".."a".."a".."a".."a".."a".."a".."a".."a".."a" print(gcinfo()) Variable a should be constant-folded away, then eliminated as dead code, as it is unused On simulator version Luau 2026-01-30.21516666911 , this prints [4:29 PM] Object: 1.4892578125 [4:29 PM] Object: 1.525390625 The two numbers are different, so something entered memory in-between the two gcinfo calls However, when run locally, it prints: $ ./slua memtest.luau 38 38 The two numbers are the same, indicating nothing happened in memory in-between the two calls. Looking at the bytecode compiled locally: $ ./slua-compile memtest.luau Function 0 (??): 1: print(gcinfo()) GETIMPORT R0 1 [print] GETIMPORT R1 3 [gcinfo] CALL R1 0 -1 CALL R0 -1 0 4: print(gcinfo()) GETIMPORT R0 1 [print] GETIMPORT R1 3 [gcinfo] CALL R1 0 -1 CALL R0 -1 0 5: RETURN R0 0 nothing at all happens in between the two print statements. No allocation, no string concatenation, nothing I can't grab the bytecode for the simulator-compiled script, but it's clearly doing something differently

This appears to be related to highlighting. It is also influenced by the amount of code in the script and by the amount of comment text. However, commenting out all preceding code, or turning it all into a very long string, can make the problem vanish. The affected scripts compile and run without unexpected errors, but it becomes difficult to edit certain lines within the editor: Steps to reproduce: In an SLua Enabled Sim, rez a new prim. Create a new script, open it, and replace the contents with the attached script. Note that "LLEvents" in line 14 is highlighted in green. Attempt to select the line. Observe that only the word "function" is highlighted. Copy the line and paste at the bottom of the script. Observe that the whole line is pasted. Place the cursor at the left edge of the line and move right one character at a time with the arrow keys. Observe that the characters "s.touch_e" are skipped as a group. Attempt to select or erase "_end". Depending on your method, various failures will occur. Press End to move to the end of the line. Observe that the visible cursor is well past the end of the line, but that backspace deletes the last character. Note that when the line no longer represents a proper event that the line becomes normally editable. Comment out line 12. Observe that "LLEvents" becomes blue and the line is normally editable. Reenable line 12 and delete line 13. Observe the same. So far, I have only observed this with LLEvents.touch... All 3 are affected. In-Editor WORKAROUND: When editing an affected line, change the first keyword by adding an extra character at the beginning, such as making "LLEvents" into "xLLEvents". Edit the line as needed, then remove the extra character.

The compiler on agni is not doing as much function inlining as the CLI tools. Take this script: print(gcinfo()) local function b() return "hello" end print(gcinfo()) print(b()) Variable b should be inlined away On simulator version Luau 2026-01-30.21516666911 , this prints [4:56 PM] Object: 1.4521484375 [4:56 PM] Object: 1.4716796875 [4:56 PM] Object: hello The two numbers are different, so something entered memory in-between the two gcinfo calls However, when run locally, it prints: $ ./slua inlinetest.luau 39 39 hello The two numbers are the same, indicating nothing happened in memory in-between the two calls. Looking at the bytecode compiled locally: $ ./slua-compile inlinetest.luau Function 0 (b): 2: local function b() return "hello" end LOADK R0 K0 ['hello'] RETURN R0 1 Function 1 (??): 1: print(gcinfo()) GETIMPORT R0 1 [print] GETIMPORT R1 3 [gcinfo] CALL R1 0 -1 CALL R0 -1 0 2: local function b() return "hello" end DUPCLOSURE R0 K4 ['b'] 3: print(gcinfo()) GETIMPORT R1 1 [print] GETIMPORT R2 3 [gcinfo] CALL R2 0 -1 CALL R1 -1 0 4: print(b()) GETIMPORT R1 1 [print] MOVE R2 R0 CALL R2 0 -1 CALL R1 -1 0 5: RETURN R0 0 On the final print call, it's not calling function b , it does seem to be calling b , not just moving "hello" to a register. hmm. The gcinfo calls above sure made it look inlined away. I can't grab the bytecode for the simulator-compiled script, but it's seems to be doing something differently

Having math.randomseed start a consistent pseudorandom sequence in each script when calling math.random allows saving and restoring, or transmitting any procedurally generated object simply by storing, recalling, or transmitting the seed, assuming knowledge of the procedure used to generate the object, be it an instance of a puzzle, a maze, a level in a game or whatever. Without this, one is obliged to either save, restore, and/or transmit potentially a great deal of data, or to create one's own pseudorandom number generator that does not depend on math.random. Also, when debugging a script, being able to repeat a psuedorandom sequence to get consistent results among trials can be invaluable when dealing with intermittent faults and tracking down uncommon errors. I like the idea that if math.randomseed has not been called, that the effective seed is itself random as is presently the case. Nevertheless, for the above reasons, I feel that it is valuable to be able to stipulate a seed that applies specifically to the script in question and does not affect and is not affect by sequences being generated by any other scripts concurrently running. On possible option that might be less painful than completely replacing the current implementation, could be to add a second math.rand and math.randseed pair that performed as described above, using a relatively simple, fast algorithm that might not be guaranteed to be quite as well randomized as math.random, but that is adequate for randomized procedural object generation.

In 1-prim objects, root prim has link number 0. In other prims, root prim has link number 1 ( =LINK_ROOT ). This behavior should change: It's a pain to make scripts work with both types of objects Link numbers are so close to already using 1-based indexing, like everything else in SLua has been already changed to. This change would complete that transition For functions that accept a link number: 0 and 1 should both be treated equally as the root prim number, regardless of prim count This change should be made in SLua at least, but possibly in LSL and Mono as well. (it's probably easier to change both) I can't think of a reason this would break existing LSL content, as it only makes the functions do something useful where they previously did nothing (Suzanna thought of a theoretical reason it could break code below) For functions that return a link number: In LSL, they must be left alone, as this check is somewhat common to test for 1-prim vs multi-prim: if (llGetLinkNumber()) In SLua, they should be changed to always return 1 ( =LINK_ROOT ). This makes them more consistent, and SLua has no backwards compatibility concerns yet (This is the main reason this proposal is in SLua-Alpha and not Scripting Bugs) These functions accept link numbers, and return a prim property: ll.AvatarOnLinkSitTarget ll.GetLinkKey ll.GetLinkMedia ll.GetLinkName ll.GetLinkNumberOfSides ll.GetLinkPrimitiveParams ll.GetLinkSitFlags ll.GetObjectLinkKey ll.IsLinkGLTFMaterial These functions accept link numbers, and modify them: ll.BreakLink ll.ClearLinkMedia ll.LinkAdjustSoundVolume ll.LinkParticleSystem ll.LinkPlaySound ll.LinkSetSoundQueueing ll.LinkSetSoundRadius ll.LinkSitTarget ll.LinkSetSoundRadius ll.MessageLinked ll.SetLinkAlpha ll.SetLinkCamera ll.SetLinkColor ll.SetLinkGLTFOverrides ll.SetLinkMedia ll.SetLinkPrimitiveParams ll.SetLinkPrimitiveParams({PRIM_LINK_TARGET}) ll.SetLinkPrimitiveParamsFast ll.SetLinkPrimitiveParamsFast({PRIM_LINK_TARGET}) ll.SetLinkRenderMaterial ll.SetLinkSitFlags ll.SetLinkTexture ll.SetLinkTextureAnim ll.SetPrimitiveParams({PRIM_LINK_TARGET}) ll.SitOnLink These functions return a link number: LLEvents.link_message ll.CastRay ll.DetectedLinkNumber DetectedEvent.getLinkNumber ll.GetLinkNumber ll.GetObjectDetails({OBJECT_LINK_NUMBER})

in slua: local t = {"a", "b", "c", "d"} local u = ll.ListReplaceList(t, {"x"}, 2, 2) print("t", lljson.encode(t)) -- t ["a","b","c","d"] print("u", lljson.encode(u)) -- u ["a","x","b","d"] -- expected ["a","x","c","d"] lsl is fine: default { state_entry() { list t = ["a", "b", "c", "d"]; list u = llListReplaceList(t, ["x"], 1, 1); llOwnerSay("t: " + llList2Json(JSON_ARRAY, t)); // t: ["a","b","c", "d"] llOwnerSay("u: " + llList2Json(JSON_ARRAY, u)); // u: ["a","x","c", "d"] // correct }} llcompat is fine: local t = {"a", "b", "c", "d"} local u = llcompat.ListReplaceList(t, {"x"}, 1, 1) print("t", lljson.encode(t)) -- t ["a","b","c", "d"] print("u", lljson.encode(u)) -- u ["a","x","c", "d"]

I would think these would always be equal in SLua: print(ll.GetMemoryLimit()) -- 130920 print(2^17) -- 131072 That's what it does in LSO; just returns a constant 2^14 default { state_entry() { llOwnerSay((string)llGetMemoryLimit()); // 16384 llOwnerSay((string)llPow(2, 14)); // 16384 }}

Not much more to it. llGetFreeMemory report 16000s bytes free at all times, llGetSPMaxMemory reports 16384 whether profiling is on or off. Same applies to pure Luau scripts, neither function returns meaningful values. ~~llGetUsedMemory and ll.GetUsedMemory appear to be ok.~~ <- Edit: redacted, they do not count memory used by tables or strings at all. A table with 10000 random numbers in it is reported as not using any memory, as well as a string with 256k(! that can't be right either) characters. Same applies to lists when compiled as LSL-Luau.

local tab1, tab2 = {}, {} local weak = setmetatable({}, { __mode = "kv" }) for i = 1, 5000 do tab1[i] = i end weak[1] = tab1 print(ll.GetUsedMemory()) -- > 83706 tab1 = nil print(ll.GetUsedMemory()) -- > 83706 for i = 1, 5000 do tab2[i] = i end -- > Script run-time error not enough memory sleeping doesn't work: local tab1, tab2 = {}, {} local weak = setmetatable({}, { __mode = "kv" }) for i = 1, 5000 do tab1[i] = i end weak[1] = tab1 print(ll.GetUsedMemory()) -- > 83741 tab1 = nil ll.Sleep(3) print(ll.GetUsedMemory()) -- > 83741 for i = 1, 5000 do tab2[i] = i end -- > Script run-time error not enough memory we need to move to another event, this works: local tab1, tab2 = {}, {} local weak = setmetatable({}, { __mode = "kv" }) for i = 1, 5000 do tab1[i] = i end weak[1] = tab1 print(ll.GetUsedMemory()) -- > 83845 tab1 = nil LLTimers:once(0, function() print(ll.GetUsedMemory()) -- > 2190 for i = 1, 5000 do tab2[i] = i end print("ok") end) -- > ok

Using a notecard "test" with a line: Time flies like an arrow; fruit flies like a banana. -- one "Time": print(ll.FindNotecardTextSync("test","Time",0,0,{})[3]) -- 4 -- one "banana": print(ll.FindNotecardTextSync("test","banana",0,0,{})[3]) -- 6 -- two "like": print(ll.FindNotecardTextSync("test","like",0,0,{})[3]) -- 5 print(ll.FindNotecardTextSync("test","like",0,0,{})[6]) -- 5 -- two "flies": print(ll.FindNotecardTextSync("test","flies",0,0,{})[3]) -- 6 print(ll.FindNotecardTextSync("test","flies",0,0,{})[6]) -- 6 Could be related to this: https://feedback.secondlife.com/slua-alpha/p/the-length-returned-by-llfindnotecardtextsync-has-been-1-based previously to that canny all lengths were returned +1.