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