📃 SLua Alpha

Second Life Project Lua Editor 7.2.3.20806470783 (64bit) The in-world editor in SLua highlights the old LSL constants TRUE and FALSE. It's confusing for students who are learning SLua booleans.

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

If you enable a script that was in disabled state and has a running timer, the second timer tick after waking up may end up happening much sooner than specified. I'm unsure if this is by spec or a bug, but Suzanna Linn's guide at least specifies timers should never tick faster than their specified rate. Repro: local t = 0; local last = os.clock() LLTimers:every(1, function() t+=1 print("tick#", t, "delta", os.clock()-last) last = os.clock() end) Play with the script running checkbox, turning it on and off, and observe the reported tick delta for the second tick. As one example, after having the script disabled for over a minute, the second tick after waking up was only 0.37 seconds instead of ~1. This behavior is not present under LSL-Mono or LSL-SLua, second tick and further ticks are always ~1 s.

LSL has an awkward bug / behavior with touch_start If a user is already touching a prim, no other users touch_start s will trigger, only their touch and touch_end events. This is awkward and seemingly undocumented at least on the wiki. While it may not be something that can be changed in lsl, it would be nice to clear this up in slua and not carry this "bug" over LSL script list ks = []; handle(string name, integer t) { while(t--) { string evnt = name + ": " + llDetectedName(t); if(llListFindList(ks,[evnt]) == -1) { ks += evnt; } } ks = llListSort(ks,1,1); llSetLinkPrimitiveParamsFast(0, [PRIM_TEXT,llDumpList2String(ks,"\n"),<1,1,1>,1]); llSetTimerEvent(5.0); } default { state_entry() { llSetLinkPrimitiveParamsFast(0, [PRIM_TEXT,"",<1,1,1>,1]); } touch_start(integer t) { handle("touch_start",t); } touch(integer t) { handle("touch",t); } touch_end(integer t) { handle("touch_end",t); } timer() { ks = []; llSetTimerEvent(0.0); llSetLinkPrimitiveParamsFast(0, [PRIM_TEXT,"",<1,1,1>,1]); } } SLua script local ks = {} local clearHandle = nil local function clear() ll.SetLinkPrimitiveParamsFast(0, {PRIM_TEXT,"",vector.one,1}) ks = {} end local function handler(name) return function(events:{DetectedEvent}) for _,event in events do local evnt = `{name}: {event:getName()}` if not table.find(ks, evnt) then ks[#ks+1] = evnt end end table.sort(ks) ll.SetLinkPrimitiveParamsFast(0, {PRIM_TEXT,table.concat(ks,"\n"),vector.one,1}) if clearHandle then LLTimers:off(clearHandle) end clearHandle = LLTimers:once(5, clear) end end clear() LLEvents:on("touch_start", handler("touch_start")) LLEvents:on("touch", handler("touch")) LLEvents:on("touch_end", handler("touch_end")) Both of these scripts require 2 users to click, and you can see that only the person that clicks first gets a touch_start set text.

LSL-Mono is specced (edit: I can't actually find where it's specified in writing to do that, but it's clearly what it does... maybe it's Mono that's been wrong all along, but too late to fix now) to return INT_MIN when trying to cast floats that are out of 32-bit integer bounds. LSL-SLua doesn't, repro: default { state_entry() { integer i; llOwnerSay("---"); for(i = 9; i < 17; ++i) llOwnerSay((string)((integer)(PI*llPow(10, i)))); } } Under Mono, every cast returns INT_MIN, under LSL-SLua you get varying values. llFloor, llCeil and llRound have the same specified OOB result, and work correctly for both VMs.

Please increase the auto delete time from 4 hours up. I recommend 8-16 hours. At least doubled to 8 if not 16. The sandbox regions are spacious and don't get that much traffic right now. Plus the reason is that scripting for SLua is a much more time intensive task , it is not that unlikely to be coding for +4 hours or coming back to a project, or hanging around scripters/content creators. Another is that this will encourage people seeing SLua projects that people are working on. Much like the beta grid has lots of awesome projects showcasing what projects people are working on.

default { state_entry() { list a = ["hello", "world"]+llSleep(0); llOwnerSay((string)llGetListEntryType(a, -1)); // 8??? not a defined return value llOwnerSay((string)a); // attempt to concatenate string with nil } } Under LSL-Mono, this is a type mismatch at compilation. Trying to insert a void return value into a list directly is properly caught either way, it's just the appending that acts up.

default { state_entry() { integer a = 7; integer b = a = 3; llOwnerSay((string)b); } } This works correctly under LSL-Mono and prints 3. Under LSL-SLua it gives an "unable to cast!" runtime error. Interestingly, doing "b = (a = 3)" works correctly under both VMs. The same applies for all other assignments as expressions as well (+=, -=, *=, /=, %=).