📃 SLua Alpha

Since 2026-04-09.24211153544 toggling "Disable Scripts" under Debug on the Region / Estate Tools seems to just outright crash the simulator. This occured on "Absolute Zero" today at roughly 17:40 UTC.

When calling ll.GetUsedMemory() or ll.GetFreeMemory() immediately after some memory operation: -- memory miscount local tab = {} local mem = ll.GetUsedMemory() tab = table.create(32, true) print(ll.GetUsedMemory() - mem) -- > 512 tab = table.move(tab, 1, 1, 1, {}) print(ll.GetUsedMemory() - mem) -- > 560 -- should be 16 Adding something that yields works well (it seems that yielding cleans things): -- yielding local tab = {} local mem = ll.GetUsedMemory() tab = table.create(32, true) print(ll.GetUsedMemory() - mem) -- > 512 tab = table.move(tab, 1, 1, 1, {}) for _ = 1, 1 do end -- yielding print(ll.GetUsedMemory() - mem) -- > 16 Also calling the function twice (perhaps because they yield at the end): -- calling twice local tab = {} local mem = ll.GetUsedMemory() tab = table.create(32, true) print(ll.GetUsedMemory() - mem) -- > 512 tab = table.move(tab, 1, 1, 1, {}) local used, used = ll.GetUsedMemory(), ll.GetUsedMemory() print(used - mem) -- > 16 Could ll.GetUsedMemory() and ll.GetFreeMemory() yield at the start to update the memory?

default { state_entry() { // editor line 0 integer i = 0.5; // line 1 }} -- > Line 2: 'integer i' assigned a float value. The editor could start with line 1 (like with SLua), or the messages return the error line - 1.

printing: print("test\0ing", "something") -- > test something ll.OwnerSay("test\0ing") -- > test saying on a channel to another object: -- object 1 local s = "test\0ing" LLEvents:on("touch_start", function() ll.RegionSay(1, s) end) -- object 2 LLEvents:on("listen", function(_, _, _, msg) print(#msg, msg) end) ll.Listen(1, "", "", "") -- > 4 test linked messaging: -- script1 local s = "test\0ing" LLEvents:on("touch_start", function() ll.MessageLinked(LINK_THIS, 0, s, s) end) -- script 2 LLEvents:on("link_message", function(_, _, s1, s2) print(#s1, s1, #s2, s2) end) -- > 4 test 4 test

The rational is simple enough. Even though 128k is bigger than ever, it's not infinite. Optimization controls that are "standard" aren't as useful as optimization controls that fit the demands of second life. Optimizations that reduce code footprint (e.g. aggressive constant folding) should be usable without triggering optimizations that increase code size in the name of performance. I don't know what optimizations are available, and how you want to treat optimization control in scripts, but it seems that tailoring them to fit second life make sense.

While this caveat behavior is known and possibly relied upon by lsl scripts. Nobody should be writing a slua script expecting this security issue to exist. So if possible could a ll.HTTPRequest from slua, only trigger the http_response event in the slua script making the request. Or a dataserver request also respond only to the requesting script. Not in any other, script regardless of their platform runtime. This might be a slight pain to implement to keep the behavior for lsl on luau scripts, but I think worth it for slua Test Place 2 scripts in a prim save them with the following content ll.HTTPRequest("https://secondlife.com",{},"") function http_response(id,stat,meta,body) ll.OwnerSay(`{ll.GetScriptName()} = {stat}`) end Note that on saving of the second script you get 2 owner says, one from each script stating the response status. Ideally this behavior should be avoided for slua. Alternate suggestion It was suggested it may be possible to instead add a new HTTP_* flag Something like ll.HTTPRequest( "https://secondlife.com", { HTTP_PRIVATE_REQUEST, TRUE }, "" ) This would not work for dataserver events though

Possibly related to [ https://feedback.secondlife.com/scripting-bugs/p/script-suddently-losing-connetion-with-the-server-on-save ] A few times I've gotten the above error. Fixing the syntax error does not eliminate the message — it's as if the script inventory instance is permanently disabled. My workaround has been to copy the script text to a new inventory instance. I was able to reproduce this on SLua Tombolo. 1) Create a block and add a new SLua script to it. 2) Change line 1 to: `` xxx ll.Say(0, "Hello, Avatar!") `` 3) Save. See an expected, normal error message. 4) Clone the object. Edit the script in the clone. 5) Notice the cloned script is marked not-running. 6) Use the external editor button to edit the cloned script. See the dreaded (0,0) error. (I am using BBEdit as my external editor: /usr/bin/open -a bbedit "%s" ) --- Second Life Project lua editor 7.1.12.13973830462 (64bit) Release Notes You are at 194.7, 250.2, 23.1 in SLua Tombolo located at simhost-0766603a88e3665d6.aditi SLURL: secondlife://Aditi/secondlife/SLua%20Tombolo/195/250/23 (global coordinates 41154.7, 23802.2, 23.1) Luau 2025-03-27.14115520293 Release Notes CPU: Apple M2 Max (2400 MHz) Memory: 32768 MB OS Version: macOS 15.3.2 Darwin 24.3.0 Darwin Kernel Version 24.3.0: Thu Jan 2 20:24:23 PST 2025; root:xnu-11215.81.4~3/RELEASE_ARM64_T6020 x86_64 Graphics Card Vendor: Apple Graphics Card: Apple M2 Max OpenGL Version: 4.1 Metal - 89.3 Window size: 2602x2102 Font Size Adjustment: 96pt UI Scaling: 1 Draw distance: 512m Bandwidth: 3000kbit/s LOD factor: 1.25 Render quality: 2 Texture memory: 21845MB Disk cache: Max size 1638.4 MB (99.9% used) HiDPI display mode: true J2C Decoder Version: KDU v7.10.4 Audio Driver Version: OpenAL, version 1.1 ALSOFT 1.23.1 / OpenAL Community / OpenAL Soft: OpenAL Soft Dullahan: 1.14.0.202408091638 CEF: 118.4.1+g3dd6078+chromium-118.0.5993.54 Chromium: 118.0.5993.54 LibVLC Version: 3.0.21 Voice Server Version: Not Connected Packets Lost: 13/10384 (0.1%) March 30 2025 06:20:01

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

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