📃 SLua Alpha

ll.LinksetDataRead("key") and ll.LinksetDataReadProtected("key", "pass") both will return an empty string if trying to access a stored value that doesn't exist. Which is not "nil". Can we get it so that if a key pair does not exist in the LSD store that the return is actually a "nil" type instead? It would also return nil on a protected key with a bad "pass". We have access to the nil data type with SLua now, and it'd be more logical for a non-existent key to return nil for a simple boolean test. IMO. Just an idea at least. Added thought: maybe have "llcompat" have the return still be a zero length ("") string for, well, compatibility sake.

Constants It might be good to have constants for the event names LLEvents:on(EVENT_TOUCH_START, handler) or LLEvents:on(TOUCH_START_EVENT, handler) Though the latter does break the general convention LSL has of prefixing constants, so may be less desirable. Aliases While at that, as mentioned here some aliases would be nice, to allow for nicer code read, constants could be used or true aliases could be provided, but that may not be worth it. LLEvents:on("on_rez", handler) -- to LLEvents:on("rez", handler) -- or LLEvents:on(EVENT_REZ, handler)

Should ll.GetEnv be updated to return the actual proper type since SLua is not a strict language? E.g. agent_limit return a number. sim_channel return a string, etc. See the table per https://wiki.secondlife.com/wiki/llGetEnv

There are functions where it makes sense to make use of the ability for functions in SLua to return multiple values, that is at least where the list would have been static and returned around or less than 4 values. Here are a few usecases where this make sense: LLEvents:on("on_damage", function(events) for _, ev in events do local damage, type, original = ev:getDamage() end end) llGetBoundingBox: local min_corner, max_corner = ll.GetBoundingBox(object) llGetPhysicsMaterial: local gravity, restitution, friction, density = ll.GetPhysicsMaterial() llLinksetDataDeleteFound: local deleted, skipped = ll.LinksetDataDeleteFound(pattern, pass) --- There are many other functions where it does NOT make sense however, for example llCastRay, etc. However functions that have a fixed list of values and where there isn't an unmanageable amount (less than or equal to 4 return values I think), multiple return values make sense. Note that unlike many other programming languages, multiple returns are actually very natural in Lua and part of many standard library functions. Even looping through array-like or dictionary tables you would use the handy ipairs/pairs functions with their multi returns.

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.

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

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