📃 SLua Alpha

In the script editor, the dropdown gives 3 options for compiling LSL, and 1 for SLua. I think they would be better named: SLua LSL-128 (on SLua) LSL-64 (on Mono) LSL-16 (on LSO) "LSL-128" is clear, compact, and and easily distinguishable from both "Mono" and "SLua", which already have colloquial names. I also reversed the list to put them in order of most to least recommended Edited with input from Nexii Malthus, Suzanna Linn, and Kristy Aurelia

Using a notecard "test" with a line: Time flies like an arrow; fruit flies like a banana. -- one "Time": print(ll.FindNotecardTextSync("test","Time",0,0,{})[3]) -- 4 -- one "banana": print(ll.FindNotecardTextSync("test","banana",0,0,{})[3]) -- 6 -- two "like": print(ll.FindNotecardTextSync("test","like",0,0,{})[3]) -- 5 print(ll.FindNotecardTextSync("test","like",0,0,{})[6]) -- 5 -- two "flies": print(ll.FindNotecardTextSync("test","flies",0,0,{})[3]) -- 6 print(ll.FindNotecardTextSync("test","flies",0,0,{})[6]) -- 6 Could be related to this: https://feedback.secondlife.com/slua-alpha/p/the-length-returned-by-llfindnotecardtextsync-has-been-1-based previously to that canny all lengths were returned +1.

Please add a function that converts a float64 to a signed 32-bit integer, compatable with lsl. It would be equivilant to in luau: function bit32.s32(n: number) return (math.modf(n) + 0x8000_0000) % 0x1_0000_0000 - 0x8000_0000 end in c: double s32(double n) { return (double)(s32)n; } Code that dealt with integers >= 0x8000_0000 behave differently in lsl and luau, due to s32 wrapping. I imagine there's already a function like this for the lsl compiler, but exposing it to slua scripters would be helpful for converting old scripts

I wrote a inventory wrapper similar to DetectedEvent . Maybe something like it should be a builtin: https://gist.github.com/tapple/81c509f4a876e7364989607f507bc947 It wraps all the generic inventory functions. It does inventory iteration, both forward and backward (required if removing inventory during iteration) It does not wrap the multiple inventory functions: ll.GiveInventoryList ll.GiveAgentInventory It does not wrap the functions specific to an asset type: the 28 functions marked asset-semantics in https://github.com/secondlife/lsl-definitions/blob/main/lsl_definitions.yaml ll.StartAnimation ll.StartObjectAnimation It does not wrap the rumored upcoming llGetLinkInventory because they don't exist yet

Making this a Canny at Harold's request. The name "listeners" in this context is confusing because we already have "listen" events. "handlers" is a more accurate term that is unambiguous and already in general use when discussing the subject. I suppose that "listeners" could potentially be kept as an alias for backward compatibility, if deemed necessary, but I feel that its use should be deprecated to avoid future ambiguity. (Not sure of the appropriate category for things like this. Calling it a Bug since it entails a change in the source code.)

There was a ticket elsewhere about supporting 64-bit unixtime by returning a list of the two halves of a 64-bit int, 32 bits wide. (32-bit ints run out for that purpose in about ten years.) There are probably other reasons you'd want to store a 64-bit int or float, like astronomical calculations. Is this going to be possible in Lua, or in LSL after the Lua cutover, without scripters writing a BCD layer or some other Rube Goldberg solution?

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

Luau scripts have a lot more ways to crash than LSL scripts. I wrote this as a proof of concept on making LLTimers and LLEvents crash proof: https://gist.github.com/tapple/70b874b3801d6cbf103559287e85b964 It might be nice if there was a function like LLEvents:setDefaultErrorHandler(errorHandler) that did the same thing the above code does, without needing to wrap/monkey patch anything.

The syntax highlighter indicates that math.isnan should exist. However an attempt to use it results in an Attempt To Call A Nil Value error. Image showing error and highlighting compared to both valid and invalid math.xx expressions: https://imgur.com/3xX9lNe I lean toward fixing this by implementing math.isnan on principle of luau compatibility, but I don't have strong feelings about it either way. The number of likely users of math.isnan is incredibly small ( laughs one?) and I'm perfectly comfortable with using v~=v. (It's more succinct!)

lljson has inconsistent behavior. I think these should all produce an error: print(pcall(lljson.sldecode, '"!vOops"')) print(pcall(lljson.sldecode, '"!qOops"')) print(pcall(lljson.sldecode, '"!uOops"')) The first 2 produce an error: malformed tagged vector: !vOops malformed tagged quaternion: !qOops But the last one produces an uncompressed uuid: local _, u = pcall(lljson.sldecode, '"!uOops"') print(u, typeof(u), u.bytes) -- Oops uuid nil This uuid cannot be re-encoded: print(pcall(lljson.slencode, u)) invalid UUID format for JSON encoding Instead, sldecode should produce an error: malformed tagged uuid: !uOops And uncompressed uuid's should be removed from slua, it's documentation, and typechecker: https://github.com/secondlife/lsl-definitions/blob/23d46484888c1908545dc92db119613bb553af11/slua_definitions.yaml#L70 - name: bytes comment: Returns the raw 16-byte binary string of the UUID, or nil if the UUID is not in a compressed state type: string?