[sldev] Generic LSL->Client Comms
dale at daleglass.net
Tue Feb 27 15:54:55 PST 2007
В сообщении от 27 февраля 2007 23:51 Argent Stonecutter написал(a):
> Because connecting to a socket is a few lines of code, because you
> can connect to a socket in just about any scripting language on any
> platform, because you're using the viewer anyway, because libsl
> doesn't connect through the viewer.
Why "anyway"? If all you have is a chat channel, and none of the client's
benefits, then about the only benefit over using libsecondlife is that you
get the viewer to speak for you.
You could do the socket thing in libsecondlife as well, or even easier, a
> This isn't about program-viewer communication, this is about script-
> script communication.
What I mean here is: You lose a LOT of things if all you do is to pass
messages back and forth. So why limit it to that? Make the viewer accept
complex commands, or at least make it so that they can be added later without
breaking the protocol.
Make it so that you can request the viewer to control the music, accept
external keypresses, upload files, etc. And one of the available commands
would be setting up this message stuff.
In fact, that was one of the things in my TODO list: Make a socket protocol
that would allow me to tell the viewer to accept scripts, compile them, and
automatically send to the right place in my inventory.
> A couple of obvious applications:
> Controls sending chat messages to vehicles. This wouldn't even need
> return messages, and could be used with existing vehicles.
This is far less than ideal.
First, if the code is outside the client and all you have is message relay it
means you must shift focus to app doing the control stuff. I suppose you
could capture the input while SL is active, but then it'd conflict.
Also, without changing the viewer you don't have the ability to make the
vehicle move on screen before the command gets to the server. That results in
I think a better approach would be to have an app tell the viewer "Act as if
this key was pressed". Then you get the benefits of client-side prediction.
> Local scripts communicating with HUDs, to provide in-world UI for
> local applications.
This is also very not ideal. For example, my avatar list would lose the
ability to get the avatar list from the viewer itself, and would have to run
a sensor in the LSL script, which is must limited in its capability.
It would also lose the ability to open IM and profile windows, making the
avatar speak and setting beacons.
Now, if you want to use my hack to talk to in-world objects that way, sure, go
ahead. But like I said, I'd use a more complex protocol for the
communication. The hack was done to be as simple as possible for the LSL
side, but it's not all that great if you have more powerful things available.
Here's how I'd do it:
Client to viewer on socket:
<send_message channel="324" type="whisper">Hi there!</send_message>
LSL script replies:
Viewer outputs this on the socket:
<message type="object" key="123123" owner_key="1431231" subsystem="Foo">
And so on. Doesn't have to be specifically XML of course, but I do think it
shouldn't be as simple as plain text with no metadata at all as that limits
the possible functionality.
> Click here to unsubscribe or manage your list subscription:
-------------- 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/a6f9f11d/attachment-0001.pgp
More information about the SLDev