📃 SLua Alpha

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

Create a new script in inventory (not a prim): default { state_entry() { llOwnerSay(llGetScriptName()); } } Select Compiler > LSL Mono Save Close and re-open the script Compiler now says "LSL 2025 VM" (incorrect) Drop the script in a prim Open the script in the prim Compiler now says "LSL Mono" (correct) "LSL Legacy LSO2" also has this issue. "LSL 2025 VM" and "SLua" do not

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.

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.

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.