[sldev] Re: Plugin architecture

Dale Glass dale at daleglass.net
Thu Feb 22 12:55:59 PST 2007

В сообщении от 22 февраля 2007 20:55 Mike Monkowski написал(a):
> Dale Glass wrote:
> > LSL scripts will never be able to do some things. Like for example
> > changing how rendering works. Or integrating things like text to speech
> > and voip.
> The reason I asked about plugins is because I'm trying to figure out how
> to implement lip-sync.  After looking at the code and reading the
> replies in this forum, I can't see how a plugin could ever work for
> lip-sync.  I can't see rendering being done in a plugin either.  TTS
Why not? Both things are perfectly doable. Not sure of what exactly you mean 
by "lip sync" (I'm guessing making the in-world avatar move the lips in sync 
with the RL person, by analyzing speech, webcam video or whatever), but 
there's nothing that'd prevent it being in a plugin.

Rendering is more complex because it'd require quite a lot of reorganization, 
but it's doable as well. In fact it's nothing very strange, as there are 
games that let you choose between an OpenGL and a Direct3D renderer. 3D 
programs like 3D Studio Max allow that as well.

> probably could because TTS can get text from the message stream and add
> to the audio stream.
TTS is trivial (to integrate, not the TTS technology itself), even without 
modifications to the client at all. All you have to do is to make a program 
that watches the chat logs, and pipes the new lines to an external TTS 

> It seems to me that plugins must have limited capabilities based on
> limited access to data.
That "must" is rather doubtful. Yes, that's the ideal situation, but it's very 
complex. For now you should assume that a plugin can do whatever it pleases, 
including reformatting your disk, and indeed, an implementation based on 
loadable libraries like people are discussing will result in exactly that.

Doing safe plugins is a very difficult problem if you want them to be able to 
do anything interesting. For example, said TTS plugin could take the text it 
processes, and secretly IM copies to an account, effectively eavesdropping on 
all you say. There are many potential issues like that that will be very hard 
to solve.

> LSL operates on objects, so it would make sense that if you want to
what objects? There are no objects in LSL

> operate on objects in a way that's currently not possible, extend LSL.
I don't see what LSL has to do with this. LSL runs on the server side and is 
completely unsuitable to implement plugins. 

> If you want to operate on the message stream, then use a message stream
> plugin.  I could imagine audio plugins and access to floaters that you
> could fill with whatever content you like, but I can't imagine access to
> all of the internal data from a plugin.
Well, you'll have to get used to that idea then, as the current talk of how 
plugins would work implies that there won't be any effective restrictions on 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070222/a3fb087c/attachment.pgp

More information about the SLDev mailing list