📃 SLua Alpha

Rather than having in built "freezes" in certain functions like object rez / ll email etc, which are trivially circumventable by "LINK_MESSAGE"ing another script in the same prim and having that other script swallow the delay (providing a 'burstable' limit on these calls) these could be better handled in slua by reworking how these delays are implemented - perhaps on a per prim or per script setting where these calls can be made at "no cost" up to some specific rate after which they stall or fail (for example the way HTTP requests can be performed - there is no function delay here but there is still an overall limit on HTTP requests) The work around of having often multiple 'worker' scripts that just listen for a link message then execute the call to llEmail / etc has always been a bodge, but also rather necessary one if you don't want your main server script to become unresponsive regularly, which is quite important for a simultaneous multi user server style script (e.g. providing a region wide service to all players, the main script here can not be stalled without noticable impact to the players and yet some of these functions with delays in are needed for operation). Made a longer post here https://community.secondlife.com/forums/topic/530018-of-functions-with-delays/ Since so much is changing in the lua implemented stuff we could use this opportunity to redefine or rework how these function delays work, /only/ for pure lua scripts compiled using the new lua mode, while legacy LSL to lua / LSL mono / LSL classic scripts can maintain their previous behaviour regarding delays. This would be great to avoid what is essentially a "gotcha" that new scripters sort of 'need to know' how to work around to have a performant system that needs to use these delayed calls, as well as avoiding the wasted overhead of multiple worker scripts with their overheads and the time wasted in link messaging (especially since all the worker scripts receive all link messages even though only one of them will take up the work) Would just be a great and rare opportunity to revisit a rather archaic piece of the scripting languages implementation that just doesn't really work as advertised anyway once you know of the bypass by offloading to worker scripts, not often breaking changes can be brought in to a new language checkpoint. If this isn't clear enough please let me know and I'll give some better examples or something but I assume this fairly trick is widely known.

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.

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

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.

I have just begun tinkering with SLua and I love the potential. However, one weak point of scripting in SL (both both LSL and SLua) is the ability of scripts to interface with another. As far as I know, we still mainly use LLEvents.link _message and ll.MessageLinked. One issue I have with that is that all the parameters are strongly typed. If we could pass (at least one) dynamically typed parameter, we could pass object instances along, which would make it much more powerful. To name one simple use case: let's say we have various scripts that all need to show a menu with ll.Dialog. We could have a single script that can instantiate a "Menu" object and pass it back to the calling script, which can then implement it for that script's situation and run the predefined Menu:Show. Another use case might be that when clicked, a script creates an "Avatar" object and then passes that to one or more handler scripts (based on whatever criteria prevail) that can use that object in their own logic. Perhaps there is another way in SLua but I have not yet found it in the docs, but I am of course happy to be educated further. Something like this would enable us to make much more loosely coupled and dynamic and reusable systems in SL scripting.

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() .

A way to add two or more array tables without requiring extra temporary memory. table.extend(t1, t2) Appends all elements of array t2 to the end of array t1 The array t2 is cleared and its memory released. Elements are moved directly to avoid intermediate duplication. Working like this, but without using extra memory during the process: extend(t1, t2) table.move(t2, 1, #t2, #t1 + 1, t1) table.clear(t2) -- but without preserving the allocated space return t1 end or better: table.extend(t1, ...) Appends the elements of each additional array to the end of array t1, in the order provided. The source arrays are cleared and their memory released. Elements are moved directly to avoid intermediate duplication.

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

SLua has no means of concatenating tables, this makes several functions designed for LSL incredibly unwieldy to use. A common practice for instance is to to loop a function call and build up a list of parameters append them to an existing list, then once done send it all to SetLinkPrimitiveParamsFast. SLua also struggles somewhat for memory and hits out of memory errors on lists that aren't incredibly long compared to LSL. Due to the table memory allocation doubling all of a sudden, which for many users is an enourmous footgun, as tabl[#tabl+1] = 1 taking their script form 64k memory to OOM is incredibly counter intuative. This leaves slua looking no better than LSL to many scripters for a very common task in SL. Until either better more 'lua' api's exist, or table memory allocation can be changed, it would be nice if the functions could accept nested tables and flatten them. Proposal ll.SetLinkPrimitiveParamsFast( 1, { PRIM_COLOR, {1,vector(1,0,0),1.0}, {PRIM_TEXT, "Text", {vector(1,1,1)},1.0}, PRIM_SIZE, vector(1,1,1) }) -- OR ll.SetLinkPrimitiveParamsFast( 1, { {PRIM_COLOR, 1,vector(1,0,0),1.0}, {PRIM_TEXT, "Text",vector(1,1,1),1.0}, {PRIM_SIZE, vector(1,1,1)} }) Would get flattened to ll.SetLinkPrimitiveParamsFast( 1, { PRIM_COLOR, 1,vector(1,0,0),1.0, PRIM_TEXT, "Text",vector(1,1,1),1.0, PRIM_SIZE, vector(1,1,1) }) This would make using SetLinkPrimitiveParams allot less painful, and also help with things like - LinkParticleSystem - RezObjectWithParams - SetAgentEnvironment - HTTPRequest This would also help aleviate the memory impact of LONG tables for set linkprimitive params, by allowing a scripter to break up their long list into several smaller ones and send them together. Not always, but 10 tables of 8 keys are 2560 bytes compared to 80 keys taking 4096 with the memory doubling tables do as you expand them. There is of course... one major caveat to this, the flattened table, while it exists needs to be be counted against the script that's running >.>

I’m rewriting some of my scripts in SLUA and noticed that strings can sometimes be auto-cast to numbers. Then if in an old script, I read numeric values from a CSV I won’t explicitly convert them back to integer / number before to use them. The result is that it sometimes works and sometimes doesn’t, depending on the function. (And yes, I know we have JSON_ARRAY that works very well and I rarely use a CSV for numbers) With LSL/Mono in any case we had to cast to integer with llList2Inger(l, x) but with SLUA we can simply get the value from the table: local data: {} = mess:split(",") ll.SetColor(vector(0, 1, 0), data[1]) -- data[1] is a string, but this work. But ll.SetLinkPrimitiveParamsFast() fails with a type error I’m wondering if this is because, in the second case, the value is inside a table (parameter list), and auto-casting is not applied the same way. It would be nice if the behavior was consistent: either always auto-cast, or never auto-cast. -- set white color on all sides ll.SetColor(vector(1, 1, 1), ALL_SIDES) local n: string = "0" -- set green color, "n" is auto-cast to integer ll.SetColor(vector(0, 1, 0), n) -- set red color, "n" is not auto-cast: -- arg #1 (face number) integer expected but string given. ll.SetLinkPrimitiveParamsFast(LINK_THIS, {PRIM_COLOR, n, vector(1, 0, 0), 1}) Is this expected behavior? If so, what’s the exact rule for when auto-casting does / doesn’t happen?