📃 SLua Alpha

Provide listen event with an object representing the message instead of the LSL parameters channel , name , id , message I'd propose if possible an object with the following structure type ChatMessage = { _id: number, from : uuid, owner: uuid, -- same as ll.GetOwnerKey on from, but preloaded to prevent loss on disappearing objects (and maybe cross region?) name: string, channel: number, listener: number, -- the same as the return for the llListen that setup this hook length: number, -- length in bytes for the message getText: (self: ChatMessage) -> string, -- retrieves the message corresponding to _id } Example use LLEvents:on("listen",function(msg) ll.OwnerSay(`from {msg.name}`) ll.OwnerSay(`with id {msg.from}`) ll.OwnerSay(`on channel {msg.channel}`) ll.OwnerSay(`it is {msg.length} bytes long`) if msg.length < 500 then ll.OwnerSay(`message: {msg:getText()}`) end ll.ListenRemove(msg.listener) end) This would make clearing listeners in the event itself allot cleaner. And also address the OOM issue of receiving too much text, (though yes that is slightly alleviated with 128k memory and chat having less than 1k max). If listen handle or owner, is not easily/reliably available right now, they should be addable at a later date without affecting existing scripts

Provide http_response event with an object representing the request instead of the LSL parameters request_id , status , metadata , body I'd propose if possible an object with the following structure type HTTPResponse = { id: uuid, status : integer, meta: {}, length: number, -- length of body getBody: (self: HTTPResponse) -> string, -- retrieves body ... -- other common headers } Example use LLEvents:on("http_request",function(response) print("Body Length", response.length) if request.length < 500 then print("Body", response:getBody()) end end) This would make http responses safer and easier to manage especially with large bodies no longer risking oom's (yes you can limit response body size, but this would match the "standard" if my feature request for http_request is done too :P)

Provide http_request event with an object representing the request instead of the LSL parameters request_id , method , body I'd propose if possible an object with the following structure type HTTPRequest = { id: uuid, method : "GET"|"POST"|"PUT"|"DELETE", length: number, -- length of body url: string, -- the url this request came in on getBody: (self: HTTPRequest) -> string, -- retrieves body getHeader: (self : HTTPRequest, header: string) -> string, -- maps to ll.GetHeader setContentType: (self: HTTPRequest, contentType:number) -> (), -- maps to ll.SetContentType respond: (self: HTTPRequest, status: number, body: string) -> (), -- maps to ll.HTTPResponse getPath: (self: HTTPRequest) -> string, -- maps to ll.GetHeader with x-path-info ... -- other common headers } Example use LLEvents:on("http_request",function(request) print("HTTP", request.method) print("Body Length", request.length) if request.length < 500 then print("Body", request:getBody()) end print("Path", request:getPath()) request:respond(200, "OK") end) This would make http requests safer and easier to manage especially with large bodies no longer risking oom's If url is not easily available now, it should be addable later with no effect to existing scripts

Provide link_message event with an object representing the request instead of the LSL parameters sender , num , str , id I'd propose if possible an object with the following structure type LinkMessage = { source: number, num: number, length: number, getMessage: (self: LinkMessage) -> string, id_length: number, -- not sure about this... getID: (self: LinkMessage) -> string|uuid } Example use LLEvents:on("link_message",function(message) print("From prim", message.source) print("Num", message.num) if message.length < 500 then print("Message", message:getMessage()) end end) This would make link_messages safer and easier to manage especially with large unknown scripts from other parties

myRequestId = ll.HTTPRequest(myUrl, { HTTP_BODY_MAXLENGTH, 16384 }, "") Currently the maximum is 16384 in VM Mono and 4096 in VM LSO. In VM Luau, with more script memory, the maximum could be 32k or 64k.

Should ll.GetEnv be updated to return the actual proper type since SLua is not a strict language? E.g. agent_limit return a number. sim_channel return a string, etc. See the table per https://wiki.secondlife.com/wiki/llGetEnv

There are functions where it makes sense to make use of the ability for functions in SLua to return multiple values, that is at least where the list would have been static and returned around or less than 4 values. Here are a few usecases where this make sense: LLEvents:on("on_damage", function(events) for _, ev in events do local damage, type, original = ev:getDamage() end end) llGetBoundingBox: local min_corner, max_corner = ll.GetBoundingBox(object) llGetPhysicsMaterial: local gravity, restitution, friction, density = ll.GetPhysicsMaterial() llLinksetDataDeleteFound: local deleted, skipped = ll.LinksetDataDeleteFound(pattern, pass) --- There are many other functions where it does NOT make sense however, for example llCastRay, etc. However functions that have a fixed list of values and where there isn't an unmanageable amount (less than or equal to 4 return values I think), multiple return values make sense. Note that unlike many other programming languages, multiple returns are actually very natural in Lua and part of many standard library functions. Even looping through array-like or dictionary tables you would use the handy ipairs/pairs functions with their multi returns.

The project/lua_editor viewer currently uses a bit of a hack to insert a default slua script. It would be good to clean this up along with the new script feature in the inventory. Proposal : Object content panel New script on an objects contents should default to a clean slua script THAT USES OWNERSAY not say, with an optional drop down next to the new script button to choose a new lsl script instead. While we are at it, it would be good if there was a config setting in the viewer to specify an alternate default script (from inventory?). Proposal : New script in inventory Either: - New script should default to creating a slua script - There could be 2 options New Slua Script / New LSL Script Related issues https://feedback.secondlife.com/slua-alpha/p/new-script-without-state-entry-and-hello-avatar-with-ownersay Though as Suzanna can likely no longer edit it LLEvents:on("touch_start", function(touches) ll.Say(0, "Touched.") end) ll.OwnerSay("Hello, Avatar!")

This seems to be some oversight that there is no way to actually a way to loop over the characters of a utf8 string. The roblox docs mention a utf8.graphemes but this doesn't seem to have been upstreamed into luau, so we would need our own utf8.graphemes in SLua to do the same. Graphemes make more sense into what a scripter would usually want to actually intuitively access or iterate over in a string. This is very important for any platform dealing with internationalisation and emojis. * See here for difference of the terms: https://stackoverflow.com/a/27331885 * Roblox's utf8.graphemes: https://create.roblox.com/docs/reference/engine/libraries/utf8#graphemes Per WolfGang: * https://codeberg.org/nazrin/grapheme * https://libs.suckless.org/libgrapheme/ I'm currently working on a mesh-based text renderer that needs to be able to iterate over graphemes for emojis and stuff correctly for example. But there are many other usecases like being able to properly utf8 substring without messing up graphemes such as combining characters etc.

Constants It might be good to have constants for the event names LLEvents:on(EVENT_TOUCH_START, handler) or LLEvents:on(TOUCH_START_EVENT, handler) Though the latter does break the general convention LSL has of prefixing constants, so may be less desirable. Aliases While at that, as mentioned here some aliases would be nice, to allow for nicer code read, constants could be used or true aliases could be provided, but that may not be worth it. LLEvents:on("on_rez", handler) -- to LLEvents:on("rez", handler) -- or LLEvents:on(EVENT_REZ, handler)