Client Side Scripting via Viewer API
tracked
Journey Bunny
Week 1 ccug hit upon a topic I've been trying to organize a request about. Yay!
Per Inara Pey's summary: "In terms of HUDs, it was suggested by Vir Linden that a more cohesive approach might be to provide support directly through the existing viewer UI and using commands native to the UI rather than part of an additional scripting capability to build / operate HUDs."
This is the direction I'd love to see this go towards. LSL is designed to run server-side; rather than pick it apart and split out what can happen in-viewer, I'd love to see the viewer itself accessible via an API.
At present, to implement "that one feature"--a UI, some RLV or RLVA, something designed for gaming... in all cases the would-be developer has to develop their own entire viewer just to slide in the thing they need.
Is it too controversial to go one further, as a way so solve the inevitable next issue where people try to run code on my device?
SLAPP store? Ok, maybe a different name. But, there's a $140 billion industry that suggests people
want
to be able to take the base "OS" and to hook into pre-defined sets of "api permissions" to expand the capabilities of the device. I can envision entering a custom game region, and just like the Experience prompt now, getting a SLAPP prompt to let me know a viewer extension is needed to play the game. In this way, the permissions used would be clear (and vetted) and there'd be a much less sketch way to extend the viewer.arguments ensue
Log In
Spidey Linden
tracked
Issue tracked. We have no estimate when it may be implemented. Please see future updates here.
Journey Bunny
Adding on things that have come up from other discussions as "wants" that would be better in client-side:
- Custom viewer restrictions for gaming. Discussion ensued around extended experience permissions, but got stuck because of the need to actually implement these viewer-side.
- RLVA type viewer effects. Discussed @setSphere (https://wiki.catznip.com/index.php?title=RLVa_RFC_setsphere#.40setsphere) which creates a completely viewer-side effects (like walking through a completely dark place illuminated only in a small radius by a torch). Currently only possible by using the rlv-type command system, sending any visual changes through chat commands, which has poor real-time performance.
- Camera animation functions. Discussion with Leviathan about how to make the camera move smoothly for gaming related needs; it's difficult on server.
- HUD interactivity and responsiveness. The new llWorldPosToHUD function is awesome for many kinds of things, live updating is not one of them (eg, having a "waypoint" in-world appear over an object is magical; keeping it pinned over that object as you move is chunky). Having a future companion client-side capability to "pin" such a position transform (and thus, the viewer updates the waypoint continously without needing to ask the server to do it) would finish the deal.
- mouse-over effects. A common UI feature for tool-tips, changing a color, activating an animation, drawing a selection box around something etc...impossible in creator content now, and impractical as a server-side feature request to send mouse coordinates continuously. The viewer could handle this and use various position detection handling to signal server-side scripts only when needed.
These are pieces that have come up in passing among the content creator discussion in the past two weeks that are especially qualified for client-side handling.
Darling Brody
There are a few viewer functions that you can access using URL's embedded into text but not enough to make anything substantial. It would be nice to be able to popup custom windows to get tasks done in the viewer.
I probably wont use it though because it will be too easy for people to rip off HUD content the the way they currently take sounds, textures, and animations that must be sent to the viewer.
I would much rather LL look towards rending a stream server side and sending just the video feed to the viewer. This would protect a lot more content from theft and bring people in to make stuff knowing it cant be stolen so easily.
VriSeriphim Resident
Darling Brody: "I would much rather LL look towards rending a stream server side and sending just the video feed to the viewer."
This would make SL unusable for me as I would be competing with others at home who are streaming other things, like movies - or even also trying to play SL.
Before you say to "just" upgrade my internet service, I'm already paying for more bandwidth that my service provider is capable of supplying in my area, so paying for a higher tier of service would only waste my money.
I am sure that many other SL users have a similar situation.
Vincent Nacon
I'd like to see them do a full overhaul of the UI system, using Qt framework or the like, and then be able to access most of its feature with scripts.