📃 Lua Alpha

Script development on one's local computer is now quite practical, with a local slua system and VSCode. Scripts developed locally often need to now whether they are running in Second Life or locally, to skip some operations or substitute behavior. There are hacks one can use to determine whether the script is in world or not, such as checking _G.ares for nil, or ll.Euler2Rot , etc. Those are all subject to change more or less arbitrarily. Please provide a "guaranteed" and efficient way to determine whether a script is running locally or in world. Thanks!

Create a new prim, and Create a new script with the following text: ] Compile it with "LSL Legacy". Close and reopen it. The compiler now reads "LSL on Mono" What all the options do: "LSL Legacy" -> "LSL on Mono" "LSL on Mono" -> "LSL on Mono" "LSL on Lua" -> "LSL on Mono" "Lua" -> "LSL on Mono" Viewer: Second Life Release 26.4.0.33894281402 (64bit) Sim: Luau 2026-07-24.30110090421

REGION: https://maps.secondlife.com/secondlife/Lua%20Beta%20Void/237/210/23 Building these little battle pets i have them connected to my server llownersay is being used to relay the server comms and the script functions in life time so its spamming my chat, i have 2 pets out and after 20 seconds or so of ownersay spam the lua alpha viewer shutters and freezes up, (not to sure if it is a bug) steps to replicate create box add script have ownersay spam in some way -issues- (must also state this is ALOT of owner say its relaying everything this object is doing with itself and what its sending and receiving from my backend service.) i added a chat command to turn off debug and no issues have happened since turning off ownersay via this command. (not super sure if this is a bug, but ive never had it happen with lsl)

While trying to stress test / benchmark a comparison for (string) list and llDumpList2String , I came across a register exhaustion for a script in lsl-luau that works in mono. I'm reporting both as one canny because I'm unsure if these are related. A) First, for the benchmark: In LSO: === list-to-string benchmark: 100 iterations x 300 items === (string)list total = 1040.432007 ms mean = 10.404320 ms llDumpList2String total = 1896.921143 ms mean = 18.969212 ms ratio (string/dump) = 0.548485x === DONE === In Mono: === list-to-string benchmark: 100 iterations x 300 items === (string)list total = 226.023000 ms mean = 2.260230 ms llDumpList2String total = 316.186000 ms mean = 3.161860 ms ratio (string/dump) = 0.714842x === DONE === In LSL-LUAU: === list-to-string benchmark: 100 iterations x 300 items === (string)list total = 2287.902000 ms mean = 22.879020 ms llDumpList2String total = 589.087000 ms mean = 5.890871 ms ratio (string/dump) = 3.883810x === DONE === === list-to-string benchmark: 100 reps x 500 items === (string)list total = 4536.675000 ms mean = 45.366750 ms llDumpList2String total = 1022.474000 ms mean = 10.224740 ms ratio (string/dump) = 4.436957x === DONE === Something about how casting a list to a string is way worse in lsl-luau. My thought was that it's likely something that could be optimized if llDumpList2String is about 4x faster already. B) Second, a test script of the discrepancy is the following default { state_entry() { integer i = 1; string s = (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i ; llOwnerSay(s); } } It prints "1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111" in mono, but in lsl-luau it fails to compile with "Out of registers when trying to allocate 1 registers: exceeded limit 255" I doubt there are many real use cases where this would have an impact after switching off mono, but it is still a notable difference.

Something about the way lsl-luau handles state changes differs from Mono. It appears like the state is changed immediately instead of after the whole event is handled. Take this test script: integer screwthisimout() { if (TRUE) state other; return 13; } default { state_entry() { integer r = screwthisimout(); llOwnerSay("after state change, r=" + (string)r); } } state other { state_entry() { llOwnerSay("entered state other"); } } In mono, you see both llOwnerSay printed, State_Entry fully finished, the output is: after state change, r=0 entered state other in lsl-luau, state_entry doesn't get to finish and only outputs: entered state other Tested on the latest 2026-07-24 luau channel

Here is a list of observed differences between Mono and LSL VM: float nan = (float)"nan"; llOwnerSay((string)(nan >= 1.0)); // Output: LSO=math error Mono=1 LSL-LUAU=0 llOwnerSay((string)(nan <= 1.0)); // Output: LSO=math error Mono=1 LSL-LUAU=0 And a test script: integer param(integer p) { return p++ + p; } default { state_entry() { integer a = 1; llOwnerSay("1 (Mono = 0): " + (string)((a = 2) == a)); // Output in lsl-luau: 1 a = 1; llOwnerSay("2 (Mono = 1): " + (string)(a++ == a)); // Output in lsl-luau: 0 llOwnerSay("3 (Mono = 2): " + (string)param(1)); // Output in lsl-luau: 3 // float->int cast float f = 0.7; llOwnerSay("4 (Mono = 7): " + (string)((integer)(f * 10.0))); // Output in lsl-luau: 6 integer i = 16777217; float z = 0.0; llOwnerSay("5 (Mono= 16777216): " + (string)((integer)(i + z))); // Output in lsl-luau: 16777217 // bit shifts integer s = 32; llOwnerSay("6 (Mono = 1): " + (string)(1 << s)); // Output in lsl-luau: 0 llOwnerSay("7 (Mono = -2147483648): " + (string)(1 << -1)); // Output in lsl-luau: 0 llOwnerSay("8 (Mono = 4): " + (string)(8 >> 33)); // Output in lsl-luau: 0 } }

String.gmatch can become stuck in use after an error. Take this example debug script: local it = string.gmatch("hello world", "(%a)%2") local ok1, err1 = pcall(it) print("call 1:", ok1, err1) local ok2, err2 = pcall(it) print("call 2:", ok2, err2) It outputs: call 1: false invalid capture index %2 call 2: false gmatch iterator is already in use While I would expect: call 1: false invalid capture index %2 call 2: false invalid capture index %2

To set the world rotation of an object to <r, p, y> requires creation and multiplication of three rotations. These objects, being four cells, all go on the heap. If ll>SetLinkPrimitiveParamsFast had, e.g. PRIM_ROT_FROM_RPY, <r,p,y>, the entire operation could be done using vectors, which live on the stack. For objects that adjust their position and rotation frequently, trains, etc., the savings in garbage creation would be substantial. Thanks!

Please add compatible implementations of the vector- and rotation-related functions such as ll.Rot2Euler, ll.Euler2Rot, ll.Axes2Rot, and so on. This will greatly facilitate the development and testing of solid Lua code off-world, with the confidence that the same code will work in-world. Currently I am using cover functions like this: ~~~ local function rot_to_euler(q) if ll.Rot2Euler then return ll.Euler2Rot(q) end local w, x, y, z = q.s, q.x, q.y, q.z -- etc etc ~~~ This ensures that the real presumably much faster functions are used in world, but of course equivalent results depend on my possibly faulty implementation of the function. I typically test this in world by running lots of values through them. Tedious at best. Thanks!

SL rotations are unit rotations. As such, they can readily be stored in a vector, dropping the s field, and reconstructing it as needed. Non-physical vehicles, such as trains, create multiple rotations per second, as do many other dynamic objects. A polymorphic vector-sized rotation could fit in the Slua stack, as do vectors. If accepted, for example, in ll.SetLinkPrimitiveParamsFast, these vector-sized rotations would reduce garbage creation substantially. Since the math would be done inside C++, reconstituting the s field would quite likely be a very reasonable trade off.