📃 Lua Alpha

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.

Texture alpha is treated as boolean by many scripts, and this worked in lsl: llSetAlpha(TRUE, ALL_SIDES); The equivilant does not work in lua: ll.SetAlpha(true, ALL_SIDES) In LSL the best way to toggle alpha was: llSetAlpha(!llGetAlpha(face), face); In Lua, the equivilant code is quite ugly: ll.SetAlpha(if ll.GetAlpha(face) ~= 0 then 0 else 1, face) The following almost works, and is less horrible, but it breaks if alpha gets accidentally set to some value other than 0 or 1: ll.SetAlpha(1 - ll.GetAlpha(face), face) If boolean alpha was implemented, it would become the pretty elegant: ll.SetAlpha(ll.GetAlpha(face) == 0, face) Inconsistenly, the following does work in Lua: ll.SetLinkPrimitiveParamsFast(LINK_THIS, {PRIM_COLOR, ALL_SIDES, vector.one, true}) Boolean alpha would require changing the following functions: ll.SetAlpha() ll.SetLinkAlpha() PrimParamsSetter.color() PrimParamsSetter.gltfBaseColor() Debatably, it would also affect particle and hovertext alpha, but I have no use case for that: ll.SetText() PrimParamsSetter.text() ParticleParams.alpha_begin ParticleParams.alpha_end

some ideas on how it could work: Required scripts are saved as a different type of script: modules, with a new compiler option: compile to "SLua scriopt" or to "Slua module". Modules are executed when required and return a value, with a return statement, for instance a table with functions and constants. Scripts call modules as myModule = require("Module name") , the returned value is assigned to the variable myModule , using the script's memory space. The module must be in the object contents with the script that requires it. If the module is not in the object, its running state is disabled, or it doesn't return a value, require() will return nil. Once it returns, the module is removed from memory and its variables are garbage-collected. Modules are executed synchronously, the main script is paused until the module returns. Modules don't receive events, any events that arrive while the module is executing are queued in the main script. Modules can't require other modules, only scripts can use require() .

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

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})

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

In the script editor, the dropdown gives 3 options for compiling LSL, and 1 for SLua. I think they would be better named: SLua LSL-128 (on SLua) LSL-64 (on Mono) LSL-16 (on LSO) "LSL-128" is clear, compact, and and easily distinguishable from both "Mono" and "SLua", which already have colloquial names. I also reversed the list to put them in order of most to least recommended Edited with input from Nexii Malthus, Suzanna Linn, and Kristy Aurelia

I'm reporting this one because we are looking for all the differences, but I don't think that it has any real use. // LSL Mono default { state_entry() { integer a = 2; (a *= 2.2); llOwnerSay((string)a); // --> 4 }} // LSL Luau default { state_entry() { integer a = 2; (a *= 2.2); // --> Script run-time error : cannot take result of integer *= float }} a *= 2.2; works in both, float f = (a *= 2.2); errors in both.