📃 SLua Alpha

There are a few function that would be good to have through the viewer web socket for smoother integration with external editors. Requests - web socket endpoints List Open script editors with editor id 's (This is sort of done, but only open scripts that are also currently externally edited it might be nice to list all open ones) Get currently selected object id List content asset id, asset type, name of an object id to allow for opening scripts Open script editor by asset id to open a script from an object return editor id Get contents of open script editor by editor id Get object id, asset for an open script editor by editor id Send contents to and open editor by editor id to save Events - Things the socket can announce to subscribers New object selected - object id, inventory content New script editor opened - editor id, object id, asset, text content General Add config to allow the websocket to be opened when editing even if there are no scripts open yet, to allow for external tools to sync to viewer when it starts editing, and stay open if there are still subscriptions after, as it currently does. Given these endpoints it should be possible to make a fairly integrated setup in any editor, that would allow you to open related scripts and edit them seamlessly, and would also allow bypass the fiddly aspect of dealing with the current temp file system. For instance the current vs code plugin could list a virtual workspace that represents the sl viewer, and show a tree view of object content for the user to open and edit.

When calling ll.GetUsedMemory() or ll.GetFreeMemory() immediately after some memory operation: -- memory miscount local tab = {} local mem = ll.GetUsedMemory() tab = table.create(32, true) print(ll.GetUsedMemory() - mem) -- > 512 tab = table.move(tab, 1, 1, 1, {}) print(ll.GetUsedMemory() - mem) -- > 560 -- should be 16 Adding something that yields works well (it seems that yielding cleans things): -- yielding local tab = {} local mem = ll.GetUsedMemory() tab = table.create(32, true) print(ll.GetUsedMemory() - mem) -- > 512 tab = table.move(tab, 1, 1, 1, {}) for _ = 1, 1 do end -- yielding print(ll.GetUsedMemory() - mem) -- > 16 Also calling the function twice (perhaps because they yield at the end): -- calling twice local tab = {} local mem = ll.GetUsedMemory() tab = table.create(32, true) print(ll.GetUsedMemory() - mem) -- > 512 tab = table.move(tab, 1, 1, 1, {}) local used, used = ll.GetUsedMemory(), ll.GetUsedMemory() print(used - mem) -- > 16 Could ll.GetUsedMemory() and ll.GetFreeMemory() yield at the start to update the memory?

While this caveat behavior is known and possibly relied upon by lsl scripts. Nobody should be writing a slua script expecting this security issue to exist. So if possible could a ll.HTTPRequest from slua, only trigger the http_response event in the slua script making the request. Or a dataserver request also respond only to the requesting script. Not in any other, script regardless of their platform runtime. This might be a slight pain to implement to keep the behavior for lsl on luau scripts, but I think worth it for slua Test Place 2 scripts in a prim save them with the following content ll.HTTPRequest("https://secondlife.com",{},"") function http_response(id,stat,meta,body) ll.OwnerSay(`{ll.GetScriptName()} = {stat}`) end Note that on saving of the second script you get 2 owner says, one from each script stating the response status. Ideally this behavior should be avoided for slua. Alternate suggestion It was suggested it may be possible to instead add a new HTTP_* flag Something like ll.HTTPRequest( "https://secondlife.com", { HTTP_PRIVATE_REQUEST, TRUE }, "" ) This would not work for dataserver events though

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

Since 2026-04-09.24211153544 toggling "Disable Scripts" under Debug on the Region / Estate Tools seems to just outright crash the simulator. This occured on "Absolute Zero" today at roughly 17:40 UTC.

Something like table.slice(src: {...}, from: number, to: number) -> {...} Or maybe table.slice(src: {...}, start: number, amount: number?) -> {...} where amount is optional and works like string.sub(...)

default { state_entry() { // editor line 0 integer i = 0.5; // line 1 }} -- > Line 2: 'integer i' assigned a float value. The editor could start with line 1 (like with SLua), or the messages return the error line - 1.

printing: print("test\0ing", "something") -- > test something ll.OwnerSay("test\0ing") -- > test saying on a channel to another object: -- object 1 local s = "test\0ing" LLEvents:on("touch_start", function() ll.RegionSay(1, s) end) -- object 2 LLEvents:on("listen", function(_, _, _, msg) print(#msg, msg) end) ll.Listen(1, "", "", "") -- > 4 test linked messaging: -- script1 local s = "test\0ing" LLEvents:on("touch_start", function() ll.MessageLinked(LINK_THIS, 0, s, s) end) -- script 2 LLEvents:on("link_message", function(_, _, s1, s2) print(#s1, s1, #s2, s2) end) -- > 4 test 4 test

While I suspect allot of this is "to come" with the improved debugging features that have been "implied/promised" It would also be nice for scripts to be able to access some meta information about themselves. This in part came up during discussion of the new event system ( RFC ) on possible issues with os.clock() and ll.GetTIme() So I proposed a table with functions and or values for getting info about the script itself e.g type llscriptmeta = { compile : { time: number, -- Unix timestamp of script compile by: uuid, -- Who saved the script with: string -- Some version string of the compiler }, startTime: number, -- Unix Timestamp of script start (resets with ll.ResetScript) getUpTime: () -> number. -- Like ll.GetTime but with no luau caveats(resets with ll.ResetScript) bytecodeSize: number, --- Size of the bytecode in bytes ... }

The utf8 library really should be full featured with equivalent methods as found in the string library, even if that method works with utf8 strings already. The point being that as a scripter you can trust these methods work fine with utf8 strings without having to tip toe around the reference docs to make sure what might or might not or have certain caveats such as the string position index being based on bytes. The first implementation would be the easy low hanging fruit: bytecode equivalents. Methods in string library that work with utf8 strings fine already and just simply generate the same bytecode. Second would be looking at existing ll* functions and copying the code to work with the slua bindings. For example llToLower / llToUpper. Third would be writing brand new methods. The big question(s) might be whether this should be a bigger effort/coordination upstream in Luau given that Roblox has all the same problems. This also means whether these might be added even further upstream in Lua 5.6+ in the future or if Luau and even SLua continue to further diverge. There are often threads in Roblox around utf8 compatibility issues due to user input such as names and chat. SL has a big international presence, official language support and existing legacies of unicode scripting support which significantly exacerbates how critical this problem is for SLua.