📃 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.

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

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.

You're already working on a major overhaul with Lua. NOW is the right time. It will NEVER, EVER be easier than RIGHT NOW. You will NEVER be able to reduce future capex on inefficient scripting overhead more easily than RIGHT NOW. Link messages: Good for broadcasting messages between scripts where it doesn't matter much if it takes a few milliseconds to arrive, and you don't mind scripting some asynchronous handler to respond if necessary. Doesn't do a good job at supporting proper organization of software in accordance with modern standards any developer expects. OK for the the Single Responsibility Principle and to some extent the Interface Segregation Principle. Does absolutely nothing to help with unit or integration tests. No serious programmer is looking at this and saying, "yes, this is good and cool." Direct, synchronous calls to public interfaces between objects: Java, TypeScript, C#, Lua (not mentioning this by accident), Python, and any other serious programming language you can mention, supports this natively. This was introduced in Simula 67 in 1967, and has been INDUSTRY-SANDARD ever since, because it's awesome and it rules. We get to call public methods on other objects (scripts) synchronously, just as fast, or nearly so, as we would call a function in the same script. You DON'T have to engineer a massive comprehensive interface mechanism between scripts, or build an include mechanism. You add ONE transmitting function to the LL library, back-end routing between Luau states in the back-end, and an in-script state handler which receives and responds to these messages. That's it! We don't have to engineer extremely hacky workarounds that force an asynchronous mechanism to serve for what would be VASTLY improved if it was synchronous. We get to write unit and integration tests without cramming them into the same file as production code, where they take up valuable RAM. We feel like we're using a real programming language, one which allows us to use the same patterns and techniques as ANY serious programming language from the last 58 years. Real Example (my aircraft physics system): A Weight & Balance script scans the linkset to determine where all the components are, their volumes and orientations. These are mapped to inertia proxies (cuboid, flat plate, thin hoop, etc) and used to calculate the inertia tensor. The airfoil prims are then split into segments (blade element theory) and have control surface information assigned. Linear force physics script has to obtain a full copy of all the airfoil parameters and segments from W&B. Moments (angular force) physics script has to do the same thing, and spend the same memory. Now the object has three independent copies of the same data. There are a ton of copy-pasted functions between these scripts because there is no #include method. This requires more storage for the script source, compiled bytecode, stack and heap segments as well. Not just for airfoil parameters, but for MANY, MANY other things that Linear and Moments both have to know about. If Linear and Moments both run timers, then LL pays for CPU for that. They are only in separate scripts to work around RAM limitations! If they could call a shared lib script in near-real-time, they could be in ONE script with ONE timer. LL is paying for all that overhead. I am losing huge amounts of time dealing with it. Everybody loses, and it sucks. Every other day I'm fighting stack-heap collisions, and wishing I had some way to effectively write unit tests. The constant discouragement is dragging me down unnecessarily. With direct inter-script calls: llInvoke(link, scriptKey, "method", args...) -> Luau back-end routes call from one Lua state (script) to the other, then returns whatever needs to be returned. (Just an example.) You can make this only work in the link set, or make it work sim-wide. (Sim-wide would enable a lot of cool stuff that relies on llRegionSay() now.) Transmitting script blocks until response received. If access control is desired on the receiving end, you can add a pin to the invoke message (a la the existing "remote load script PIN"), or whatever. In my project, Linear and Moments can just ask W&B for airfoil data in near-real time, and get an answer back in microseconds. Functions for calculating rho, tangential velocity, dozens of aeronautical equations, etc. can be in a standard library. Scripts can call that library, again, getting answers back in microseconds, instead of all that copy-pasted code gobbling up space on YOUR servers. You don't have to provide an #include mechanism, further conserving space. I can write UNIT AND INTEGRATION TESTS!!! and stop relying on horrid llOwnerSay() spam for everything. I can stop feeling so EXHAUSTED while trying to do serious innovation in SL. More efficient scripts from now on -> reduced capex for LL. LL wins, SL developers win, users win, EVERYBODY WINS. What's not to like?

In 1-prim objects, root prim has link number 0. In other prims, root prim has link number 1 ( =LINK_ROOT ). This behavior should change: It's a pain to make scripts work with both types of objects Link numbers are so close to already using 1-based indexing, like everything else in SLua has been already changed to. This change would complete that transition For functions that accept a link number: 0 and 1 should both be treated equally as the root prim number, regardless of prim count This change should be made in SLua at least, but possibly in LSL and Mono as well. (it's probably easier to change both) I can't think of a reason this would break existing LSL content, as it only makes the functions do something useful where they previously did nothing (Suzanna thought of a theoretical reason it could break code below) For functions that return a link number: In LSL, they must be left alone, as this check is somewhat common to test for 1-prim vs multi-prim: if (llGetLinkNumber()) In SLua, they should be changed to always return 1 ( =LINK_ROOT ). This makes them more consistent, and SLua has no backwards compatibility concerns yet (This is the main reason this proposal is in SLua-Alpha and not Scripting Bugs) These functions accept link numbers, and return a prim property: ll.AvatarOnLinkSitTarget ll.GetLinkKey ll.GetLinkMedia ll.GetLinkName ll.GetLinkNumberOfSides ll.GetLinkPrimitiveParams ll.GetLinkSitFlags ll.GetObjectLinkKey ll.IsLinkGLTFMaterial These functions accept link numbers, and modify them: ll.BreakLink ll.ClearLinkMedia ll.LinkAdjustSoundVolume ll.LinkParticleSystem ll.LinkPlaySound ll.LinkSetSoundQueueing ll.LinkSetSoundRadius ll.LinkSitTarget ll.LinkSetSoundRadius ll.MessageLinked ll.SetLinkAlpha ll.SetLinkCamera ll.SetLinkColor ll.SetLinkGLTFOverrides ll.SetLinkMedia ll.SetLinkPrimitiveParams ll.SetLinkPrimitiveParams({PRIM_LINK_TARGET}) ll.SetLinkPrimitiveParamsFast ll.SetLinkPrimitiveParamsFast({PRIM_LINK_TARGET}) ll.SetLinkRenderMaterial ll.SetLinkSitFlags ll.SetLinkTexture ll.SetLinkTextureAnim ll.SetPrimitiveParams({PRIM_LINK_TARGET}) ll.SitOnLink These functions return a link number: LLEvents.link_message ll.CastRay ll.DetectedLinkNumber DetectedEvent.getLinkNumber ll.GetLinkNumber ll.GetObjectDetails({OBJECT_LINK_NUMBER})

Having math.randomseed start a consistent pseudorandom sequence in each script when calling math.random allows saving and restoring, or transmitting any procedurally generated object simply by storing, recalling, or transmitting the seed, assuming knowledge of the procedure used to generate the object, be it an instance of a puzzle, a maze, a level in a game or whatever. Without this, one is obliged to either save, restore, and/or transmit potentially a great deal of data, or to create one's own pseudorandom number generator that does not depend on math.random. Also, when debugging a script, being able to repeat a psuedorandom sequence to get consistent results among trials can be invaluable when dealing with intermittent faults and tracking down uncommon errors. I like the idea that if math.randomseed has not been called, that the effective seed is itself random as is presently the case. Nevertheless, for the above reasons, I feel that it is valuable to be able to stipulate a seed that applies specifically to the script in question and does not affect and is not affect by sequences being generated by any other scripts concurrently running. On possible option that might be less painful than completely replacing the current implementation, could be to add a second math.rand and math.randseed pair that performed as described above, using a relatively simple, fast algorithm that might not be guaranteed to be quite as well randomized as math.random, but that is adequate for randomized procedural object generation.

In the script editor, the dropdown gives 3 options for compiling LSL, and 1 for SLua. I think they would be better named: SLua LSL-128 (on SLua) LSL-64 (on Mono) LSL-16 (on LSO) "LSL-128" is clear, compact, and and easily distinguishable from both "Mono" and "SLua", which already have colloquial names. I also reversed the list to put them in order of most to least recommended Edited with input from Nexii Malthus, Suzanna Linn, and Kristy Aurelia

Luau scripts have a lot more ways to crash than LSL scripts. I wrote this as a proof of concept on making LLTimers and LLEvents crash proof: https://gist.github.com/tapple/70b874b3801d6cbf103559287e85b964 It might be nice if there was a function like LLEvents:setDefaultErrorHandler(errorHandler) that did the same thing the above code does, without needing to wrap/monkey patch anything.

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