As a former programmer, I applaud revamping the old LSL language. I'm not sure about the ll. change... I would rather have Lua be more of an upgraded, still supporting LSL functions transparently. I would also like LL supply some tools to code the new Language. The old lslEditor is still my go to for working offline on code.
Log In
steph Arnott
lslEditor is an antiquated has been, it has not been updated in years.
Bleuhazenfurfle Resident
Seems like LSL isn't going anywhere, it'll just switch over to using Lua bytecode, instead of Mono bytecode. If you want to write LSL, then keep doing so.
But Lua presents an opportunity to fix the many many many horrible things that hold LSL back, not just be LSL all over again. I said recently on the forums, we need people to propose frameworks that actually make use of the benefits and capabilities Lua offers, and for LL to then select one and make it standard when they bring Lua out to the masses, so that people coming to scripting have an on-road that introduces the capabilities of Lua by having them actually be used naturally and positively.
Things like llSLPP/llGLPP being replaced by a command that gets a reference to an object, and then you just change it's properties, and call methods on it, and so forth. The handle returned from ll.Listen could support enable, disable, and close methods, and provide access to the parameters that were used to create it. Keys could be actual binary keys rather than the evil bloated demon constructs they are in LSL (falling back to strings at the interfact, when needed). I believe Lua supports binary strings, so we can have actual encryption, and one of several tight binary packing formats which are MUCH more compact than JSON, and a bunch of other things LSL couldn't have because of that limitation. So on and so forth. Some bad decisions made early on in LSL, presumably in a rush to get SOMETHING usable — lets not just persist those limitations out of little more than laziness, and an undue reluctance to change.
I'd also love to see the events moved into a table, and being invoked as object methods. Though I recognise that would likely break the "assign a value to the name, and it becomes active" thing, so perhaps just adding a built in function that object binds events from a table to their slots, clearing out any not present in the table as it goes. And a naming pattern would be good — append _event to them all, just to distinguish them from everything else. One limitation of LSL states, was we couldn't have state-specific methods and data, this is an opportunity to provide that for those who want it.
These are some of the kinds of things that can be considered now, there's a whole bunch of stuff Lua can allow that would bring SL scripting forwards into the present, rather than remaining the necessary but ugly stain on SL that it is.