📃 Lua Alpha

The icon for the VS Code Tight Integration feature of the VS Code extension got placed at the top of my sidebar without my intervention upon an automatic update. The icon being a folder and at the top of my sidebar caused confusion working on non-scripting projects. Please do something to disambiguate the icon, place it differently, or otherwise reduce the confusion. Potential ideas: Different icon Icon lower in the sidebar Hide the icon when not connected to a viewer with content to explore Thank you! :D

I encountered this Mono vs LSL VM discrepancy while trying to use AVSitter compiled to the LSL VM (offsets would fail to work due to how lists are handled in sitA) Here is a sample script that breaks on LSL VM but works on Mono: default { state_entry() { list vectors = [<1,0,1>,<0,-0.192,2.479>]; vectors = [(vector)llList2String(vectors, 0),(vector)llList2String(vectors, 1)]; // <--- does not work in lsl vm llSay(0,"LSL VM TEST VECTOR PARSE: " + (string)((vector)llList2String(vectors, 1))); } } This pattern breaks compatibility due to the self-referenced assignment, the vectors array becomes [<0,0,0>, <0,0,0>] instead of keeping the same values [<1,0,1>,<0,-0.192,2.479>]. The expected output of llSay here is <0,-0.192,2.479> like in Mono, but in lsl vm it outputs <0,0,0> Tested in Clawed region, current simulator: Luau 2026-06-09.27238848717 A simpler version that also breaks: default { state_entry() { list integers = [1,2,3]; integers = [llList2Integer(integers, 0)]; llSay(0, llList2String(integers, 0)); // Expected Output: 1, Actual: 0 } } Some further observations from Suzanna: Another example, tested on the Beta grid, Luau 2026-07-24.30110090421: default { state_entry() { list myList = ["test"]; myList = [myList == []]; // myList should be [0] llOwnerSay((string)myList); // --> 1 } } When the list being assigned to is also used inside the expression, its value is evaluated to an empty list. I think the bug comes from here: https://github.com/secondlife/slua/blob/ab883b7072887e73d5f962bd6d35467d098276d8/Compiler/src/LSLCompiler.cpp#L921-L964 where the destination list is assigned a new empty table before evaluating the expression.

When drag-copying an object containing a halted LSL-Mono script, the script in the new copy is also halted. This is the desired behavior. When drag-copying an object containing a halted SLua script the copied script may start running depending on A, the exact contents of the script, and B, whether one is copying a single instance or multiple instances. Procedure to reproduce: Step 1: Rez a block. Put the following script in the block, mark it Not Running, and save. local base = ll.GetPos() while true do ll.SetLinkPrimitiveParamsFast( LINK_THIS, {PRIM_POSITION, vector(math.random()-0.5, 0, 0) + (base + ll.GetPos())/2 } ) ll.SetLinkPrimitiveParamsFast( LINK_THIS, {PRIM_POSITION, vector(0, math.random()-0.5, 0) + (base + ll.GetPos())/2 } ) ll.SetLinkPrimitiveParamsFast( LINK_THIS, {PRIM_POSITION, vector(0, 0, math.random()-0.5) + (base + ll.GetPos())/2 } ) ll.SetText( tostring(ll.GetPos()-base), vector(1,1,1), 1 ) end--while Drag-copy the object horizontally several times. Observe that the script remains halted. Select the newly created group of objects. Drag-copy the group vertically several times. Observe that some or all scripts in the new copies spontaneously start running. Step 2: Delete the first group. Rez a new block and put the following nearly identical script in it. (Difference is ll.SetText argument in line 6.) Again, mark it as not running and save. local base = ll.GetPos() while true do ll.SetLinkPrimitiveParamsFast( LINK_THIS, {PRIM_POSITION, vector(math.random()-0.5, 0, 0) + (base + ll.GetPos())/2 } ) ll.SetLinkPrimitiveParamsFast( LINK_THIS, {PRIM_POSITION, vector(0, math.random()-0.5, 0) + (base + ll.GetPos())/2 } ) ll.SetLinkPrimitiveParamsFast( LINK_THIS, {PRIM_POSITION, vector(0, 0, math.random()-0.5) + (base + ll.GetPos())/2 } ) ll.SetText( tostring(os.clock()), vector(1,1,1), 1 ) end--while Again, drag-copy the object. Observe that the new copy starts running immediately every time. As you can imagine, this bug defeats attempts to start a group of test scripts together, or to precisely place a group of objects containing scripts that will move the objects before starting.

While SLua is still in development, would it be possible to make pcall and xpcall catch all errors, including the old LL error? Currently, the error is ignored, the test is bypassed, and an error window pops up. This is not the expected behavior when using pcall. Both the new and old functions should appear to interact with each other in both directions. Compile this: local success, errormsg = pcall(ll.StartAnimation, "none") if not success then print(errormsg) end

After running continuously for several weeks, my emulator script halted with this error: A Simple Sun-Earth-Moon emulator.: 0.3 [script:Sun-Earth-Moon demo] Script run-time error Failed to perform mandatory yield lua_script:159 function emulation_step [C] function _tick [C] function timer_event_wrapper [C] function _handleEvent The script, or an earlier version thereof, has halted similarly on at least two previous occasions. This, however, is the first time I've been on Sim when the crash occurred to receive the error message. Full script @ https://pastebin.com/PAg61t1K The instance of the object that crashed is at https://maps.secondlife.com/secondlife/Builders%20Brewery%20Sandbox/36/69/498 Anyone may take a full perms copy. I have not reset the script.

This menu has 2 items for recompiling LSL scripts under the 2 old VM's. It should also have the new VM: Recompile Scripts (LSL) Recompile Scripts (Mono) Recompile Scripts (Lua) Currently, I need to open every script and change it's vm, press save, close --- Also, I noticed 3 bugs with Recompile scripts: It sets not-running scripts to running (I had them not running for a reason) Scripts recompiled to LSO2 this way do not show the correct vm when you open the script. Most of them say "LSL: Mono". This one said "SLua": default { state_entry() { llOwnerSay(llGetScriptName() + " " + (string)llGetMemoryLimit()); }} Lua (the language) scripts are skipped and not recompiled. The new "Recompile Lua" menu item should not skip those

it would be nice if the uuid table had a generate function, similar to ll.GenerateKey . Mostly I've wanted it when I'm running slua offline, and don't have any uuid's available like ll.GetOwner Though, I could just use NULL_KEY and IMG_USE_BAKED_AUX1 and such there for testing, so, maybe this isn't a compelling reason

There are a few function that would be good to have through the viewer web socket for smoother integration with external editors. Requests - web socket endpoints List Open script editors with editor id 's (This is sort of done, but only open scripts that are also currently externally edited it might be nice to list all open ones) Get currently selected object id List content asset id, asset type, name of an object id to allow for opening scripts Open script editor by asset id to open a script from an object return editor id Get contents of open script editor by editor id Get object id, asset for an open script editor by editor id Send contents to and open editor by editor id to save Events - Things the socket can announce to subscribers New object selected - object id, inventory content New script editor opened - editor id, object id, asset, text content General Add config to allow the websocket to be opened when editing even if there are no scripts open yet, to allow for external tools to sync to viewer when it starts editing, and stay open if there are still subscriptions after, as it currently does. Given these endpoints it should be possible to make a fairly integrated setup in any editor, that would allow you to open related scripts and edit them seamlessly, and would also allow bypass the fiddly aspect of dealing with the current temp file system. For instance the current vs code plugin could list a virtual workspace that represents the sl viewer, and show a tree view of object content for the user to open and edit.

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.