📃 SLua Alpha

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

// 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>

In beta grid, Luau 2026-03-24.23471922914, and in main grid, Luau 2026-01-30.21516666911 local r = rotation(0,0,0,0) print(rotation.tofwd(r)) -- > <nan, nan, nan> print(ll.Rot2Fwd(r)) -- > <1, 0, 0> print(rotation.toleft(r)) -- > <nan, nan, nan> print(ll.Rot2Left(r)) -- > <0, 1, 0> print(rotation.toup(r)) -- > <nan, nan, nan> print(ll.Rot2Up(r)) -- > <0, 0, 1>

This script: u = ll.RezObjectWithParams("00", {}) print(`"{u}"`, typeof(u), u.bytes) prints [7:59 AM] Object: Could not find object '00'. [7:59 AM] Object: "" uuid nil

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

This appears to be related to highlighting. It is also influenced by the amount of code in the script and by the amount of comment text. However, commenting out all preceding code, or turning it all into a very long string, can make the problem vanish. The affected scripts compile and run without unexpected errors, but it becomes difficult to edit certain lines within the editor: Steps to reproduce: In an SLua Enabled Sim, rez a new prim. Create a new script, open it, and replace the contents with the attached script. Note that "LLEvents" in line 14 is highlighted in green. Attempt to select the line. Observe that only the word "function" is highlighted. Copy the line and paste at the bottom of the script. Observe that the whole line is pasted. Place the cursor at the left edge of the line and move right one character at a time with the arrow keys. Observe that the characters "s.touch_e" are skipped as a group. Attempt to select or erase "_end". Depending on your method, various failures will occur. Press End to move to the end of the line. Observe that the visible cursor is well past the end of the line, but that backspace deletes the last character. Note that when the line no longer represents a proper event that the line becomes normally editable. Comment out line 12. Observe that "LLEvents" becomes blue and the line is normally editable. Reenable line 12 and delete line 13. Observe the same. So far, I have only observed this with LLEvents.touch... All 3 are affected. In-Editor WORKAROUND: When editing an affected line, change the first keyword by adding an extra character at the beginning, such as making "LLEvents" into "xLLEvents". Edit the line as needed, then remove the extra character.

I would think these would always be equal in SLua: print(ll.GetMemoryLimit()) -- 130920 print(2^17) -- 131072 That's what it does in LSO; just returns a constant 2^14 default { state_entry() { llOwnerSay((string)llGetMemoryLimit()); // 16384 llOwnerSay((string)llPow(2, 14)); // 16384 }}

Not much more to it. llGetFreeMemory report 16000s bytes free at all times, llGetSPMaxMemory reports 16384 whether profiling is on or off. Same applies to pure Luau scripts, neither function returns meaningful values. ~~llGetUsedMemory and ll.GetUsedMemory appear to be ok.~~ <- Edit: redacted, they do not count memory used by tables or strings at all. A table with 10000 random numbers in it is reported as not using any memory, as well as a string with 256k(! that can't be right either) characters. Same applies to lists when compiled as LSL-Luau.