📃 SLua Alpha

There has already been some discussion of this in other canny's Like here But a centralized issue for feedback is probably a better idea. As the post by Harold Linden says in the above link, LL are considering something like LLEvents.touch_start = function ... Personally I would rather suggest something more akin to local handle = llevent.onTouchStart(function(touches:number) end) local handle = llevent.dispose(handle) or local handle = llevent.on(llevent.TOUCH_START, function(touches:number) end) llevent.dispose(handle) or (nya's suggestion) local function touchHandler(touches: number) end llevent.on(llevent.TOUCH_START, touchHandler) llevent.off(llevent.TOUCH_START, touchHandler) Mostly to allow for if not now, at least in the future multiple event handlers being setup and expanding to support things similar too function listenHandler(channel, name, key, msg) end local listener = ll.Listen(0,"","","test") llevent.on(llevent.LISTEN, listenHandler, listener) or function listenHandler(channel, name, key, msg) end llevent.on(llevent.LISTEN, listenHandler, {channel=0,message="test"}) Possibly something similar to roblox's "standard" , or something designed in a way that is compatible with it, so it can be properly extended later. This needs to happen BEFORE a possible beta phase There should also be NO COMPATABILITY with the current way of working, all current scripts SHOULD break and need rewriting, having both is not really a good option, and NOW is the time for breaking that.

some ideas on how it could work: Required scripts are saved as a different type of script: modules, with a new compiler option: compile to "SLua scriopt" or to "Slua module". Modules are executed when required and return a value, with a return statement, for instance a table with functions and constants. Scripts call modules as myModule = require("Module name") , the returned value is assigned to the variable myModule , using the script's memory space. The module must be in the object contents with the script that requires it. If the module is not in the object, its running state is disabled, or it doesn't return a value, require() will return nil. Once it returns, the module is removed from memory and its variables are garbage-collected. Modules are executed synchronously, the main script is paused until the module returns. Modules don't receive events, any events that arrive while the module is executing are queued in the main script. Modules can't require other modules, only scripts can use require() .

Common usage of methods like ll.AgentInExperience etc in lsl is to just stick them in an if directly as 1 evaluates true As this is not the case in lua, it would be good for the relevant functions to return booleans. I have scoured the function list and updated the wiki to include all the ones I could see on a first pass through. https://wiki.secondlife.com/wiki/Category:LSL_Functions/Returns_a_integer/boolean ll.AgentInExperience ll.DerezObject ll.EdgeOfWorld ll.GetScriptState ll.GetStatus ll.IsFriend ll.ManageEstateAccess ll.SameGroup ll.ScaleByFactor ll.ScriptDanger ll.SetMemoryLimit Were missing and I added them, listed separately in case they are "wrong" ll.DetectedGroup ll.IsLinkGLTFMaterial ll.OverMyLand ll.SetRegionPos ll.VerifyRSA

Traditional LSL requires bitwise operators quite often: event parameters ( changed ), function call flags ( llRezObjectWithParams ), ... Lua 5.3 introduced native bitwise operators: https://www.lua.org/manual/5.3/manual.html#3.4.2 Having these usable in SLua would be a significant quality-of-life improvement in the face of Luau's bit32 library, though the library does still include other very useful features like btest , replace , etc. The library should stay regardless. To be fair, Luau's reasoning for not including bitwise operators is decent, but LSL context adds quite a heavy weight on this decision. I don't know the work that would go into implementing these operators, but hopefully they can be implemented in such a way that makes use of the same VM built-ins as the bit32 library to avoid any performance penalties.

function touch_start(total_number) ll.Say(0, "Touched.") end ll.OwnerSay("Hello, Avatar!") It's confusing for LSL scripters who are starting to learn SLua to be told that state_entry() doesn't exist, when the sample script includes it. There are many "Hello, Avatar!" messages in scripting classes or sandboxes.

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.

This should remove any undue runtime overhead from bit32.* calls and friends that have FASTCALL implementations.

Externally edited files currently go to strange locations and have strange names. If this could be normalized a bit, it would make it easier to use Git or similar code managers to keep versioned copies of one's scripts. As things stand now, one typically has to make a copy of the script, give it a standard name and then save to the local repo folder, then version it. I'm hoping something better can be devised.

Currently there are surely a lot of little parity problems. These are just some that I've noticed so far- local a = {1, 2, 3, 4} local b = {1, 2, nil, 4} local c = {1, 2, d = 3, 4} ll.OwnerSay(`a {#a} `) ll.OwnerSay(`b {#b} `) ll.OwnerSay(`c {#c} `) A and B will return 4, but C will return 3. Getting the length of a table with dictionary elements requires looping thru the entire table with pairs() each time, requiring a cludgy metamethod to have it work how one would 'expect', when just a table.len() would be useful. local Tbl = {} Tbl.__index = Tbl Tbl.__len = function(len) local incr = 0 for _ in pairs(len) do incr = incr + 1 end return incr end Likewise, list concatenation is a major thing in SL, allowing one to build up lists for llSetLinkPrimitiveParams for instance to save on function calls. This is entirely impossible in Lua with merging even two tables requiring your own function, or another cludge, to say nothing of matching the functionality of SL where multiple lists can be strung together easily- Table. __concat = function(a, b) if type(b) == "table" then for _, v in ipairs(b) do a[#a+1]=v end else a[#a+1]=b end return a end } As these are probably minor, basic functions that would get a lot of use, I feel like small things like this should start being added to the language, to prevent them from needing to be created in every script itself. The performance would also be higher if implemented in C on top of that. Lua is advertised as being an extremely tiny language, but that can be a little detrimental when we have to make even basic helper functions ourselves in our limited 64kb memory.

table ll.LinksetDataListTable(start, count, pass?) and table ll.LinksetDataFindTable(start, count, pass?) like llLinksetDataListKeys and llLinksetDataFindKeys , but returning a table with keys and values with optional parameter pass for protected values table ll.LinksetDataWriteTable(table, pass?) returning a table with keys and errorcodes for the pairs not writen, an empty table means all ok table ll.LinksetDataReadTable(pass?) returning all the linkset data