[opensource-dev] Client-side scripting in Snowglobe
morgaine.dinova at googlemail.com
Fri Feb 19 14:49:00 PST 2010
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
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.
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.
On Fri, Feb 19, 2010 at 9:35 PM, Domino Marama <domino at dominodesigns.info>wrote:
> On Fri, 2010-02-19 at 15:57 -0500, Maggie Leber (sl: Maggie Darwin)
> > On Fri, Feb 19, 2010 at 3:08 PM, Domino Marama
> > <domino at dominodesigns.info> wrote:
> > > I'd hope things like attachment sizing scripts would move to client
> > > 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:
> Please read the policies before posting to keep unmoderated posting
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the opensource-dev