Lua Viewer Alpha

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

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

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.

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)

Please kill this project immediately and waste no further resources on it. It provides no additional functionality above and beyond what Third Party Viewers already provide, and makes life more difficult for everyone by further complicating the SL user experience and opening up additional problems as people try to distribute "Plugins" for SL that contain who knows what. I can already see the group-chat spam "Download My Newest TotalRLV Plugin for SL" and posts a link to ransomware.exe

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

Since client side scripting is being explored and developed I thought I'd express my personal desire to not only expose 'get' and 'set' of client state via script, but also the ability to 'restrict' certain actions For example, for certain types of games, the ability to restrict seeing other players on the minimap would be a useful gameplay mechanic. But the problem is if we only have 'get' and 'set', whilst our lua script might hide the map, another script could then show it again or the player could just open it again themselves. The ability to set constraints would therefor be useful. The constraints could be tied to an attachment assuming we can run lua scripts on avatars in inworld objects such that the constraint releases when the attachment is removed. Other lua scripts would not be able to remove the constraint if that makes sense - so we can be sure the user is not cheating the game. examples of useful constraints might be disallow flight radar/minimap don't show avatars nearby max alt cam distance max draw distance (think skyboxes)

Ability for a client side script to draw a section of an arbitrary nearby avatar in HUD space. ie. so you could do a live portrait of someones avatar head as part of a HUD. Think of games like starfox or visual novels where the heads of characters are displayed. Obviously scope for abuse so limits would have to be thought about too. Just throwing random thoughts out.