[Opensim-dev] Module/Plugin Loading
Dahlia Trimble
dahliatrimble at gmail.com
Wed Jun 25 22:13:38 UTC 2008
There is a server side simulation for weather, it can be accessed with
functions such as llWind() or llCloud(). I believe the "classic clouds" made
use if these data, but I dont know if the newer clouds in the windlight
viewer use it. Another use is for flexible prims that respond to wind. A
server based simulation would be a means where they could respond in sync
between viewers, but I'm not aware if they currently do or if the wind they
respond to is specified in the viewer alone. One way to have them respond in
sync would be to have a script in the flexi prims that provided some motion
based on llWind(). The viewer does appear to be relying on some server based
parameters for classic clouds. There is also a wind noise generator in the
viewer but I dont know if it uses server side wind as a control parameter
either.
Some current uses of the wind simulation are education and sailboat racing.
A crude means of visualizing the Linden server based wind can be implemented
by placing the following LSL script in a prim, stretched on it's Z axis:
default
{
state_entry()
{
llSetTimerEvent( 1.0 );
}
timer()
{
vector wind = llWind( llGetPos() );
llSetRot(llRotBetween( <0.0, 0.0, 1.0>, llVecNorm( wind ) ) );
}
}
Spreading around several prims containing the above script provides some
interesting insight into the simulation.
On Wed, Jun 25, 2008 at 2:18 PM, Cristina Videira Lopes <lopes at ics.uci.edu>
wrote:
> Having written the DataSnapshot module as an outsider, I must say I was
> really pleased with the current module system. It's really simple to
> understand, and works as advertised. There were protected parts that I
> couldn't access (in theory), but I hacked around it. In any case, no other
> module system would have allowed access to protected parts -- that issue is
> always a potential problem for plugin modules.
>
> I don't know enough about the mono plugins to compare. And I'm not sure
> what the problem is here, I lost track.
>
> WRT that specific simulation (wind), I think a lot of that info is
> currently on the client, not on the server. But one can implement a wind
> model module, no doubt about that; you may need to get creative about
> visualizing it with the SL client, though, I'm not sure there's any talk
> between the simulator and the client about wind.
>
> Dahlia Trimble wrote:
>
> I've been thinking about what it would take to implement a crude wind
> model in opensim, and this thread appears to be along the lines of some of
> my thoughts. I've done some CFD visualization work several years ago, but I
> am by no means an expert and as such I think I would rather concentrate on
> developing the hooks and providing a basic model that can be unplugged and
> replaced with other models that would be better suited for more demanding
> applications. Such a model may need access to simulation variables like time
> of day, sun position, the object meshes used by the physics engine and their
> layout in 3D space, weather conditions of neighboring regions, and probably
> others. It may need to send weather data to agents in the simulation area,
> and expose data to the scripting engine to support functions such as
> llWind(). It would also need to be informed of changes in the region such as
> adding prims or terrain modifications.
>
> As a relatively new contributor, I'm not really familiar with the benefits
> or drawbacks of the various means of plugging in code with these
> requirements, and it appears that many of these issues are being brought up
> here which is what prompted me it add it to this thread rather than start
> another. Comments?
>
>
>
>
> On Wed, Jun 25, 2008 at 12:08 PM, Michael Wright <michaelwri22 at yahoo.co.uk>
> wrote:
>
>> Yes those are great if we can acheive them. I'm just not sure how we
>> create a "clean" wrapper that is independant of Mono.addins, as it uses
>> various attributes to define the interfaces and plugins (TypeExtensionPoint,
>> Extension, etc) . So those classes need references to mono.addins.
>>
>> Like for example our current IApplicationPlugin:
>>
>> using Mono.Addins;
>>
>> [assembly : AddinRoot("OpenSim", "0.5")]
>>
>> namespace OpenSim
>> {
>> [TypeExtensionPoint("/OpenSim/Startup")]
>> public interface IApplicationPlugin
>> {
>> void Initialise(OpenSimBase openSim);
>> void Close();
>> }
>> }
>>
>> and to implement a Application plugin:
>>
>> assembly : Addin]
>> [assembly : AddinDependency("OpenSim", "0.5")]
>> [assembly : AddinDependency("RegionProxy", "0.1")]
>>
>> namespace OpenSim.ApplicationPlugins.LoadBalancer
>> {
>> [Extension("/OpenSim/Startup")]
>> public class LoadBalancerPlugin : IApplicationPlugin
>> {
>>
>>
>> So if we had more classes that used were loaded by mono.addins, we would
>> need the interfaces to have a TypeExtensionPoint attribute and the
>> implementations to have the Extension. Tthe only other way I saw for
>> Mono.addings to load plugins without those attributes, is by using its xml
>> manifest files. And one of our requirements is listed as that we don't use
>> third party config files.
>>
>> I most likely haven't dug deep enough into mono.addins and there could
>> well be a method to do cut out the attributes and not require manifest
>> files. But anyway my point is that I believe a implied effect of those
>> requirements is that we don't have references to Mono.addins in the core
>> opensim assemblys. (OpenSim.Framework.X , etc)
>>
>> *Dr Scofield <DrScofield at xyzzyxyzzy.net>* wrote:
>>
>> Stefan Andersson wrote:
>> > Just to get this straight, is what we're saying
>> >
>> > 1) Yes, we will have a common loader architecture
>> > 2) Yes, it will be implemented as a set of interfaces
>> > 3) Yes, we will create one implementation as a wrapper around
>> Mono.Addins
>> > 4) Yes, we will aim at having a common setup file structure for
>> > OpenSim, not depend on lots of different third-party components config.
>> >
>> > That sounds excellent to me.
>> +1
>> >
>> > Best regards,
>> > Stefan Andersson
>> > Tribal Media AB
>> >
>> > Join the 3d web revolution : http://tribalnet.se/
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------
>> >
>> > > Date: Wed, 25 Jun 2008 10:16:34 -0400
>> > > From: sean at dague.net
>> > > To: opensim-dev at lists.berlios.de
>> > > Subject: Re: [Opensim-dev] Module/Plugin Loading
>> > >
>> > > On Wed, Jun 25, 2008 at 03:12:45PM +0100, Melanie wrote:
>> > > > I believe that we should use a plugin loader that allows us to
>> > > > configure plugin loading completely within our own .ini files. I
>> > > > think that a requirement to tweak complex XML based mono/.NET config
>> > > > files to get a plugin loaded will put running OpenSim out fo reach
>> > > > of many users.
>> > > >
>> > > > That said, I'm all for a standardized way to load a plugin. I just
>> > > > think it shouldn't be required to edit conifg files outside of
>> > > > OpenSim's own.
>> > >
>> > > +1. I think that ryan's plugin loader approach will give us that (at
>> > > least from what I've seen in his patch and description). I'm looking
>> > > forward to that work.
>> > >
>> > > -Sean
>> > >
>> > > --
>> > > __________________________________________________________________
>> > >
>> > > Sean Dague Mid-Hudson Valley
>> > > sean at dague dot net Linux Users Group
>> > > http://dague.net http://mhvlug.org
>> > >
>> > > There is no silver bullet. Plus, werewolves make better neighbors
>> > > than zombies, and they tend to keep the vampire population down.
>> > > __________________________________________________________________
>> >
>> > ------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > Opensim-dev mailing list
>> > Opensim-dev at lists.berlios.de
>> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >
>>
>>
>> --
>> dr dirk husemann ---- virtual worlds research ---- ibm zurich research lab
>> SL: dr scofield ---- drscofield at xyzzyxyzzy.net ----
>> http://xyzzyxyzzy.net/
>> RL: hud at zurich.ibm.com - +41 44 724 8573 -
>> http://www.zurich.ibm.com/~hud/
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>> ------------------------------
>> Not happy with your email address?
>> Get the one you really want <http://uk.docs.yahoo.com/ymail/new.html> -
>> millions of new email addresses available now at Yahoo!<http://uk.docs.yahoo.com/ymail/new.html>
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
> ------------------------------
>
> _______________________________________________
> Opensim-dev mailing listOpensim-dev at lists.berlios.dehttps://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080625/7df1c44a/attachment-0001.html>
More information about the Opensim-dev
mailing list