[opensource-dev] Client-side scripting in Snowglobe

Mike Monkowski monkowsk at fishkill.ibm.com
Fri Feb 19 15:00:29 PST 2010


Client-side scripts can only operate on data that is client-side.  It 
means that they do not operated directly on in-world objects.  They only 
access the client's representation of those objects.  Any actions 
performed by a client-side script would only be visible to that 
particular client.  So attachment scripts and vehicle scripts are not 
candidates for client-side scripting.

Before worrying about what language the scripts should be written in, 
someone has to figure out functions that can operate on the client data 
model.  So anything related to chat is fair game, as is anything related 
to polygons and meshes, although any modifications to these would be 
visible only locally (like beacons).  Anything related to the UI could 
be scripted client-side.  Accessibility extensions could be client-side.

Emerald uses a lot of information in the local avatars data model for 
its radar.  Those kinds of things would be available for defining getter 
functions.

But expect that most functions that operate server-side (most LSL 
functions) will not be able to operate client-side.  You can't just 
offload those functions to the client.  It would be like talking to your 
television and expecting the characters on the screen to hear you.  If 
the capability doesn't exist in the client-to-server messages now, a 
client-side script could not communicate it to the servers, where all 
assets reside.

Mike

Domino Marama 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
>><domino at 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..


More information about the opensource-dev mailing list