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 >><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
