Lua Viewer Alpha

As a programmer, I've never been a fan of Lua. It's cumbersome, and tries to "do things differently" than every other scripting language. Take for example array indexes. Everyone is familiar with index zero being the first entry of an array. Lua uses index one. Going back and forth between the two when trying to interface stuff with LSL is going to be a pain, because if I have a index that is entry 14 in LSL, it will be entry 15 in Lua. Or how everything is separated, and there is no object model, except for when there is a object model, but the decision of a object model is completely random. If you want to insert into a table, you don't do MyTable.append() , or MyTable.push() , you have to call the "table" object, which has a function "insert": table.insert(MyTable, MyValue) . Another is Lua's bitwise. I forget what the functions are specifically, but I remember when I had to do stuff in Garry's Mod, if you wanted to do bitwise operators, it was stuff like bit.xor(a, b) instead of what everyone else does like a^b . Don't get me wrong, I really appreciate that there is effort going to do client side scripting, and it would be hella useful, but I don't see Lua as the future. It's been dying out of favor from what I've seen, even Garry Newman (The creator of Garry's Mod) has fallen out with Lua. ( https://garry.net/posts/i-fell-out-of-love-with-lua ) It would make more sense to use a language that is more in-line with what people are familiar with, such as Python or JavaScript. If sandboxing is a issue(EG: Preventing file access), the V8 engine is what NodeJS uses. NodeJS just implements interfaces such as file access into V8. Otherwise, V8 is just a engine for JavaScript without any bells/whistles. ( https://v8.dev ) Javascript even comes with the benefit of being able to do WASM, which is almost on par with native machine code. If Lua is ultimately the decided language, I really really do not see myself using it. I had to use it recently to implement interfaces for a DNS service(PowerDNS), and it was horribly painful to work with, because it felt like everything I knew about programming was thrown out the window. I highly ask that a second look be taken on which language to use for client side scripting, I really do not feel that Lua fits with Second Life, and that there are much better choices to choose from, especially ones that would better align with what people who do programming in Second Life are familiar with.

I would really like this to be more tightly integrated into the existing sl ecosystem so products can be made that use. My suggestion would be to create a new file type in sl for lua files that is basically notecards except they can be saved with an experience. If a lua file is saved with an experience and provided to a user they may choose to run that script client side and such scripts provided from server to client with a saved experience functioning as a digital signature get one more permission client side, they can read and send chat messages on all channels (not just public). Along with this I would like to see one more function added to LSL that allows a script saved in an experience to load a lua file saved with the same experience for the user. With such a system we could actually make an entirely new era of huds and other products for SL. Along with have some level of security and accountability for any bad actors.

On topic of using client side scripts to draw UI, I think it would be very helpful if we are able to anchor any generated UI to an object inworld, for example draw a dialog and have it appear to be floating next to an object.

In Brief If a client side scripting solution is decided on, I would suggest either some form of official clientside script repository, or a way of scripts being signed to run clientside so that the script could be removed, or signature can be revoked incase of abuse. The problem There is a huge desire for products in sl to be able to load a script into the viewer for increased functionality. See this request There is also a desire for the client side scripting to be very powerful. (For instance RLV like control of inventory may be an almost minimum level requirement desired for clientside scripting) These 2 desires cause 2 main problems that this proposal could resolve to some degree. Security Shared Experience Without a solution to this we could see a rejection of clientside scripts as they are regarded as unsafe and or unwieldly with further fragmentation of experience as users do or do not have certain scripts installed if there is no way for an LSL script to guranree a clientside script is loaded. Security For security we would need a very granular permission system, which will inevitably result in people either refusing them because they don't understand, or just clicking yes because they don't understand/care. Which are both bad outcomes.... This is also assuming that nobody finds some exploit to escape whatever sandboxing will be done on clientside scripts. And as scripts being signed/ in repo, can require them to be full and cleanly open source, some level of abuse can be prevented / inspected from the start. A permission system would still be very desirable, but less critical and less of a problem if scripts that can run in a default setup are vetted somewhat in advance. Shared Experience For shared experience, we could end up rapidly devolving into "Script only works on X viewer because that's what I designed it for" kind of products. With this solution an LSL script could prompt for a known good clientside script to be running/installed on the users viewer with user approval, and get expected functionality from it, Consistently across viewers as there would be little incentive for a TPV to break what is available to these scripts. Propsed Solution Summary A form of script signing, or official repository, managed by LL or some approved user group, to be the only way remote code could be loaded would solve most of those problems. This would not prevent people from running custom clientside scripts, but allow LSL scripts to interact with "known good" clientside functionality provided by scripts. I would also suggest to prevent people just telling others to "go download this zip and extract it here" that this signature/repository source, be enforced by default. Thus lsl could run something like llPromptForClientsideScript(<some_form_of_script_id>) and get a response from the viewer once the script has either been loaded (installed and loaded or if it already running etc), or the user declined the script. Problems I see with this proposed solution This would require anyone wanting new functionality for a general sl audience to either get their script approved, or get their functionality added to an existing project that's in good standing. Though this could still be faster and easier than getting desired features included into current viewers. To alleviate the above somewhat, I would suggest some form of "Good Standing" where once added, a source (be that a project or individual) can update their script with less manual oversight. It adds some extra continuous workload to LL or whatever user group. is decided to be in control of approval. Opinionated decisions will likely be a problem, with some features being deemed inappropriate by some and not by others. Developers / Power Users To allow for the creation of scripts and tinkering by power users, I would suggest the viewer needs to be launched with some sort of flag to disable the signature/repo requirement. With some clear warnings to less experienced users as to the risks this may entail.

You know, it has been years that I implemented Lua scripting in the Cool VL Viewer, with automation features (based on Lua callbacks for the various events happening in the viewer or in world), UI customizations (you can design your own Lua floaters if you want), Lua threading support (better than coroutines since they do not impact the viewer main thread as much as the latter), Lua and LSL interaction (and Lua and D-Bus interaction too, under Linux) etc... Granted, my viewer is very different from LL's, but most of what I implemented for Lua could be backported to LL's code base (and all TPVs deriving from it). The full documentation for my implementation is available here: http://sldev.free.fr/CoolVLViewerLuaManual.pdf

Ooo, nice I'm glad LL is finally looking into developing a modern scripting alternative to LSL. Thank you. Lua isn't hard to learn so it probably will be ok for most people, and it is pretty fast and easy to embed. However, everything is a table and they're a bit tedious for some purposes. But, I definitely think scripters will more rapidly develop in Lua than LSL, so thanks for putting effort into moving forward. While I love Python, it is a bit sluggish as an embedded scripting language. I would have personally recommended something more along the lines of Javascript since everyone knows JS, it is a very modern language and it performs really well. And, even though it can be insecure on the web... LL would have been able to tighten the VM up on your end you can restrict what it can do. So, I think it would have been a more modern and well established route to go. And, while there are a lot of naysayers regarding Lua on this thread I personally believe you've made a better choice of at least picking something and moving forward, LSL is too antiquated and limited. I do hope it is secured properly, however. This kind of move shouldn't be taken lightly, don't forget.

I think it would be useful to be able to set particle effects on an object from client side script such that only that client saw the effect. This would be useful in game type experiences where an objective needs to be highlighted to the user

I've got a soft spot for MMORPG UI and would like to be able to client side script custom RPG UI with my own theme and style. I'd want a great deal of artistic control over how the UI looked and also be able to do hover effects and other things that feel 'native' that standard huds just can't provide. I'd want to do a chat replacement in rpg style, We'd probably need some way to do text input UI and maybe also let us send stuff into local chat from said input/receive local chat in the client side script? I suppose lsl scripts could act as local chat relays though. It would be cool to essentially just temporarily get rid of the entire SecondLife UI during a game and replace it with a totally different game specific one, although this would probably need some clear easy way out for the user. I am not sure how something like this would best be implemented. I am simply stating the desired goal for now, and not presenting a solution. This is just food for thought.

I think a useful client side script feature would be the ability to cap draw distance. Reason for this is whilst the user usually sets their draw distance as far as performance permits, inside skyboxes, it is often not desirable to render neighboring skyboxes, or one skybox casts a shadow over another etc. If we had the ability to cap draw distance from client side script, a script could automatically cap draw distance when the user enters one of these skyboxes for better immersion

If you push the forward key in an llVehicle, the signal gets sent to simulator, script does something, result of input comes back. What I'm trying to say is vehicles in SL have latency that other multiplayer games don't. If the client can be told basics about the llVehicle it could be making a good guess about what the vehicle should be doing before it gets a definitive answer from the simulator, thus making vehicles appear much snappier as the result of input would be instant client-side Or perhaps even make it possible for a client side script to be authorative on an objects position and run the physics simulation client side, just sending results to simulator for other residents to see? (I'm currently just throwing random ideas out there to see what sticks, sorry if my posts seem excessive)