Mike Monkowski wrote:
> 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.
>
Not using the current server-centric model of SL, true.
But a packet injector based on grid-proxy could easily inject an object
the sim doesn't know about and control its behavior independently of
what the sim says to do. In fact, that is how the puppeteering code
worked to a certain extent, although I remain confused as to whether or
not feedback for the UI manipulations was cllientside or sent back to
the server first and then sent to the originating client as part of the
general broadcast to everyone in the sim.
Either strategy would have advantages and disadvantages I suspect and
either one might make more sense in certain contexts.
There's been some talk of client-side physics being extended.
Obviously, once you start doing that, the sim has less and less control
over what goes on. The ultimate form would be p2p-ish physics where the
sim doesn't participate at all in anything but sending geometry updates
and all calculations are shared between clients, either in a cobalt
fashion, or using a separate physics server (or hybrid).
> 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.
>
>
if you think of the teatime object server used in cobalt as a
distributed state server, you could see a scenario where all
manipulation is done using smalltalk TObjects and distributed to a
teatime server which then passes the updates back down to everyone
(including the client originating the UI manipulations).
SL client => UI plugin => teatime service <= UI plugin <= SL client
V
V
SL client <= xx-plugin <= teatime service => xx=plugin => SL client
> 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.
>
>
Except NEW behavior that is passed back and forth between clients
independently of the sim, or passed back to the sim as an afterthought
to an audience that isn't participating in the race/combat/whatever, so
they don't need the custom physics/etc packets.
Lawson
_______________________________________________
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
