📃 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.

Hello, I have technical questions regarding SLua timer behavior and recursive/self-rescheduling callbacks. I’m using the following pattern, where a function schedules itself again using LLTimers:once(). The snippet below is a highly simplified version of the real use case, included only to demonstrate the issue (I’m aware of LLTimers:every()). ```lua local main main = function() ll.SetText(tostring(ll.GetTime()) .. "\n" .. tostring(ll.GetFreeMemory()), vector(1, 1, 1), 1) LLTimers:once(1, main) end main() ``` Issue observed With this code, ll.GetFreeMemory() steadily decreases over time, as if memory is being accumulated or not released correctly. Why I’m asking (comparison with LSL habits) In LSL, it’s very common to avoid recursive loops by using llSetTimerEvent(x) —the timer event triggers again later without building up a recursive call chain. So from an LSL perspective, the pattern “schedule again in 1 second” is typically considered safe and non-recursive in practice. With SLua + LLTimers:once() , I expected a similar behavior (a clean callback invocation each tick), but the memory decrease makes me wonder if this pattern is internally treated as a form of recursion that keeps references/callbacks alive longer than expected. Questions Is this memory decrease expected behavior when using LLTimers:once() in a self-rescheduling callback? Internally, are timer callbacks handled in a way that could retain closures/references across calls (causing memory to accumulate)? Would it be possible (now or in the future) for timer callbacks to be executed in a way that breaks this “recursive” chaining—e.g., treated like an isolated execution context (separate thread-like handling or a coroutine-style dispatch)—so that each timer tick runs cleanly without retaining the previous call context? Real use case The simplified example above is only to demonstrate the problem. In real scripts, I have a controller function that checks multiple conditions and schedules follow-up actions with different delays (sometimes calling other functions that schedule additional timers, and sometimes rescheduling the original function). This makes LLTimers:every() unsuitable in many cases, because the next delay depends on the outcome of the current step. Thanks in advance for any clarification on whether this is expected. For now, as a workaround, I use linked messages to schedule new timers that execute the desired functions after a given delay.

I'm attempting spawning a scripted arrow using ll.RezObjectWIthParams ll.RezObjectWithParams(projectile, { REZ_PARAM, 0, REZ_FLAGS, bit32.bor(REZ_FLAG_PHYSICAL, REZ_FLAG_DIE_ON_NOENTRY, REZ_FLAG_NO_COLLIDE_OWNER, REZ_FLAG_TEMP, REZ_FLAG_BLOCK_GRAB_OBJECT), REZ_POS, projectilePosition, false, true, REZ_ROT, avatarCameraRot, false, REZ_VEL, vector(currentStance.Speed, 0.0, 0.0), true, false, REZ_LOCK_AXES, vector(1.0, 1.0, 1.0), }) When attempting to rez a non-scripted prim, the object_rez event is fired with little delay [9:23 AM] zCS#Slua Bow#TEST-0.01: Object rezzed: daaf9d30-d42b-43bd-5467-f6e649d18b08 [9:23 AM] zCS#Slua Bow#TEST-0.01: Spawn time: 0.17778599995654076 [9:23 AM] zCS#Slua Bow#TEST-0.01: Object rezzed: ee6945cb-7234-2879-96bc-37900ec01782 [9:23 AM] zCS#Slua Bow#TEST-0.01: Spawn time: 0.17782800004351884 [9:23 AM] zCS#Slua Bow#TEST-0.01: Object rezzed: ba83213a-4c80-ce3e-a513-e550aed047d0 [9:23 AM] zCS#Slua Bow#TEST-0.01: Spawn time: 0.15552400005981326 However, when dropping in a script to the arrow (in this case the default Luau script) there is a delay in the script in the arrow becoming active along with the event. [9:26 AM] zCS#Slua Bow#TEST-0.01: Object rezzed: a37f1021-6c51-4aab-a569-37dd55c26103 [9:26 AM] zCS#Slua Bow#TEST-0.01: Spawn time: 3.066867999965325 [9:26 AM] zCS#Slua Bow#TEST-0.01: Object rezzed: cc467eb3-5715-bfe9-e637-4e16ce34317e [9:26 AM] zCS#Slua Bow#TEST-0.01: Spawn time: 3.066815000027418 [9:26 AM] zCS#Slua Bow#TEST-0.01: Object rezzed: 6ab801c0-43bd-4bed-6a68-f701f64d46d6 [9:26 AM] zCS#Slua Bow#TEST-0.01: Spawn time: 3.066683000070043 In the past, there was a similar problem when using Mono, so a lot of the time LSO was used for projectiles, however here I am trying to go full Luau.

Run the following script: list items = [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 236, 237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252, 253, 254, 255, 256, 257, 258, 259, 260, 261, 262, 263, 264, 265, 266, 267, 268, 269, 270, 271, 272, 273, 274, 275, 276, 277, 278, 279, 280, 281, 282, 283, 284, 285, 286, 287, 288, 289, 290, 291, 292, 293, 294, 295, 296, 297, 298, 299 ]; default { state_entry() { llOwnerSay("254: " + llList2String(items, 254)); llOwnerSay("255: " + llList2String(items, 255)); /* integer i; for (i = 0; i < 300; i++) { llOwnerSay((string)llList2Integer(items, i)); } */ } } Under LSL Mono, it prints, correctly: [10:39 PM] Object: 254: 254 [10:39 PM] Object: 255: 255 Under LSL 2025 VM, it prints, incorrectly: [10:39 PM] Object: 254: 254 [10:39 PM] Object: 255: 256

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?

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

myRequestId = ll.HTTPRequest(myUrl, { HTTP_BODY_MAXLENGTH, 16384 }, "") Currently the maximum is 16384 in VM Mono and 4096 in VM LSO. In VM Luau, with more script memory, the maximum could be 32k or 64k.