📃 SLua Alpha

I'd like to suggest including scripting school regions in the SLua beta testing on the main grid. These regions could offer a useful testing environment, with motivated students and instructors who would be glad to provide feedback. I mentioned this at the August 5th SUG meeting: [12:18] Suzanna (suzannalinn): Will the regions with scripting schools be able to get SLua Beta? [12:19] Rider Linden: That's a pretty good idea Suzanna. Would you put something on the SLua board in Canny to remind me about that when we start selecting regions? Allowing schools to teach SLua on the main grid would greatly benefit students: No need to switch grids or recreate inventories. More accessible and comfortable learning environment. Better attendance and continuity. Easier integration into existing classes. More realistic feedback from live educational use. Thanks for considering this!

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

The LSL variables TRUE and FALSE both work as true in SLua. I'd suggest that rather than auto-define them, they should be left undefined. If not, a not uncommon error will be to type TRUE or FALSE when one meant true or false. Failing that, I'd suggest defining TRUE -> true and FALSE -> false. Thanks!

The SLua code below demonstrates the problem. Two vectors, multiplied, results in a vector answer rather than a number. v1 = vector(9, 2, 7) v2 = vector(4,8,10) v3 = v1 * v2 ll.OwnerSay(typeof(v3) .. ": " .. tostring(v3)) Program output: vector: <36.00000, 16.00000, 70.00000> Reason for identifying as a bug: The SL Wiki indicates that the dot product should return the sum of the products of the vector elements. In this case, the expected result should be 122.0. What is returned instead is simply the vector of the products of each element.

Second Life Project Lua Editor 7.1.12.14888088240 (64bit) I created a short script demonstrating multiple inheritance in SLua. The program worked exactly as intended until I added a call to ll.SetText at the beginning of the script, whereupon the script produced an incomprehensible "Failed to perform mandatory yield" error when the __index function was invoked. Attached is a stripped down version of the script demonstrating the problem, together with various commented out alternatives trying to narrow the problem down. Details of trying the alternatives, and the full error message are included in the comments at the end of the script.

--ll.Dialog(ll.GetOwner(), "Empty Table", {}, 1) --This works, presents the dialog and prints done. ll.Dialog(ll.GetOwner(), "Nil", nil, 1) --This hangs, no dialog, no done. Should either trigger an error or treat nil as an empty table. print("done") You can thank a puzzled SLua class student, Marie (MarieOmani), for triggering this error.

ll.OwnerSay("A\tB") ll.OwnerSay("C" .. string.char(9) .. "D") -- > -- A□B -- C□D same happens with ll.Say(0, "A\tB") and print("A", "B") in LSL, any version, it seems that \t is replaced with 4 white spaces: default { state_entry() { llOwnerSay("A\tB"); llOwnerSay("C" + llChar(9) + "D"); // --> // A B // C□D } } As explained in https://feedback.secondlife.com/slua-alpha/p/t-is-displayed-as this issue should be fixed in the viewer rather than using the LSL solution.

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() .

In LSL, functions like llGetTexture() return either a texture name or its UUID, both as strings, and string–key comparisons work. In SLua, string and uuid are distinct types. For instance, in an object with blank textures: print( ll.GetTexture(0) == TEXTURE_BLANK ) -- > false We must cast to uuid: print( uuid( ll.GetTexture(0) ) == TEXTURE_BLANK ) -- > true

Currently, when scripting in Luau, indexing of tables does not match between Luau functions and ll. functions. For example, the following return the same values: str = ll.List2String(List,2) and str = List[3] This isn't exactly a bug, both are functioning 'correctly', but it's going to cause some issues. Is there a reasonable solution to this?