📃 SLua Alpha

I was debugging stuff and hid a block behind "if false then ... end". Upon saving the script, the region crashes and takes a long time to recover. As for why I wasn't commenting it out instead, I have no good explanation other than "block is too long, comments look uglier in my editor". Said code included a call to LLTimers:every with an anonymous function as the first bit. I culled down the script this this minimal repro (the function call before may not even be necessary, nor the contents of the timer function): local function setup() end setup() if false then LLTimers:every(3, function() ll.SetLinkPrimitiveParamsFast(LINK_THIS, {PRIM_TEXT, "hi!", vector(1, 1, 1), 1}) end) end I promise to stop testing after crashing 3 out of 4 regions.

Feels like a bit of a pitfall to begin with: we used to turn timers off with delay 0, not that there is any reason not to interpret delay 0 as "call the timer as soon as possible" but it's not consistent with the old logic. However, it also does not work properly: try this script: local count = 0 local stime = 0 function timer() count += 1 ll.SetLinkPrimitiveParamsFast(LINK_THIS, {PRIM_TEXT, tostring(count), vector(1, 1, 1), 1}) if count >= 100 then -- never reached at 0.0 delay, will be reached at 0.001 ll.OwnerSay(`finished in {os.clock()-stime} s`) LLTimers:off(timer) end end function LLEvents.touch_start() -- disable this event and the count reaches higher, but not 100 ll.OwnerSay(`current count = {count}`) end stime = os.clock() -- set delay to 0.001 (or anything sub-server frame) to have functional -- "call as soon as possible" rate LLTimers:every(0.0, timer) The count will never reach 100 and terminate in my tests, it's like the timer gets jammed. Using a delay of 0.001 (or anything > 0 but sub-frame) will achieve the expected "as soon as possible" timing. Also disabling the touch event lets the timer count higher (still not 100), so there's some dependency on the event system on the whole there.

Right now, vectors and quaternions encode to strings and decode to strings with the "<... >" format. Likewise UUIDs decode to strings. This is a major nuisance to scripters when decoding tables with embedded vectors, quaternions or UUIDs, requiring special decoding functions in each and every script using them. The underlying problem is that at present there is no way to differentiate between an encoded vector, quaternion, or UUID and the equivalent string value. i.e vector(1,2,3) and "<1,2,3>" both encode to "<1,2,3>". I'd like to propose a variation to encode/decode, (call them lljson.pack and unpack or better, perhaps, add an optional EncodingType argument to encode and decode), that when a vector or quaternion is encountered, encodes them as they are now. UUIDs would then be encoded by adding the same <> delimiters around the current UUID string. When a string starting with < and ending with > is encountered, encode it adding an extra < and > at each end, then decode such strings by removing the added < and >. Then the vectors, quaternions, and UUIDs can be uniquely identified as such by the undoubled delimiters and the appropriate internal format and decoded directly to the appropriate type. This would allow the encoding and decoding of all SLua types in tables without special intervention by the scripters--significantly simplifying scripting such operations and greatly improving performance (one optimized pass through the data in C, rather than one in C followed by one of random scripter quality in SLua) when passing tables between scripts, or storing and retrieving tables in Linkset Data. The only reason for keeping encode and decode as they are now is for the sake of compatibility with external json operations and even then if vectors, quaternions, or UUIDs are involved the proposed operations would likely be superior as it would be necessary to make accommodations for these types on the remote end anyway.

default { state_entry() { state two; } state_exit() { llOwnerSay("exit default"); } } state two { state_entry() { llOwnerSay("entry two"); } } In LSL/Mono: -- > exit default -- > entry two In LSL/Luau -- > entry two

Internally there is only LLTimers:on(), but it could be confusing for beginners: LLTimers.every(1, print) -- with a point -- > invalid argument #1 to 'on' (LLTimers expected, got number) LLTimers:every(1, myUndefFunc) -- > invalid argument #3 to 'on' (function or callable table expected, got nil) If :every() is the prefered one, could the internal function be every() instead of on()?

Using LSL:Luau when incrementing a integer declared at script level, incrementing it with int++ seems to do nothing. ++int seems to work the same across both LSL:Mono and LSL:Luau See : https://github.com/secondlife/slua/issues/23 Reproduction steps The following script halts in LSL:Luau : default { state_entry() { integer i; while(i < 1) { i++; llOwnerSay("Ping " + (string)i); llSleep(1.0); } } } This one does not: integer i; default { state_entry() { while(i < 1) { i++; llOwnerSay("Ping " + (string)i); llSleep(1.0); } } }

Modify the LLEvents table, calling :on or :off Follow that with function call with a forced delay (ll.Sleep, ll.InstantMessage, etc.) Modify the LLEvents table again The 2nd modification of the events table triggers a yield error, because in step 2 we executed a call with a forced delay. This could be the ll.Sleep, or any ll.* function described as having a forced delay. LLEvents:on("touch_start", print) ll.Sleep(0.001) LLEvents:on("touch_start", print) The error generated is: Object [script:New Script] Script run-time error runtime error Failed to perform mandatory yield lua_script:3

Listener doesn't work after the first message: local function listening(channel, name, id, msg) print(msg) end LLEvents:on("listen", listening) ll.Listen(1, "", "", "") [ typing: /1 hello] -- > hello [ typing: /1 hello] ( nothing ) --- Both listeners don't work after the first message to any of them local function listening(channel, name, id, msg) print(msg) end LLEvents:on("listen", listening) ll.Listen(1, "", "", "") ll.Listen(2, "", "", "") [ typing: /2 hello] -- > hello [ typing: /1 hello] ( nothing ) --- Event handlers are in place: local function listening(channel, name, id, msg) print(msg) end local function touching(events) for _, eventName in LLEvents:eventNames() do for _, myHandler in LLEvents:listeners(eventName) do print(`{eventName} : {debug.info(myHandler,"n")}`) end end end LLEvents:on("listen", listening) LLEvents:on("touch_start", touching) ll.Listen(1, "", "", "") [ typing: /1 hello] -- > hello [ touching ] -- > touch_start : touching -- > listen : listening [ typing: /1 hello] ( nothing ) --- This doesn't work, listeners are removed after calling the event handler: local function listening(channel, name, id, msg) print(msg) ll.Listen(1, "", "", "") end LLEvents:on("listen", listening) ll.Listen(1, "", "", "") --- This works: local function listening(channel, name, id, msg) print(msg) LLTimers:once(0.1, function() ll.Listen(1, "", "", "") ll.Listen(2, "", "", "") end) end LLEvents:on("listen", listening) ll.Listen(1, "", "", "") ll.Listen(2, "", "", "")

On damage event is only triggering once for a script and needs the script to be reset to work again This happens in both SLua and LSL: Luau This does not happen in LSL If you setup a once registered event handler on each click, those will report correctly but only if you dont have an existing on registered handler Reproduction Be in a sim with allow damage adjustment set to true - and in a parcel with damage enabled Create a prim Take a copy Add the copy to the prim's inventory (leave it's name as Object ) add this script to the prim LLEvents:on("touch_start", function(detected) ll.OwnerSay(`{#LLEvents:listeners("on_damage")}`) ll.RezObjectWithParams( "Object", { REZ_FLAGS, bit32.bor(REZ_FLAG_TEMP,REZ_FLAG_PHYSICAL,REZ_FLAG_DIE_ON_COLLIDE,REZ_FLAG_DIE_ON_NOENTRY), REZ_POS, vector(0,0,2), true, true, REZ_DAMAGE, 10, REZ_DAMAGE_TYPE, DAMAGE_TYPE_BLUDGEONING, } ) end) LLEvents:on("on_damage",function() ll.OwnerSay(`on damage`) end) Click the prim, outputs 1 on damage Click the prim, outputs 1 Note that every hit after the first prints no on damage text This also happens in LSL: Luau LSL Script default { touch_start(integer count) { llRezObjectWithParams( "Object", [ REZ_FLAGS, REZ_FLAG_TEMP|REZ_FLAG_PHYSICAL|REZ_FLAG_DIE_ON_COLLIDE|REZ_FLAG_DIE_ON_NOENTRY, REZ_POS, <0,0,2>, TRUE, TRUE, REZ_DAMAGE, 10, REZ_DAMAGE_TYPE, DAMAGE_TYPE_BLUDGEONING ] ); } on_damage(integer count) { llOwnerSay("on damage"); } } Saving that back and forth between lsl luau and lsl mono will show the difference

I'd like to suggest including scripting school regions in the SLua beta testing on the main grid. These regions could offer a useful testing environment, with motivated students and instructors who would be glad to provide feedback. I mentioned this at the August 5th SUG meeting: [12:18] Suzanna (suzannalinn): Will the regions with scripting schools be able to get SLua Beta? [12:19] Rider Linden: That's a pretty good idea Suzanna. Would you put something on the SLua board in Canny to remind me about that when we start selecting regions? Allowing schools to teach SLua on the main grid would greatly benefit students: No need to switch grids or recreate inventories. More accessible and comfortable learning environment. Better attendance and continuity. Easier integration into existing classes. More realistic feedback from live educational use. Thanks for considering this!