[opensource-dev] Client-side scripting in Snowglobe

Lawson English lenglish5 at cox.net
Fri Feb 19 14:29:16 PST 2010

Maggie Leber (sl: Maggie Darwin) wrote:
> On Fri, Feb 19, 2010 at 2:49 PM, Edward Artaud <edward.artaud at gmail.com> wrote:
>>  For client-side scripts to be something worth
>> prioritizing implementing in mainstream viewers, their usage must be
>> based on the assumption that some large percentage (80+% maybe) of
>> attachment scripts, for example, would be running client-side...
> Uh...I didn't really see viewer-side scripting as something that would
> make any significant dent in what's done today with scripted objects
> serverside except in the case of some HUD objects.
> I was thinking of this as new function, and only incidentally
> providing some marginal performance relief for LLs servers in limited
> cases...such as how Emerald's avatar radar reduces or eliminates
> avatar radar HUDs.
> Love to hear other views on this...

Depends on what is being done with it of course. a squeak interface 
(say) tied to the socket/shared memory connection could prototype just 
about any kind of extension/facility (as long as it used already 
existing events).

Suppose, for example, there was a way to use the media plugin's shared 
memory as  a sculpty map rather than simply as a texture to be painted 
on a prim.  One could manipulate the vertices of the sculpy via a plugin 
and have the changes show up in the client without putting extra strain 
on the sim. The state might be shared via p2p connections between 
clients' plugins,  or collaborative clients could share state 2 ways via 
a server (or p2p), while an audience could subscribe to a one-way 
connection of some kind, or the animation could be cached in a 
distributed file, or it might not be shared at all if someone were 
working on a test of a new animation and wanted to see what it would 
look like in-world before distribution.

One could have high-end content creation tools hooked into the client 
this way and manipulate anything from a prim or texture all the way to 
the full scenegraph. physics could be modded the same way. Likewise with 
custom scriptable objects.

This is basically a hybridization of the croquet/cobalt strategy for 
virtual worlds and the VWRAP strategy so anything you could do with 
either should be possible this way.


More information about the opensource-dev mailing list