[sldev] Re: Plugin architecture

Tim Shephard tshephard at gmail.com
Fri Feb 23 21:54:12 PST 2007


I think some way to communicate from LSL to the Plugins would be very
useful in many situations as well.

LSL has access to listen, email, dataserver, sensor, llDetected() and
many other critical information gathering events... communicating that
information to the PlugIn could be very useful.

Heuristic: I recommend surveying all the HUDs currently in use as
potential plugins.

On 2/22/07, Kelly Washington <kelly at lindenlab.com> wrote:
> Mike Monkowski wrote:
> > 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
> > probably could because TTS can get text from the message stream and
> > add to the audio stream.
> >
> > It seems to me that plugins must have limited capabilities based on
> > limited access to data.
> >
> > LSL operates on objects, so it would make sense that if you want to
> > operate on objects in a way that's currently not possible, extend LSL.
> > 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.
> >
> > Mike
> > _______________________________________________
> > Click here to unsubscribe or manage your list subscription:
> > /index.html
> This is an excellent point.  There will have to be a line drawn
> somewhere between what can be a plugin and what requires a separate
> client or re-compile.  This line does not need to be fixed in stone at
> the creation of the plugin system.  In fact the best approach may be to
> start conservatively with very little on the plugin side.  This would
> allow the system to get out, get tested, get used and get refined
> quicker than building an all-encompassing plugin system from the start.
> The plugin system of course then needs to be extendable, but even an
> all-encompassing attempt should be extendable to allow for future core
> source changes and new features.
>
> Along this route, what is the minimal needed to create a plugin system
> that can at least make some useful plugins?
> My guess is the following:
>  - create a floater, be able to populate and update data in the
> floater.  By this I just mean set text, set images, add/remove items
> from scroll lists.
>  - add UI to bring up the floater.  As a first pass even just a
> 'plugins' menu with a menu item for each loaded plug in.
>  - access to specific internal data - ie the list of visible avatars,
> region name, current location etc.
>
> Now that won't let you create just any plugin, it won't even let you
> create most plugins (I'm sure everyone noticed there is nothing about
> handling messages at all), but that is my guess as to the minimal needed
> by a plugin.
>
>
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>


More information about the SLDev mailing list