[sldev] Generic LSL->Client Comms
dale at daleglass.net
Tue Feb 27 19:22:36 PST 2007
В сообщении от 28 февраля 2007 01:40 Argent Stonecutter написал(a):
> Because I'm looking at making this easy to use for the kind of people
> I find myself helping with LSL scripting on a regular basis.
But by trying to make it too simple you'll very possibly end up complicating
it. IMO, simple things far too often end up as a complicated mess when there
is a limitation and it has to be worked around in some strange way.
I also thought you wanted to implement plugins in this way, by doing it all
through a socket.
> Fair enough. But the format for the simple case needs to be simpler
> than XML.
I think XML comes quite nicely here, IMO. After all this is a moving codebase
we don't have control of. Tomorrow a new message type could appear, and
you'll need the protocol to deal with that sort of thing gracefully. And by
then you're half the way to reinventing XML.
Of course, there are alternatives (YAML for example), but it all seems to
reduce to the same thing: ability to represent nested structures, possibility
of adding extra data without breaking the parser, dealing with delimiters and
unicode, etc. Might as well use XML since the parser is already in the
> Um, the vehicle movements in SL are controlled by the linear and
> rotational motors, the user's control inputs aren't meaningful to the
> client at all... they're passed to the script which changes the motor
> parameters. There's nothing to base client-side prediction on... for
> aircraft, at least, the only controls that are near universal are
> left and right and how they behave differs from one craft to another.
Hm, ok, that was a bad example. I was thinking that something could be
predicted based on the vehicle's params, but I guess not.
Anyway, you still can do prediction for the avatar, so I still think sending
keypresses would be the better way. Will work better if you want to control
the avatar, and doesn't need a script to support it.
> What does your avatar list have to do with this? I'm talking about
Just using it for the sake of an example
> things like music player controls, local environment sensors,
LSL is rather weak for this. If you want stats, just get them from the client
itself, which gets a whole lot more, and you don't even need to request
> What I generally do is something like this:
> If the message starts with a pound sign, it's followed by a byte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070228/d8069331/attachment.pgp
More information about the SLDev