📃 Lua Alpha

llprim.ParamsSetter is not proper English, and I keep misspelling it due to that. It should be llprim.ParamSetter (1 fewer "s") These sentences are correct: the script programmer will program scripts the cat herder will herd cats the param setter will set params the llprim.ParamSetter will ll.SetPrimitiveParams These sentences are not correct: the scripts programmer will program scripts the cats herder will herd cats the params setter will set params the llprim.ParamsSetter will ll.SetPrimitiveParams I submitted a pull request: https://github.com/secondlife/lsl-definitions/pull/196

Incorporate a SLua sub forum into the SL forums. The LSL Scripting section has been invaluable to many over the years and a new section would be as well.

I'm reporting this one because we are looking for all the differences, but I don't think that it has any real use. // LSL Mono default { state_entry() { integer a = 2; (a *= 2.2); llOwnerSay((string)a); // --> 4 }} // LSL Luau default { state_entry() { integer a = 2; (a *= 2.2); // --> Script run-time error : cannot take result of integer *= float }} a *= 2.2; works in both, float f = (a *= 2.2); errors in both.

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!

The compiler on agni is not doing as much constant-folding and dead-code elimination as the CLI tools. Take this script: print(gcinfo()) local a = "a" .."a".."a".."a".."a".."a".."a".."a".."a".."a" .."a".."a".."a".."a".."a".."a".."a".."a".."a".."a".."a" print(gcinfo()) Variable a should be constant-folded away, then eliminated as dead code, as it is unused On simulator version Luau 2026-01-30.21516666911 , this prints [4:29 PM] Object: 1.4892578125 [4:29 PM] Object: 1.525390625 The two numbers are different, so something entered memory in-between the two gcinfo calls However, when run locally, it prints: $ ./slua memtest.luau 38 38 The two numbers are the same, indicating nothing happened in memory in-between the two calls. Looking at the bytecode compiled locally: $ ./slua-compile memtest.luau Function 0 (??): 1: print(gcinfo()) GETIMPORT R0 1 [print] GETIMPORT R1 3 [gcinfo] CALL R1 0 -1 CALL R0 -1 0 4: print(gcinfo()) GETIMPORT R0 1 [print] GETIMPORT R1 3 [gcinfo] CALL R1 0 -1 CALL R0 -1 0 5: RETURN R0 0 nothing at all happens in between the two print statements. No allocation, no string concatenation, nothing I can't grab the bytecode for the simulator-compiled script, but it's clearly doing something differently

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

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

// VM Luau default { state_entry() { float f = (float)1 / 0; llOwnerSay((string)f); // -- > Infinity vector v = <1, 1, 1> / 0; llOwnerSay((string)v); // -- > <Infinity, Infinity, Infinity> v = <0, 0, 0> / 0; llOwnerSay((string)v); // -- > <NaN, NaN, NaN> }} In VM Mono the 3 divisions are a Math Error run-time error.

I've been porting a set of three scripts to the LSL on luavm 2025 and have run into an unexpected memory limit issue. As the script has grown by my enabling more of it by integrating the three scripts into one, the USED memory size has crossed the 64k boundary. This includes code and data, and because of a different bug that Harold Linden is aware of (code size greater than 64k triggers a constructor fault), I've been working to keep the code under 64k (just barely at this point). Today I started getting these kinds of runtime errors: PRIMA Femme Elite v1.9 [script:body_lsl] Script run-time error not enough memory not enough memory [C] function ListInsertList [C] function ListReplaceList lsl_script function _fupdate_link_alpha lsl_script function _fchange_piece_shape lsl_script function _e0/state_entry By commenting out other code that is not used during the state_entry logic, the code runs. I'm guessing it's because there are checks in the list code called to make sure the lists are inside the 64k boundaries of days of yore. I have some skid marks in my code and what I see are these two messages before the script fault occurs: state_entry 0 used 61241 free 69831 state_entry2 1 used 66745 free 64327 The first one is the first statement in state_entry(). The second one is down a ways after I've initialized a bunch of my global variables. The third one I added to the code never runs because of the error shown above.

In beta grid, Luau 2026-03-24.23471922914, and in main grid, Luau 2026-01-30.21516666911 // VM Mono default { state_entry() { rotation r = (rotation)"hello"; llOwnerSay((string)r); }} // -- > <0.00000, 0.00000, 0.00000, 1.00000> // VM Luau default { state_entry() { rotation r = (rotation)"hello"; llOwnerSay((string)r); }} // -- > <0.00000, 0.00000, 0.00000, 0.00000>