📃 SLua Alpha

This was briefly discussed in the original table to json feature . It would be useful to have to allow for encoding of more complex data structures, also to allow tables that have functions to be encoded by specifying them to not be included Probably best for __tojson to return what we want to be encoded rather than actual json? local Nested = {} Nested.__index = Nested function Nested:__tojson() return { name= self.name, child= if self.child then self.child else nil } end function Nested.new(name,parent) return setmetatable({ name=name, parent=parent, child=nil },Nested) end local root = Nested.new("root") root.child = Nested.new("child1",root) root.child.child = Nested.new("child2",root.child) ll.OwnerSay(lljson.encode(root)) Possibly this is deemed too much of an addition as it can be achieved atm with this local Nested = {} Nested.__index = Nested function Nested:__tojson() return { name= self.name, child= if self.child then self.child:__tojson() else nil } end function Nested.new(name,parent) return setmetatable({ name=name, parent=parent, child=nil },Nested) end local root = Nested.new("root") root.child = Nested.new("child1",root) root.child.child = Nested.new("child2",root.child) ll.OwnerSay(lljson.encode(root:__tojson()))

Right now tovector("cake") Returns a zero vector and it should probably return nil instead This is how tonumber works for instance. It would also allow for easy testing of if a string is a vector Current behavior tovector("cake") -- <0.0, 0.0, 0.0> tovector("<0,0,as>") -- <0.0, 0.0, 0.0> tovector("<0,0,0") -- <0.0, 0.0, 0.0> tovector("<0,0,0>") -- <0.0, 0.0, 0.0> tovector("<1,1,1>") -- <1.0, 1.0, 1.0> tovector("<0xFF,0Xff,0xFF>") -- <255.0, 255.0, 255.0> Expected behavior tovector("cake") -- nil tovector("<0,0,as>") -- nil tovector("<0,0,0") -- nil tovector("<0,0,0>") -- <0.0, 0.0, 0.0> tovector("<1,1,1>") -- <1.0, 1.0, 1.0> tovector("<0xFF,0Xff,0xFF>") -- <255.0, 255.0, 255.0>

If a script is open in the external editor, print errors the client receives to a matching .log file. This would allow external tooling to pick them up and display them in editor. In the future with more advanced errors this could include source map support etc. Suggestion Client receives script error (be it on debug channel, or a compile error) Checks if script the error belongs to is open Checks if that script is open in external editor Appends error to matching file sl_script_<script_name>_<uuid>.luau.log

SL's implementation of Lua now has three number-ish types: number (built-in) boolean (built-in, false is distinct from 0 ) integer (userdata, for compatibility with LSL API) integers can be created from numbers by calling integer() Right now, we can't convert boolean to integer , which makes writing scripts a bit convoluted: enable = false -- eg. result of `health <= 0` ll.SetPrimitiveParams({PRIM_PHYSICS, integer(enable)}) -- error: lua_script:2: unable to cast! -- [C] function integer The current solution would have to be: enable = false -- eg. result of `health <= 0` enable = if enable then 1 else 0 ll.SetPrimitiveParams({PRIM_PHYSICS, integer(enable)})

It doesn't look like changes for the slua sims is pushed to https://releasenotes.secondlife.com/repositories.html Would this be possible? Or maybe push them to a channel on discord so we know what's done and what's needing attention. It's hard to track when and where on the canny stuff is noted as fixed unless you have commented on the post

When using either SLua or LSL: 2025 VM , script execution continues for a short time after a call to llResetScript . With the following LSL script on the Luau VM, touching the object results in both "Touched." and "Hello, Avatar!" being output to local chat. This behavior does not match the same script compiled to Mono or LSO2 which only output "Hello, Avatar!" on touch. default { state_entry() { llSay(0, "Hello, Avatar!"); } touch_start(integer total_number) { llResetScript(); llSay(0, "Touched."); } } Placing a sleep of any length between the call to llResetScript and llSay will result in the expected behavior. This extended execution also affects SLua when calling ll.ResetScript , but it's easier to compare the behavior by just switching the compiler on LSL.

Again just a finetuning thing from a performance geek, but I ran a test and the vector() function runs several times slower, maybe 1/3 the speed, compared to vector.create. Considering people might be creating vectors repeatedly for prim params based effects for colors and positions and the vector(x, y, z) style was sort of "advertised as the official way" when we didn't have full vector library compatibility, it feels like an unnecessary slowdown when they do the exact same thing. Assigning a global variable to vector.create is slower than just calling it directly so I'm sure part of it is the whole lookup delay, but that too is somewhat faster than just calling vector(). Could the vector() function be changed just to be an alias for at least a minor speedup? The best approach is of course unlearn using vector() in the first place.

found another way to cause the bug found here https://feedback.secondlife.com/slua-alpha/p/unable-to-perform-mandatory-yield-error it is happening with my script every now and then. not often enough to track down the part of the code that is triggering it. i have a script that reproduces the error fairly reliably I'm pretty sure I can narrow it down to something with ll.GetNotecardLineSync as this started after moving over from ll.GetNotecardLine with data server event To reproduce add a notecard called LootConfig to an object along side the below script and compile -- Global variables to track line number and notecard query ID notecardLine = 0 notecardQueryId = nil --tables testTable = {} rw = {} rc = {} rMessage = {} lStack = {} config = {} -- Price of the loot box (read from the notecard) lPrice = 0 --current user currentUser = nil function read_notecard_sync(name) local notecard = "LootConfig" -- Ensure this is a valid notecard name local line = 0 if notecard and notecard ~= "" then -- Ensure the notecard name is valid local text = ll.GetNotecardLineSync(notecard, line) while text ~= EOF and text ~= NAK do --ll.OwnerSay(text) process_line(text) line = line + 1 text = ll.GetNotecardLineSync(notecard, line) end if text == NAK then ll.OwnerSay("Cache interrupted! getting data") ll.GetNumberOfNotecardLines("LootConfig") ll.ResetScript() else ll.OwnerSay("finished reading successfully") if config["price"] then lPrice = tonumber(config["price"]) ll.SetPayPrice(PAY_HIDE, { lPrice, PAY_HIDE, PAY_HIDE, PAY_HIDE }) ll.OwnerSay("Loot box price set to: " .. lPrice .. " L$") updatePriceDisplay() else ll.OwnerSay("Warning: No price set in the notecard.") end end else ll.OwnerSay("Error: Notecard name is invalid or missing!") end end function process_line(line) local key, value = string.match(line, "([%w_]+)%s*=%s*(.+)") if key and value then local num_value = tonumber(value) config[key] = num_value or value return end local r, c, w, i, m = string.match(line, "([^:]+):([^:]+):([^:]+):([^:]+):(.+)") if r and c and w and i and m then local iList = string.split(i, ",") testTable[r] = iList rw[r] = tonumber(w) or 1 rc[r] = c rMessage[r] = m else ll.OwnerSay("Failed to match line format: " .. line) end end for i=1,1000,1 do read_notecard_sync("LootConfig") ll.ResetScript() end

Now that the list casting work has been done, we no longer need all the "whole number" constants to be integers. Being integers is causing issues with other methods like ll.GetInventoryType("notecard") == INVENTROY_NOTECARD Always evaluating to false as GetInventoryType returns a number not an integer Other examples ll.LinksetDataWrite("a",a") == LINKSETDATA_OK ll.GetAttached() == ATTACH_HEAD There are 2 alternatives Implement equallity checking between integers and numbers Make all the fucntions return integers.... I think 1. should maybe be done anyway, but 2. just seems like a bad idea So changing the constants back to numbers, now that numbers work in lists seems like the right move.

Here are some specifics on the parameters, not a method to reproduce the issue, as I cannot narrow that down myself. Upon link change, if local sitter_id = ll.AvatarOnSitTarget() istruthy then I store player_id = sitter_id , otherwise NULL_KEY Taking permissions on player_id for controls, and various controls once run_time_permissions is fired Using ll.HMAC(SECRET_KEY, message, 'sha224') with a few values in the message including tostring(player_id) Over time, for unknown reasons, player_id starts shifting "e760b472-baf4-43c2-97f9-e36bbc5ee3f6" -- correct -- eventually starts changing... "0cf16f0f-002a-8d09-97f9-e36b00000000" "7c6f7e12-002a-8d09-97f9-e36b00000000" "7c6f7e12-002a-8d09-fc07-421200000000" If it helps I have a version of my work that triggers the issue, which I don't mind sharing.