šŸ† SLua Showcase

Show off your SLua creations!
SLua Snake Game
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
1
SLuG - SLua Graphical Programming
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...)
0
Simple remote control - Remote control mini car
Touch the physic object (car) to take the control and move it around your place. It may be improved for more functions and options. active = false linearSpeed = 0.0 angularSpeed = 0.0 function state_entry() ll.SetStatus(STATUS_PHYSICS, 1) ll.InstantMessage(ll.GetOwner(),"Touch me to activate remote control") end function touch_start(toucher) ll.RequestPermissions(ll.GetOwner(), PERMISSION_TAKE_CONTROLS) end function run_time_permissions(perm) if bit32.band(perm, PERMISSION_TAKE_CONTROLS) then ll.OwnerSay("Permissions granted.") local controlMask = bit32.bor(CONTROL_FWD, CONTROL_BACK, CONTROL_ROT_LEFT, CONTROL_ROT_RIGHT) ll.TakeControls(controlMask, 1, 0) active = true ll.SetTimerEvent(0.1) end end function control(avatar_id, level, edge) local start = bit32.band(level, edge) local finish = bit32.band(bit32.bnot(level), edge) local held = bit32.band(level, bit32.bnot(edge)) local untouched = bit32.bnot(bit32.bor(level, edge)) if (true) then if bit32.band(held, CONTROL_FWD) ~= 0 then linearSpeed = 12.0 elseif bit32.band(held, CONTROL_BACK) ~= 0 then linearSpeed = -12.0 elseif (bit32.band(held, CONTROL_FWD) == 0 or bit32.band(held, CONTROL_BACK) == 0) then linearSpeed = 0.0 end if bit32.band(held, CONTROL_ROT_LEFT) ~= 0 and linearSpeed >= 0.0 then angularSpeed = 2.5 end if bit32.band(held, CONTROL_ROT_LEFT) ~= 0 and linearSpeed <= 0.0 then angularSpeed = -2.5 end if bit32.band(held, CONTROL_ROT_RIGHT) ~= 0 and linearSpeed >= 0.0 then angularSpeed = -2.5 end if bit32.band(held, CONTROL_ROT_RIGHT) ~= 0 and linearSpeed >= 0.0 then angularSpeed = 2.5 end if (bit32.band(held, CONTROL_ROT_LEFT) == 0 or bit32.band(held, CONTROL_ROT_RIGHT) == 0) then angularSpeed = 0.0 end end end function timer() ll.SetVelocity(vector(linearSpeed, 0, 0), 1) ll.SetAngularVelocity(vector(0, 0, angularSpeed), 1) end state_entry()
0
Load More
ā†’