🏆 SLua Showcase

Put down a few sample scripts for people to get some ideas from in Mesa A minimal "callback style" fetch sample GitHub commits over ll.HTTPRequest -- this even compares (to avoid empty commits) using correctly formatted Git shasum , which wasn't possible in LSL HTTP-in website using HTMX and Alphine.js Very basic Zalgo text generator math.noise float text example math.noise across a linkset Few of these are a bit on the rough side, will make some more minimal examples if I have time! Aside from the Zalgo one, these are all things that either weren't really possible with pure LSL, or just plain awkward. secondlife://Aditi/secondlife/SLua%20Mesa/241/250/27

The ll table is frozen, but it can be cloned and modified to enable a debug mode that lets you track function calls or perform other tricks. SCRIPTDEBUG = true if SCRIPTDEBUG then llDEBUG = ll -- store original ll table reference ll = table.clone(ll) -- replace with modifiable version -- then modify the function with debug info; calls original function afterwards ll.Say = function(c, s) llDEBUG.OwnerSay(`(DEBUG:Say at line {debug.info(2,'l')-1})`); llDEBUG.Say(c, s) end end ll.Say(0, "test") This of course costs a considerable chunk of memory as per gcinfo(), so it may not be tenable if/when harder memory limits set in.

I've been converting some of my LSL projects into SLua and set them up at the SLua sandboxes for a demonstration. At the time of this writing, what's set up: A computer (emulates a 6502 CPU and custom devices to run a computer within SL), which can be poked at and played with - the SLua implementation runs maybe 3x+ faster than LSL, thanks to easier data handling with buffers and other improvements, clocking at roughly ~1.5 kHz real CPU equivalent. Feel free to poke at it, there's a short explanation and a game to play on it. Mandelbrot/Julia fractal plotters, just the classic ones on a 40x40 pixel grid. These are fullperm including the script, right click+buy to get a copy. A complex number class, to enable doing complex number arithmetic with normal SLua equations, compatible with built in numbers. Not actually used by the fractal plotters since it's slower than optimized manual computation, but good for prototyping or just having a complex number calculator. Demo is rather minimal, just compares Euler's formula results to built-in sine and cosine. Fullperm copy via click. Will probably add more things still, as inspiration strikes. Location: SLua Mesa

Allows objects to call functions on remote scripts as if they were local, whether they're in the same object or located anywhere within the region

I have started a project to get luau-lsp compatible type definitions for SLua https://github.com/WolfGangS/sl_lua_types Currently has a guide for setup in vscode The files would work in your editor of choice if you can run selene or luau-lsp for them But am working on setup guides for other editors directly. Please log any issues you encounter in the github. I am working on getting a pr into the vscode extension for luau-lsp to make it less bothersome to setup.

At janetrossini.github.io , I have a growing series of articles about SLua scripting and testing, including at least one way of creating SLua objects with classes and methods. Comments and ideas welcome via email.

🔹 Smart Video Player for Second Life 🔹 Introducing a custom-built Video Player for Second Life – designed to play high-quality, long-duration videos directly in-world without requiring any special viewer settings or streaming protocols. Unlike traditional GIF-based displays that are limited in frame count and often suffer from quality loss, this video player supports smooth playback of full-length videos – ideal for immersive advertising and product showcases. ✅ No media settings required ✅ No streaming or external protocols ✅ Runs fully within Second Life ✅ Optimized for long videos – current demo is 3 minutes Perfect for storefront displays, interactive banners, and creative presentations where quality and duration matter. Simple to use, fully compatible, and visually impressive – a modern solution for dynamic content in Second Life.

I’ve been working on an in-world visual programming language that takes advantage of the new SLua capabilities. It is inspired by similar systems in other games or virtual worlds like Wiremod in Garry’s Mod or Protoflux in Resonite . One of the primary goals for this project is to provide a collaborative experience for teaching and learning SLua while keeping users engaged in Second Life. Demo Anyone can grab a copy in (SLua Tideland/48/240/23). Be sure to check back occasionally for updates! The in-world version comes with a notecard that provides additional information about use of the system. Dynamic Function Signature Lookup The system was designed to minimize the amount of hard-coded SLua function and event signatures, but some compromises had to be made due to either SLua language/runtime constraints or time budget for getting this project into the SLua Showcase. The possibilities with this system are impressive, but it is probably quite abusive of the simulator. The SLuG controller first rezzes a “checker” object and passes it the name of the function the user wants to place. The checker then repeatedly calls pcall with the target ll.function and a varying number and type of arguments until it succeeds and generates an appropriate function signature (type and number of arguments and returns). The checker then sends the completed signature back to the controller, deletes itself, and the controller adds the node to the board with the appropriate signature. One of the experimental implementations for the checker could even time the execution to determine any forced sleep, but it was removed from SLuG since it isn’t necessary. Shortcomings The checker for determining function signatures relies on parsing error messages which likely aren’t guaranteed to stay static, at least during the Alpha and Beta periods. Currently each event or function node in the graph is a separate script (and object). This means that many ll.Detected* functions cannot be used since they have no way to “called within” the appropriate event. Also, many events such as http_response or dataserver are triggered by ll.* function calls. Lists are also quite poorly handled by the current system. There is currently no way to insert, delete, or access elements. Functions that rely heavily on lists such as the PrimitiveParams family or ll.ParticleSystem can be placed on the graph, but require innate knowledge of their list parameters since a signature cannot be generated for the contents of a list . SLua Wishlist The building and design of this system highlighted a few areas of improvement for SLua that would allow for event more capabilities in the future. Links to relevant Canny tickets and descriptions of what it would bring to SLuG follow. Improved Event Registration - https://feedback.secondlife.com/slua-alpha/p/object-touchability-not-updated-if-touch-event-assigned-outside-global-scope Since SLuG currently uses one object/script for event nodes on the graph, the only way to dynamically add a handler is for the script to pre-register a handler for all events and then nil -out any that aren’t the intended event for the node. tovector and toquaternion return nil on invalid input - https://feedback.secondlife.com/slua-alpha/p/make-tovector-and-toquaternion-return-nil-on-invalid-inputs SLuG allows users to specify constants for use in their graphs, and these values are stored as strings. They are casted when they are passed as input to another node, and this change will allow SLuG to provide helpful error information. Current Features Users can select and place a few different types of nodes Functions ( ll.* only for now) Events (signatures hard-coded) Constant Values Users can connect the outputs of one node to the inputs of another. This connection performs basic type checking and will ensure that the user cannot connect dissimilar types. One exception to this (at least at this time) is that Constant nodes output an any type. When an any output is connected to a non-any input the receiving node will cast the value to the appropriate type when it is executed. Planned Features and Improvements Target Object A script that can be placed in an object (separate from the SLuG panel) where the SLua events would be received and functions (at least the ones that affect world state) can be executed. This alone would dramatically increase the usefulness of the system, and is my current main development task. (More planned, but trimmed to fit Canny. Also lost some nested bullet points...)

This game is scratch built in Lua in some free time I have had over the past 5~ days. Initially started with just cells that change color, and green/yellow for food. Then added a sprite sheet, and realised (with some feedback) I was missing a few critical features: Snake could not "pause" for one frame before edges and collisions (iframes?) Sprite sheet was limited and could not handle "turns" Grid was not dynamic, could not change size Adding a menu, and support for multiple players would've required massive restructuring the code So, obviously... I started over. I did however distract myself for a moment with a feature complete high-score tracker, I've shared the code for that in Discord ! Anyway, since then I've added a few more features: Lua object (metatable) for the player, allowing easy reset that state, and later multiple players Lua object (metatable) for the world, allowing for dynamic grid size Sprite table for simplified lookup i.e. SPRITE_LOOKUP.HEAD[direction] , and bit32.bor logic for turns Sprite font rendering for the score, and game over message State management, and render on demand (update methods return true if we need to render) Error catching during update/render loop (see the blue screen screenshot!) I do plan to share some more findings once I've had a chance to start looking at multi-player (and separate scripts that buffer controls), plus some menu logic. Finally, I want to say that Lua brings a lot of convenience to the table . It allows for the creation of objects with methods (organisation and encapsulation), wrapping events with callbacks (again more encapsulation), and ease of data lookup; with in-memory (key-value stores), and multi-dimensional arrays. Given the above, don't think I would have attempted to build this in LSL. It would have taken at least five times longer, and managing strided lists would have been quite challenging. Additionally, if I needed to revisit the LSL code later, it would have been difficult to debug and maintain. secondlife://Aditi/secondlife/SLua%20Mesa/217/245/23

A simple avoid-the-fireballs game, written using SLua. Avoid the fireballs while catching the coins as they come your way! See if you can set a new high score! Uses coroutines for each sprite's animations and hit-tracking, keeping everything in sync. Mostly written using ll.SetLinkPrimitiveParamsFast. Not as efficient as it probably could be, but I wanted some coroutine practice! :) Try it out Here