IRegionModule/de

= Bitte beachten Sie = Diese Seite behandelt den Mechanismus des Bereichsmoduls, der seit OpenSimulator 0.6.9 vorhanden ist. Eine ältere Version die auf die älteren IRegionModule-Mechanismen verweist, finden Sie unter http://opensimulator.org/index.php?title=IRegionModule&oldid=13166

Siehe Related Software für Links zu vorhandenen Regionsmodulen.

= Einführung =

Region-Module sind Klassen, die die Schnittstellen INonSharedRegionModule oder ISharedRegionModule von OpenSimulator implementieren. .NET-DLLs, die diese Klassen enthalten, können dann in das Binärverzeichnis von OpenSimulator (bin /) gestellt werden. Beim Start durchsucht OpenSimulator dieses Verzeichnis und lädt dort alle darin enthaltenen Module.

Regionsmodule werden im Herzen des Simulators ausgeführt und haben Zugang zu allen Einrichtungen. Dies macht sie sehr leistungsfähig, bedeutet aber auch, dass bei der Erstellung besonders darauf geachtet werden muss, dass sie sich nicht negativ auf die Simulatorleistung auswirken.

Typischerweise registrieren Regionenmodule Methoden mit dem Ereignismanager des Simulators, die aufgerufen werden, wenn verschiedene Ereignisse auftreten (z. B. Avatar-Chat, Benutzer, der eine Region betritt usw.).

Es gibt zwei Arten von Regions-Modulen.


 * Nicht freigegebene Module, für die ein separates Modul für jede Region/Szene erstellt wird
 * Freigegebene Module, bei denen ein einzelnes Modul zwischen allen Regionen/Szenen geteilt wird, die auf demselben Simulator ausgeführt werden.

= Erstellung eines Region Modules =

Von Grund auf neu
Zu diesem Zeitpunkt werden Regionsmodule normalerweise in der OpenSimulator-Quellstruktur selbst mithilfe ihrer Build-Mechanismen erstellt.

Die Schritte sind wie folgt:

1. Navigieren Sie zu dem Verzeichnis addon-modules / in der Basis der OpenSimulator-Quellstruktur (nicht zu dem Verzeichnis bin / addon-modules / in der Bin-Baumstruktur, über das wir in Kürze sprechen werden).

2. Erstellen Sie ein Verzeichnis für das Regionsmodulprojekt, normalerweise mit demselben Namen wie das Regionsmodul. Zum Beispiel BareBonesNonSharedModule /

3. Erstellen Sie eine prebuild.xml für das Projekt. Dies ist die Datei, die von ./runprebuild.sh oder ./runprebuild.bat im Basis-OpenSimulator-Verzeichnis verwendet wird, um die entsprechenden Build-Dateien für Visual Studio, Monodevelop und nant zu erstellen. Für ein sehr einfaches Modul hätten Sie etwas wie

Zu dieser Datei müssen einige Dinge beachtet werden


 * In OpenSimulator 0.8, wenn Sie auf Windows aufbauen, müssen Sie eine FrameworkVersion von 4_0 anstelle von 3_5 im oberen  -Tag verwenden. Vor OpenSimulator 0.8 muss dies jedoch net 3_5 sein, damit der Build fortgesetzt werden kann. Bei Mono kann dies entweder 3_5 oder 4_0 auf OpenSimulator 0.8 sein, muss aber 4_0 sein, wenn Sie C# 4.0-Funktionen verwenden möchten.
 * Das Pfadattribut in  muss auf den Speicherort im Verzeichnis addon-modules verweisen, in dem sich der Quellcode befindet. Dieses Verzeichnis ist relativ zum OpenSimulator-Stammpfad. Im obigen Beispiel befindet sich der Code in addon-modules / BareBonesNonSharedModule / src / BareBonesNonSharedModule.
 * Die  -Tags geben an, wo Ihre kompilierte Modul-DLL kopiert wird, nachdem sie erstellt wurde. Dies ist relativ zum Speicherort Ihres Quellcodes, wie im Pfadattribut von  angegeben. In den meisten Fällen möchten Sie, dass dies zusammen mit dem Rest der DLLs im OpenSimulator-Verzeichnis / bin abgelegt wird. Legen Sie diese Datei nicht in das Verzeichnis bin / addon-modules - dies ist verwirrend nur für Addon-Modul-Konfigurationsdateien (* .ini).
 * Der  -Wert gibt an, wo das Modulprojekt die DLLs finden kann, auf die es verweisen muss (OpenSimulator.Framework.dll, log4net.dll usw.).
 * Jede Bibliothek, auf die Sie in Ihren Modulen verweisen, benötigt ein  -Tag. Das obige Beispiel listet Bibliotheken wie OpenSim.Framework.dll und OpenMetaverse auf.
 * Weitere Beispiele finden Sie in der Hauptdatei prebuild.xml im Stammverzeichnis der OpenSimulator-Quellstruktur. Bitte beachten Sie, dass das obige Beispiel im Vergleich zu vielen anderen Einträgen optimiert ist - die Hauptdatei muss zu einem gewissen Zeitpunkt vereinfacht werden, da es eine große Redundanz gibt (zB muss Pfad nicht in jedem  angegeben werden) bereits durch  angegeben).

4. Navigieren Sie zurück zum OpenSimulator-Stammverzeichnis und führen Sie ./runprebuild.sh (Linux, Mac OSX) oder ./runprebuild.bat (Windows) aus. In der resultierenden Ausgabe, in der Nähe der Spitze, sollten Sie die Linie sehen

searchDirectory: addon-modules/BareBonesNonSharedModule

or similar. Now, if you are using an IDE such as Visual Studio or MonoDevelop, you should now be able to reload the OpenSim.sln solution and see your project within the source tree.

If anything goes wrong, look carefully at the output for runprebuild.sh/.bat. You may see messages such as

[!] Could not resolve Solution path: addon-modules/BareBonesNonSharedModule/src/BareBonesNonSharedModule

which indicate that your prebuild.xml file for that module is not correctly picking up the source folder.

5. Add or edit module files in your project as required.

6. Re-run runprebuild.sh if you have added any new files to your module.

7. Build OpenSim.sln using your usual build method, whether that's within the IDE or on the command line with xbuild (mono) or nant.

8. If compilation succeeds, the build process will copy the binary into the OpenSimulator bin/ directory. When you next restart OpenSimulator, it should be loaded into the simulator and appear in the output for the "show modules" console command.

From existing module code
If you are looking to build a region module that already exists, the steps are a little simpler.

1. Place the module code inside the base OpenSimulator addon-modules directory. For example, if you are looking to compile a module called EventRecorderModule, then this will be situated at addon-modules/EventRecorderModule. Please be aware that the name of the module must match the patch in the prebuild.xml file (in this example, the file is EventRecorderModule/prebuild.xml).

2. As above, re-run prebuild.sh/prebuild.bat. This is to insert the module into the OpenSimulator build solution (OpenSim.sln).

3. You can now compile the module with Visual Studio, MonoDeveloper, xbuild or nant.

4. On the next startup of OpenSimulator, the module should be loaded (the prebuild.xml places the built module within OpenSimulator's bin/).

=Installing Region Modules= If you are just installing an existing region module DLL rather than building it from source then you will need to

1. Copy the DLL and any other associated files into $OPENSIM_BASE/bin

2. In most cases configure the module, either by adding the required section to OpenSim.ini, adding it as bin/addon-modules/MyModule/config/config.ini or by explicitly including the module's configuration file.

=Region Module Interfaces= All region modules must implement INonSharedRegionModule or ISharedRegionModule from OpenSim.Region.Framework.Interfaces. If a region module implements INonSharedRegionModule then an instance of that module is created for each region (aka scene) in the simulator. Each module only knows about its own region. If a region module implements ISharedRegionModule then only a single instance of the module exists and it is informed about all regions/scenes in the simulators.

Both INonSharedRegionModule and ISharedRegionModule extend IRegionModuleBase which implements the bulk of the interface methods. These are as follows.

INonSharedRegionModule itself contains no methods, being defined simply as

ISharedRegionModule has one additional method.

= Example Region Module =

This example assumes that you are using the file already in the OpenSimulator source tree (from 0.7.1 onwards) at OpenSim/Region/OptionalModules/Example/BareBonesNonShared/BareBonesNonSharedModule.cs. There's also a bare bones shared module example there. To build this as a separate project, please see the instructions above.

BareBonesNonShareadModule is very basic. It does nothing more than log calls made to IRegionModule methods in the process of activating the module.

In the source tree, the [Extension... attribute line is commented. You can uncomment this, rebuild OpenSimulator and start it to see the module in action.

Enabling the module
Creating the module code itself isn't quite enough to enable it. To do that, we need to make it visible to OpenSimulator's module mechanism (which is currently Mono.Addins).

This is done by adding an Extension attribute to the class, for example.

The important part here is the "Path" section "/OpenSim/RegionModules" - this is how OpenSimulator retrieves modules from Mono.Addins. The Id can be anything meaningful to the module.

Newer Mono versions also need this kind of section before the namespace declaration:

At the beginning of your module source code file you need to add this line:

And prebuild.xml needs to include such a line for newer Mono versions:

= Integrating with OpenSimulator =

NOTE: This section is very incomplete and parts are out of date. If you need to know something, please ask on the OpenSimulator mailing lists where we can both answer the question and add the necessary documentation here.

However, please note that OpenSimulator is a very young project and the internal interfaces can change at short notice. If this happens, it is up to you to keep your module up to date with later versions of OpenSimulator.

Accessible Objects
In the AddRegion routine you get access to the scene object for the region, from here you can spider down into the scene and get access to many other objects of interest.


 * scene.GetEntities - returns a list of all the Entities in the environment. This will be a combined list of SceneObjectGroups (prim sets) and ScenePresences (avatars).
 * scene.GetAvatars - get only the avatars in the scene (very handy for sending messages to clients)
 * scene.EventManager - this is the object from which you can register callbacks for scene events. Some examples provided below.
 * scene.RegionInfo - properties about the region

Events
Various occurrences in OpenSimulator (e.g. avatar entering a region, chat) have event hooks to which a module can subscribe. The major sets of events are available from Scene.EventManager.

In many cases, you want to do as little work as possible in the thread that fires the event as many coming from time-critical areas in the OpenSimulator code (e.g. within main scene frame processing) or areas where a holdup will cause other disruption (e.g. events which notify that a root agent has arrived).

These events are somewhat rough and ready because they were originally created for internal OpenSimulator use and by default modules started to use them. Thus, there is inconsistency with names, arguments and the events exposed. Please be prepared for all of these to change over time or be superseded by more appropriate events.

Registering for events
Taking the SunModule as an example we can see the following code:

In Initialise: Pretty simple, we just got the EventManager and registered the SunUpdate method as a callback for the OnFrame event. OnFrame is triggered every time there is a render frame in Opensim, which is about 20 times per second. So in this particular case, you want to be very careful about the actions you perform in this event as they will have a direct impact on scene loop performance (where taking a long time will result in symptoms of lag for moving avatars, etc.).

Here's the function itself

SunUpdate takes no parameter (some events may require them). It only fires every 1000th frame by default (m_frame_mod = 1000 in this module), so it doesn't take too many cycles.

In order for the sun position to change for the clients, they need to be told that it changes. This is done by getting a list of all the Avatars from the scene, then sending the Sun Position to each of them in turn. Moreover, you only want to do this for root agents (agents that actually have an attached avatar that can move around, etc.). Updates sent to child agents (which allow viewers to see into neighbouring regions) will simply be ignored.

Available Events
Here is an extremely incomplete list of available events (which hopefully should be filled out as time goes by). For more details, please see the OpenSimulator code itself. Please also note that OpenSimulator is still in development. Event parameters and names may change over time.

In the table below, the delay columns signal whether a delay in processing the event is likely to disrupt the simulator as a whole and/or the entity (e.g. a user) in question. However, please be aware that even if there is no immediate disruption from delaying one event thread, delaying many will eventually cause simulator wide problems as the threadpool is exhausted.

In OpenSim.Region.Framework.Scenes.EventManager
= Where to go from here =


 * Getting Started with Region Modules -- the Hello World of OpenSimulator application development. Rather old by now but still worth a look.
 * http://bluewallvirtual.com/example_region_module - More shared region module example code by Bluewall.
 * Development discussion of the current region module mechanism
 * Read the source for existing opensim core modules. These are in the OpenSim.Region.CoreModules and OpenSim.Region.OptionalModules projects. Looking through this code is an extremely good way to find out what region modules can do and how they can do it.
 * Read the source code for the EventManager class in the OpenSim.Region.Framework.Scenes project. These list the many events that exist. Some modules may also export their own events (e.g. OnInventoryArchiveSaved in the InventoryArchiverModule at OpenSim/Region/CoreModules/Avatar/Inventory/Archiver/).
 * Help write some examples here. OpenSimulator grows with your contributions.