📃 SLua Alpha

This is the second time this problem has occurred for me. An object in inventory, with an SLua script that was working as expected when I picked it up, gives me a the following irregular error message when I rez the object: Rez Bug Demo [script:.Foxy Conga Line SLua -- Line Manager 1.02] Script run-time error Note that there is no line number or function name or traceback, just the above message. The script has an on_rez event handler that should reset the script on rez. After rezzing the script appears halted, it does not respond to touch or to the seated user's controls as expected. However, if I take the object back into inventory again and rez the new copy, the same error occurs. This indicates that the script is not properly halted, despite the runtime error and not responding to events. But if I use the SLua editor to manually reset the script without changes, it runs as expected. And if I take the now reset object into inventory and rez it again, it continues to run as expected. I've removed the animations and secondary script from the demo object, and set full permissions on both script and object , but I am unable to simplify the erring script without making the problem disappear. The object is in my inventory at Inventory/Objects/Rez Bug/Rez Bug Demo (the newest/full perms version) Its Asset UUID is 07675d99-deea-9e4c-bb4d-dee9e69c59e8 . Or you may contact me in world for a copy. Procedure to reproduce: Obtain the above object. Using the SLua Alpha Editor viewer, rez the object in world in an SLua enabled sim. Observe the anomalous runtime error message. Touch the object. Observe that it does not respond to touch. Take the object into inventory and rez the new copy. Observe the same behavior again. Edit the script, scroll to the bottom to confirm the on_rez and touch_start event handlers. Reset it without saving and without changes. Sit on the object. (This creates and populates the table the touch event reports from, otherwise the script will halt on a legit runtime error.) Observe that it now responds to touch with a print message. (Note: The print message will appear in your Script Error/Warning window, I've overridden print with my own version in my debug tools at the top of the script because routing error/debug messages to the local chat window is excessively messy, especially when dealing with a class full of students.) Use forward and left-right keys to move if you like. Observe that the object moves. The script is behaving as expected. Stand and take the object into inventory. Rez the new copy. Observe that there is now no anomalous runtime error. Sit and repeat above. Observe that the script continues to perform as expected. I'm not sure what your internal rules are regarding directly accessing user objects so, just in case: I hereby grant any LL personnel permission to access my inventory and/or obtain and examine the above named object by whatever means they may find convenient for the purpose of analyzing and responding to this report and correcting any bugs they may find. Thank-you, Sung Ali

Running on server: Luau 2026-01-06.20757451310 In successive calls of string.match, I often get a fatal error if I don't wrap string.match in a pcall: runtime error lua_script:3: String pattern too complex, timed out [C] function match The problem is that the only thing repeatable is that I may or may not get errors when running the code. local function getStringMatch(s) local status, k, v repeat status, k, v = pcall(string.match, s, "(%g+)%s*=%s*(%g+)") if not status then print(k) end until status end local keys = {} for i = 1, 10 do table.insert(keys, tostring(ll.GenerateKey())) end for k, v in keys do print(k) getStringMatch(v) end This is basically a useless example, except to trigger the issue. gmatch should return the captures, the original string if no captures, or nil. This example will never find a match, but I don't believe string complexity is the issue, and I don't believe its timing out because it happens very fast. But, if a failure is triggered, I can recall the very same match again and get success, without providing any delays in the code.

If a region is moved to SLua, and in the past had objects that used the money debit permission, this seems to be forgotten on the transition. This can break vendor objects, such as CasperVend or SmartBots franchise terminals.

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

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

Using strict type checking doesn't display warnings in the Script Warning/Error window --!strict local function add(a: number, b: number): number return a + b end local result1: number = add(3, 4) -- Should work fine local result2: number = add("3", 4) -- Should trigger a type error in strict mode This code in Luau/Roblox displays this warning: Type Error: (8,29) Type 'string' could not be converted into 'number'

The SLua code below demonstrates the problem. Two vectors, multiplied, results in a vector answer rather than a number. v1 = vector(9, 2, 7) v2 = vector(4,8,10) v3 = v1 * v2 ll.OwnerSay(typeof(v3) .. ": " .. tostring(v3)) Program output: vector: <36.00000, 16.00000, 70.00000> Reason for identifying as a bug: The SL Wiki indicates that the dot product should return the sum of the products of the vector elements. In this case, the expected result should be 122.0. What is returned instead is simply the vector of the products of each element.

Very, very minor bug. Currently "goto" highlights as a keyword in the script editor, and gives the helper text, "Lua goto statement: jumps to a specified label" goto is not implemented in Luau, and this is not me asking for it to be implemented. But right now the script editor is implying that goto will work, and it doesn't. Perhaps there are some other functions from Lua that aren't implemented in Luau where this is also an issue? I couldn't find anything else, but it's possible.