SLuG - SLua Graphical Programming
Clapping Cheeks
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 adda handler is for the script to pre-register a handler for all events and thennil-out any that arenāt the intended event for the node.
- tovectorandtoquaternionreturnnilon 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 anytype. When ananyoutput 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...)
Log In