The client-side scripts that we are talking about in this thread are not related to in-world LSL scripts in any way. They always execute client-side, isolated in their respective processes, and they only talk directly to the client and sometimes also to local PC resources, such as the text-to-speech example I described earlier.
Of course, if one of the viewer's script API functions provides communication with the world, then indirectly the client-side script would be able to interact with the world too, but that is indirect, by invoking a viewer API function through a message. It is entirely up to the viewer to define which messages are accepted from a script and which API functions are invoked by that message. Because scripts can interact with the viewer only through the messaging interface, they cannot do anything to the viewer or to the world that the viewer does not permit. Nothing would happen to a client-side script directly when you change regions. However, the script could receive LeavingRegion and EnteringRegion events from the viewer if it registered its interest in callbacks for them. Also, a script could register interest in CurrentPosition events, which the viewer would send to the script periodically with a requested time interval, or maybe with a requested spatial resolution granularity. TRAVEL LOGGER Add the region callbacks and position callbacks together and you have the basis for a very simple *travel logger* script, logging your travels to your local machine. This could even play back its voyage and send you around the world revisiting old places again. That's another nice use case for client-side scripting, and very simple to do. Morgaine. ====================================== On Fri, Feb 19, 2010 at 9:35 PM, Domino Marama <dom...@dominodesigns.info>wrote: > On Fri, 2010-02-19 at 15:57 -0500, Maggie Leber (sl: Maggie Darwin) > wrote: > > On Fri, Feb 19, 2010 at 3:08 PM, Domino Marama > > <dom...@dominodesigns.info> wrote: > > > > > I'd hope things like attachment sizing scripts would move to client > side > > > scripts. > > > > I guess that would be nice, but the data that would have to flow to > > the attached hair prims would be substantial....and the prims would > > still have to be scripted. I wouldn't expect to see much savings from > > that. > > Depends on implementation. I'm assuming client side scripts won't need > transferring sim to sim on teleports, so scripts such as these that > don't need to be active on the sim seem like good candidates to me. > > If anything I'd have thought the data flow with the vehicle scripts > would be more of an issue as that'd be constant messaging between the > client and server parts. It would need careful testing to make sure that > moving the maths client side was more efficient. Even without my crazy > ideas on doing torque based acceleration curves, it's likely that people > will overdo messaging (if it's a feature) with stuff like client hud > speedos for vehicles.. > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges >
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
