📃 SLua Alpha

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.

The rational is simple enough. Even though 128k is bigger than ever, it's not infinite. Optimization controls that are "standard" aren't as useful as optimization controls that fit the demands of second life. Optimizations that reduce code footprint (e.g. aggressive constant folding) should be usable without triggering optimizations that increase code size in the name of performance. I don't know what optimizations are available, and how you want to treat optimization control in scripts, but it seems that tailoring them to fit second life make sense.

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

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?

Possibly related to [ https://feedback.secondlife.com/scripting-bugs/p/script-suddently-losing-connetion-with-the-server-on-save ] A few times I've gotten the above error. Fixing the syntax error does not eliminate the message — it's as if the script inventory instance is permanently disabled. My workaround has been to copy the script text to a new inventory instance. I was able to reproduce this on SLua Tombolo. 1) Create a block and add a new SLua script to it. 2) Change line 1 to: `` xxx ll.Say(0, "Hello, Avatar!") `` 3) Save. See an expected, normal error message. 4) Clone the object. Edit the script in the clone. 5) Notice the cloned script is marked not-running. 6) Use the external editor button to edit the cloned script. See the dreaded (0,0) error. (I am using BBEdit as my external editor: /usr/bin/open -a bbedit "%s" ) --- Second Life Project lua editor 7.1.12.13973830462 (64bit) Release Notes You are at 194.7, 250.2, 23.1 in SLua Tombolo located at simhost-0766603a88e3665d6.aditi SLURL: secondlife://Aditi/secondlife/SLua%20Tombolo/195/250/23 (global coordinates 41154.7, 23802.2, 23.1) Luau 2025-03-27.14115520293 Release Notes CPU: Apple M2 Max (2400 MHz) Memory: 32768 MB OS Version: macOS 15.3.2 Darwin 24.3.0 Darwin Kernel Version 24.3.0: Thu Jan 2 20:24:23 PST 2025; root:xnu-11215.81.4~3/RELEASE_ARM64_T6020 x86_64 Graphics Card Vendor: Apple Graphics Card: Apple M2 Max OpenGL Version: 4.1 Metal - 89.3 Window size: 2602x2102 Font Size Adjustment: 96pt UI Scaling: 1 Draw distance: 512m Bandwidth: 3000kbit/s LOD factor: 1.25 Render quality: 2 Texture memory: 21845MB Disk cache: Max size 1638.4 MB (99.9% used) HiDPI display mode: true J2C Decoder Version: KDU v7.10.4 Audio Driver Version: OpenAL, version 1.1 ALSOFT 1.23.1 / OpenAL Community / OpenAL Soft: OpenAL Soft Dullahan: 1.14.0.202408091638 CEF: 118.4.1+g3dd6078+chromium-118.0.5993.54 Chromium: 118.0.5993.54 LibVLC Version: 3.0.21 Voice Server Version: Not Connected Packets Lost: 13/10384 (0.1%) March 30 2025 06:20:01

Don't know a better place to ask. I know some beta regions outside the SLua cluster on main grid are already running it, so are there plans to have it available for the birthday expo?

ll.LinksetDataRead("key") and ll.LinksetDataReadProtected("key", "pass") both will return an empty string if trying to access a stored value that doesn't exist. Which is not "nil". Can we get it so that if a key pair does not exist in the LSD store that the return is actually a "nil" type instead? It would also return nil on a protected key with a bad "pass". We have access to the nil data type with SLua now, and it'd be more logical for a non-existent key to return nil for a simple boolean test. IMO. Just an idea at least. Added thought: maybe have "llcompat" have the return still be a zero length ("") string for, well, compatibility sake.

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})