Opensim selber kompilieren auf Windows

Anleitung

zum Bau des OpenSim

Simulators unter Windows

Akira Sonoda

Version 1.0 / Feb 2009

Diese Anleitung beschreibt Schritt für Schritt den Bau des OpenSim Simulators unter Microsoft

Windows direkt ab dem Quellcode des OpenSim Subversion Repository.

Der Bau des Simulators direkt mittels der Quellcodes ab dem Subversion Repository ist nicht

schwierig, das versuche ich mit diesem Dokument zu beweisen :-) Trotzdem existieren einige

Schritte im ganzen Ablauf, welche unter Umständen nicht korrekt funktionieren. Ein Beispiel ist mir

während des Erstelens dieses Dokumentes selbst passiert. Und ich habe das Problem auch

entsprechend im Dokument beschrieben.

Deshalb meine Empfehlung:

Wenn das Arbeiten mit Befehlen der Eingabeaufforderung absolutes Neuland ist. Wenn OSGrid

der Grund war, sich einen Windows Server zu mieten dann würde ich folgendes machen:

I. Sucht euch jemanden der euch assistieren kann. Ich helfe gerne, einfach fragen. Jeden

Montag um 20:00 Uhr findet auf der Region “Schwarze Sonne” bei der “Banana Bar” ein

Treffen der deutschsprachigen OSGrid Bewohner statt. dies ist eine gute Gelegenheit um

Fragen zu stellen.

II. Folgt den Ratschlägen eures Trainers, wenn er lieber mit vorgefertigten Simulatoren arbeitet

dann folgt seinem Rat.

Suchanfragen: Nicht alles glauben was dort steht. Zuerst das Datum der Meldung anschauen.

November 2008 ist wahrscheinlich inzwischen veraltet. Wenn von Version 0.5.7 des OpenSim

die Rede ist, dann ist diese Version ebenfalls alles andere als aktuell. Quer recherchieren,

nachfragen, gesunden Menschenverstand walten lassen.

IV. Ralf Haifisch und andere nette und engagierte OSGrid Bewohner stellen bereits vorgefertigte

Warum also selber kompilieren?

OSGrid ist der “Spielplatz” der OpenSim Entwickler hier testen sie die neusten Versionen des

Simulators aus. OpenSim hat im Entwickler Sprachgebrauch “Alpha” Zustand. Das bedeutet, dass

der OpenSim zwar läuft aber immer noch häufigen Änderungen unterworfen ist. Eine stabile

Version welche über Monate eingesetzt werden kann, existiert nicht. Entwickler kompilieren ihren

Code mehrmals täglich und haben deshalb entsprechende Prozeduren gebaut um diese Aufgabe

möglichst einfach und sicher zu erledigen. Daraus ergeben sich folgende Vorteile:

I. Es ist möglich, den allerneusten “bleeding-edge” Stand des Simulators zu bauen. Das kann

aber auch ein Nachteil sein.

II. Es ist möglich eine ganz bestimmte Version des Simulators zu bauen, zu dem es eventuell

keine vorgefertigten Versionen gibt.

III. Eine erfolgreiche Kompilation gibt die Sicherheit, dass die notwendigen Bestandteile alle im

richtigen Zustand zur Verfügung stehen und auch auf dem eigenen Server

höchstwahrscheinlich lauffähig sind.

IV. Eine Kompilation ist einfach und der Arbeitsablauf dauert mit etwas Übung eine viertel Stunde

bis eine halbe Stunde.

Niemals vergessen. Der OpenSim Simulator ist in der aktuellen Version 0.6.x alles andere als fertig

ausprogrammiert. Eine Anzahl von Funktionen welche im SecondLife problemlos funktionieren sind

hier noch nicht implementiert und funktionieren einfach noch nicht, egal ob direkt ab Quellcode

kompiliert oder in vorgefertigten Simulatoren. Eine Übersicht, was geht und was nicht findet ihr

LSL_Status/Functions

In diesem Dokument gelten folgende Formatierungsregeln:

Text welcher in der Schriftart Courier geschrieben ist, sind Befehle, welche im Fenster

die Eingabe die Eingabetaste oder Return-Taste gedrückt werden muss. Ein Beispiel:

Hyperlinks zu Web Seiten werden wie folgt formatiert:

http://opensimulator.org/wiki/Build_Instructions

Die Anleitung geht davon aus, dass wir direkt auf einem gemieteten Windows Server arbeiten.

Diese Schritte gelten aber auch für eine Installation oder ein Update des OpenSim Simulators auf

einer lokalen Windows Maschine. Wir arbeiten meist in der Eingabeaufforderung

oder dem Windows Explorer

Ich gehe davon aus, dass die für OpenSim erforderliche .NET Version 2.0 oder Mono

Laufzeitumgebung installiert ist. Um dies herauszufinden kann in der Adresszeile des Windows

Explorer folgendes eingeben werden:

Das Bild welches sich dann im Windows Explorer zeigt sollte etwa so aussehen

Auf der rechten Seite des Explorers ist eine Anzahl Ordner mit Nummern sichtbar. Die Nummer mit

der höchsten Zahl ist die aktuell gültige Version des .NET Frameworks. In diesem Falle die Version

Servern installiert. Die Installation dieses Frameworks ist jedoch nicht Gegenstand dieses

Dokumentes.

Um die Quellcodes ab dem Subversion Repository zu holen benötigen wir ein kleines Programm

Es ist vollkommen ausreichend

den Subversion Command-

Line Client herunterzuladen.

Wir wollen nur die Quellcodes

holen und nicht einen

Subversion Server einrichten.

Die Grösse der Datei ist etwa

2.5 MB. Um den Download

durchführen zu können muss

man sich registrieren. Die

Registrierung kostet nichts und

CollabNet ist auch nicht dafür

bekannt, dass sie Unfug mit email Adressen anstellen.

Der CollabNet Subversion Command-Line Client v1.5.5 (for Windows) lässt sich nach

dem Download wie eine normales Windows Programm durch Anklicken eines

Installationsprogramms ins System integrieren.

Um festzustellen ob die Installation geklappt hat bitte 

eine Eingabeaufforderung öffnen und folgendes

eingeben:

Es erscheint ein kleiner Hilfetext sowie eine Liste der

möglichen Befehle. Also ist alles in bester Ordnung

und wir sind bereit für das grosse Abenteuer!

Anmerkung: Als Alternative zu dem “Subversion Command Line Client” kann auch “TortoiseSVN”

benötigen. Wer mehr mit Subversion macht, wird jedoch “TortoiseSVN” schnell schätzen lernen

und kann das Werkzeug auch entsprechend bedienen.

Dieser Schritt muss nur durchgeführt werden, wenn ein Upgrade einer bestehenden OpenSim

Installation durchgeführt werden soll.

Falls der OpenSim noch läuft ist jetzt der

Zeitpunkt gekommen ihn zu stoppen.

Dies erfolgt mit dem Befehl:

im laufenden Simulator.

Eventuelle Scripts, welche schauen ob

der OpenSim läuft und ihn automatisch

starten falls er nicht läuft ( im Fachjargon

werden diese Scripts auch Watchdog

genannt ) müssen nun ausgeschaltet

werden.

Die Sicherung ist denkbar einfach wir benennen nur den Ordner opensim um. Beispielsweise nach

opensim_sicherung. Das können wir im Windows-Explorer machen. Bei meinem Beispiel befindet

sich die aktuelle OpenSim Installation in einem Verzeichnis opensim direkt im C:\ Laufwerk. Nach

dem Umbenennen sollte das C: Laufwerk etwa so aussehen:

Nun sind wir bereit um mit dem Subversion Client die entsprechenden Quellcodes runterzuladen.

Das was ich vorhin “runterladen” genannt habe, wird im Fachjargon “checkout” genannt.

Subversion erlaubt es, die unterschiedlichsten Programmversionen, auch genannt “Revision”

mittels checkout zu holen. Ohne spezielle Eingaben holen wir einfach die allerletzte Version aus

dem Repository. Da aber OpenSim ständig weiterentwickelt wird, kann es durchaus sein, dass die

allerneuste Version nicht stabil läuft, weil neue Fehler eingebaut wurden oder Sachen einfach noch

nicht so funktionieren wie sich der Entwickler das vorstellt.

Deshalb ist es auch möglich eine ganz bestimmte Revision herauszuholen von der bekannt ist,

dass sie stabil läuft.

Wenn eine bestimmte Revision von den Entwicklern als stabil erachtet wird, so nennen sie diese

Revision “Release” und geben dem einen ganz bestimmten Namen im Fachjargon “Tag”. Das

letzte Tag war beispielsweise “0.6.2-release” welches auf der Revision 8068 basiert. Um einen

bestimmten Release auszuchecken muss in der Eingabeaufforderung folgender Befehl

eingegeben werden ( in diesem Falle bitte nicht machen wir werden eine andere Version

auschecken ):

Es kann auch sein, dass in den Quicknews beim Start des Viewers ein Vorschlag gemacht wird

oder sogar der Befehl gegeben wird auf eine bestimmte Version zu upgraden.

Beim Bild oben wird in den Quicknews vorgeschlagen ein Upgrade auf die Revision 8274+ (das

Plus heisst grösser oder gleich) zu machen. Wir werden auch dies nicht machen, aber der

Vollständigkeit halber zeige ich den entsprechenden Befehl auf der nächsten Seite.

Selbstverständlich kann man mich (Akira Sonoda) auch fragen, welche Version ich empfehlen

würde oder Ralf Haifisch oder sonst einen Spezialisten. Eine gute Quelle für Informationen ist auch

Subversion Repository von Opensimulator.org. Die Informationen dort sind von Entwicklern für

Entwickler geschrieben, haufenweise Fach-Chinesisch, wer es versteht, dem hilft es weiter,

ansonsten sein lassen.

Langer Rede kurzer Sinn um eine bestimmte Revision, beispielsweise 8274 auszuchecken bitte in

der Eingabeaufforderung folgenden Befehl eingeben:

Dies checkt die Revision 8274 aus.

Spezialisten wie Ralf Haifisch welche Dutzende von Regionen auf mehreren Servern mit mehreren

OpenSim Simulatoren betreiben, holen sich meist die allerletzte Version aus dem Subversion

Repository bauen sich den OpenSim Simulator und lassen den mit einer ganz speziellen Region

laufen welche nur dafür aufgesetzt ist um zu schauen, ob alles sauber läuft und wenn sie sehen,

dass alles in Ordnung ist, werden dann die produktiven Simulatoren auf den entsprechenden

Stand gebracht. Dieses Vorgehen ist absolut zu empfehlen für jemanden der viele Simulatoren und

Regionen betreibt wo eventuell sogar noch Shops drauf stehen und viele Leute sich treffen.

Zum Betreiben einer oder mehrerer netter kleiner Regionen auf einem Simulator ist dies definitiv

zu viel des Aufwandes! Wir haben ja eine Sicherung wo wir im schlimmsten Fall wieder darauf

zurückgreifen können. Also holen wir uns die absolut neuste Revision aus dem Subversion. Das

machen wir jetzt wirklich :-)

Ich habe ja erwähnt dass ich in dem Beispiel den OpenSim im C:-Laufwerk installieren will. Falls

die Eingabeaufforderung auf irgend ein Unterverzeichnis zeigt wie in folgendem Bild,

müssen wir zuerst in das oberste

Verzeichnis des C:-Laufwerkes

wechseln. Das machen wir mit der

folgenden Eingabe:

Jetzt sind wir am richtigen Ort und

können nun in der

Eingabeaufforderung folgenden

Befehl eingeben:

Nun beginnt der Subversion Client zu arbeiten und holt sich alle Quellcodes des aktuellsten

Release aus dem Subversion Repository. Nach einiger Zeit sollte das Bild in der

Eingabeaufforderung etwa so aussehen wie auf der nächsten Seite dargestellt.

Immer schön den existierenden opensim Ordner umbenennen und danach den checkout

durchführen. Ein neuer opensim Ordner wird dabei erstellt. Alles andere wird zu Problemen führen!

Wir sehen die einzelnen Quellcodes aufgelistet

und die eigentlich wichtigste Information sehen

wir ganz am Ende:

Checked out revision 8392

Perfekt, wir haben nun die allerneusten

Quellcodes auf unserer Maschine und diese

werden wir jetzt so umwandeln, dass auch der

Computer damit etwas anfangen kann. Im

Fachjargon wird dies “kompilieren” genannt.

Da jedoch OpenSim auf den unterschiedlichsten

Systemen läuft wie Windows, Linux, Mac OSX

und jedes der Systeme gewisse Eigenheiten

hat, müssen wir zuvor gewisse Windows

spezifische Einstellungen vornehmen. Keine

Angst, dies läuft alles automatisch ab!

Beim checkout wurde uns ein neues Verzeichnis mit dem Namen opensim erstellt. Um die

Vorbereitungen durchzuführen müssen wir in dieses Verzeichnis wechseln. Dazu geben wir in der

Eingabeaufforderung folgendes ein:

und die Eingabeaufforderung sieht wie folgt aus:

Das Programm welches wir dort starten

müssen heisst runprebuild.bat. Findige Köpfe

sehen vielleicht, dass auch eine Datei namens

runprebuild2008.bat existiert. Dies ist keine

neuere Version der runprebuild.bat sondern

ein spezielles Programm für Entwickler welche

mit dem VisualStudio 2008 arbeiten. Diese

Datei interessiert uns nicht, eben so wenig wie

die Datei runprebuild.sh welche für Leute mit

den Apfel- oder Pinguin- Computern gedacht

ist.

Wir geben ganz einfach folgendes in der Eingabeaufforderung ein:

und schon beginnt der Computer wieder fleissig zu arbeiten und wir können auf die nächste Seite

blättern...

Nach einiger Zeit sollte unsere Eingabeaufforderung

etwa so aussehen wie links abgebildet.

Jetzt sind wir bereit für die Umwandlung der

Quellcodes in ausführbare Programme!

Dieser Schritt ist ebenfalls sehr einfach. In der Eingabeaufforderung folgenden Befehl eingeben:

und wieder muss der Computer hart arbeiten. Ich finde das angenehm, wenn der Computer

arbeitet und ich zuschauen kann oder mir in der Zwischenzeit einen Kaffee mache. Den brauche

ich zwar nicht mehr für den Update, denn wir haben es beinahe geschafft!

... warten ...

Uii Schock Horror!! Die Aussage mit dem Kaffee hätte ich nicht machen dürfen, das war ein

schlechtes Omen!! Meine Eingabeaufforderung sieht wie folgt aus:

Um ehrlich zu sein, dies ist das erste Mal in

meiner OpenSim 'Karriere', dass eine

Kompilation nicht geklappt hat. Kann aber

durchaus passieren. Die gelben Warnungen

sind unkritisch. Jedoch die rote Zeile ist nicht

gut! Und zuoberst der Satz Build FAILED,

das ist ganz schlecht.

Ich hatte schlicht Pech. Im Log des

Subversion hab dann gesehen, dass das

Problem mit der Revision 8393 schon wieder

gelöst war.

Also zurück zum Kapitel “Checkout aus dem

OpenSimulator.org Subversion Repository”.

Mit dem Befehl:

zurück auf das oberste Verzeichnis des C:-

Laufwerkes und im Windows Explorer das

Verzeichnis opensim löschen und danach die

Prozeduren wieder durchführen.

Aber wie gesagt, dies ist NICHT der Normalfall, üblicherweise klappen die Umwandlungen. Wer

jetzt die Nerven verloren hat, kann ja auch das Verzeichnis opensim_sicherung wieder zu opensim

umbenennen den alten OpenSim starten und es am nächsten Tag nochmals versuchen.

Wie die Eingabeaufforderung aussieht, wenn es geklappt hat ist auf der nächsten Seite

beschrieben.

Nach dem Fehler ( wie gesagt, üblicherweise passiert der nicht ) habe ich den harten Weg auf

mich genommen und die Schritte ab Seite 6 nochmals durchgeführt. Inzwischen waren die

Entwickler fleissig, haben den Fehler korrigiert und wir stehen bei Revision 8395 und ich habe

genüsslich meinen Kaffee getrunken während der Compiler am Umwandeln war. Nun sieht das

Bild etwas anders aus:

Ganz oben steht nun in beruhigenden

grünen Buchstaben geschrieben “Build

succeeded”. Das ist es was wir wollen!

Die Warnungen in gelb. Ok die gibt es, da

haben die Entwickler noch was zu tun, aber

die sind nicht tragisch. OpenSim wird

trotzdem funktionieren.

Jetzt müssen wir noch einige Dateien aus

der Sicherungskopie opensim_sicherung in

unser neues Verzeichnis opensim kopieren.

Dieser Schritt muss natürlich nur dann durchgeführt werden, wenn eine bestehende Installation auf

eine höhere Revision angehoben ( im Fachjargon update ) werden soll. Bei Neuinstallationen gibt

es nichts zu kopieren.

Beim Update muss zusätzlich noch unterschieden werden, ob es sich um eine unabhängige

Installation ( standalone im Fachjargon ) oder um eine Installation im OSGrid handelt. Nehmen wir

den einfacheren Fall es handelt sich um eine Installation eines Simulators im Grid.

Aber wir haben ja bloss einen kleinen Simulator mit ein paar Regionen im Betrieb, und nutzen die

per Voreinstellung eingestellte SQLite Datenbank und nicht MySQL oder ähnliche Brocken (das ist

was für Profis, welche mehrere Simulatoren mit vielen Regions auf richtig grossen Servern

betreiben). Die Dateien, welche wir kopieren müssen sind:

Diese Aktionen können wir ganz bequem im Windows Explorer durchführen.

Klappen wir im Windows Explorer auf der linken Seite einmal den Ordner opensim_sicherung und

danach den bin Ordner auf und klicken auf den Ordner Regions, dann sehen wir unsere Regionen

XML-Dokumente ( diese können übrigens frei benannt werden. Ich habe ihnen den Namen meiner

Regionen 'Ko Suai' und 'Ko Sabai', ohne Leerzeichen, gegeben. Ohne spezielle Anpassungen

heissen die XML-Dokumente 'Default.xml').

Diese beiden Dokumente kopieren wir nun in den entsprechenden Ordner in unserem neuen

opensim Ordner.

Die beiden Dateien 'OpenSim.db' und OpenSim.ini befinden sich im 'bin' Ordner des Ordners

'opensim_sicherung'.

Dieser Ordner ist ziemlich unübersichtlich und je nach

Einstellung sogar ziemlich verwirrend. Deshalb würde ich

hier unter dem Menu 'Ansicht' auf 'Details' klicken und in

dem Menu 'Extras' unter 'Ordneroptionen' kontrollieren,

dass der Eintrag 'Erweiterungen bei bekannten Dateitypen

ausblenden' nicht ausgewählt ist.

Falls dies gemacht ist, sehen wir im Windows Explorer

schön die Dateien 'OpenSim.db' und etwas weiter unten die

Datei 'OpenSim.ini'. Diese beiden Dateien kopieren

( kopieren und nicht verschieben, wir wollen ja eine

Sicherung für den Fall der Fälle ) wir nun in den 'bin' Ordner

des neuen 'opensim' Ordners.

Diejenigen, welche einen standalone Simulator updaten,

müssen noch ein paar weitere Dateien kopieren.

Hier noch eine tabellarische Übersicht, wer welche Dateien kopieren muss:

Nun haben wir alle Arbeiten erledigt und wir könnten den neuen Simulator starten. Ich möchte

trotzdem noch auf das Thema OpenSim.ini zu sprechen kommen. Es empfiehlt sich diese Datei

auch bei einem Update genauer unter die Lupe zu nehmen.

Anmerkung: OpenSim ist im stetigen Umbau begriffen. Es ist deshalb durchaus möglich, dass in

Zukunft weitere Dateien kopiert werden müssen. Ich werde versuchen das Dokument so aktuell

biz/DE-opensim__versionsupdate.shtml

Diese Datei steuert das Verhalten des OpenSim Simulators und je nachdem wie der Simulator

eingesetzt werden soll ob lokal oder im Grid muss sie unterschiedlich angepasst werden.

Bei einer Neuinstallation existiert diese Datei noch gar nicht. Diese muss erst erstellt werden. Dazu

existiert eine Datei namens 'OpenSim.ini.example' im Ordner 'bin' des 'opensim' Ordners. Diese

Datei kann nun nach OpenSim.ini umbenannt werden und ist dann perfekt für den Standalone-

Betrieb eingerichtet.

Für den Betrieb im OSGrid müssen jedoch noch ein paar Anpassungen gemacht werden. Diese

Anpassungen haben wir ja bereits in der OpenSim.ini gemacht welche wir aus der Sicherung

'opensim_sicherung' kopiert haben. Es macht dennoch Sinn diese OpenSim.ini mit der neuen

OpenSim.ini.example, welche wir beim checkout der neusten Version automatisch erhalten haben

zu vergleichen. Wesentliche Änderungen in der OpenSim.ini werden jeweils von den Entwicklern in

die OpenSim.ini.example eingetragen.

Um die beiden Dateien einfach zu vergleichen gibt es Software, welche kostenlos heruntergeladen

werden kann. Ich verwende dazu das Programm ExamDiff welches von hier heruntergeladen

werden kann:

http://www.download.com/ExamDiff/3000-2248_4-10059626.html

Nachdem ich ExamDiff gestartet habe erscheint folgendes Fenster:

Ich wähle also die beiden Dateien aus, welche ich vergleichen will und klicke auf 'OK'. Es erscheint

nun folgendes Fenster:

Sieht doch hübsch aus! Links ist die Datei OpenSim.ini.example und rechts die OpenSim.ini,

welche wir aus der Sicherung übernommen haben und das schöne daran ist, dass die

Unterschiede farblich hervorgehoben sind. Also schauen wir die Unterschiede einmal an.

Um eventuelle Änderungen gleich durchzuführen empfiehlt es sich, die Datei OpenSim.ini

gleichzeitig im Editor zu öffnen. ExamDiff macht es einem diesbezüglich einfach.

Das fünfte Symbol von links auf der Symbolleiste öffnet die Datei auf der rechten Seite im

Editor, um sie unter Umständen gleich zu bearbeiten. Also legen wir los.

Der erste Eintrag:

HttpProxy = "http://proxy.com"

ist für mich irrelevant, da ich keinen Proxy benutze, also ist es in Ordnung, dass er unter

Kommentar ist. Einträge unter Kommentar haben einen Strichpunkt (;) am Anfang der Zeile.

Da ich keinen Proxy habe ist auch der zweite Eintrag

HttpProxyExceptions = ".mydomain.com;localhost"

irrelevant. Deshalb ist es ebenfalls korrekt, dass er unter Kommentar ist.

Der dritte Unterschied.

gridmode = false

Wir sind ja mit unserem Server im OSGrid also ist es korrekt, dass in unserem OpenSim.ini

gridmode = true eingestellt ist.

Wir blättern weiter im ExamDiff.

Keine Ahnung warum ein Unterschied bei asset_database angezeigt wird. Wahrscheinlich ein

Tabulator anstelle von Leerzeichen. Der Eintrag „default“ ist neu und eine gute Sache. Die Asset

Datenbank, also die Datenbank in welcher die Graphiken, Shapes, Objects usw. Abgespeichert

sind ist im OSGrid zentral vorhanden. Bei einer Standalone Installation ist auch die Asset

Datenbank auf dem lokalen Rechner. Dies musste früher eingestellt werden und war eine häufige

Ursache von Problemen der Regions im Grid. Mit „default“ stellt der Simulator selbst fest, welche

Datenbank er verwenden soll. Gute Sache, lassen wir so.

Mesher. ZeroMesher ist gut und schnell. Meshmerizer ist besser dafür weniger schnell und

funktioniert nur mit der OpenDynamicsEngine. Ich habe Meshmerizer eingestellt und die

OpenDynamicsEngine eingeschaltet, deshalb die Differenzen hier.

Die Berechtigungen in den Voreinstellungen sind zu schwach für mich. Im Standalone Modus ok.

Wir sind jedoch im grid-Modus!

Wir haben ja nur einen kleinen Simulator auf unserem Server, also gehen die vorgegebenen http_listener_port=9000

DotNetEngine. Will ich nicht! Deshalb habe ich sie ausgeschaltet. Die ScriptEngine die ich verwende ist die

Xengine. Sicher, es ist möglich mit DotNet viele lustige Sachen zu machen, welche mit der Xengine unter

Umständen nicht realisierbar sind. Aber gross hier zu erklären warum ich DotNet Scripting nicht mag würde

zu weit führen, diejenigen die das wollen sollen es einschalten ich will es nicht!

Die Einträge unter DataSnapshot sind dann wichtig wenn im Viewer in der Suche auch etwas gefunden

werden soll. Dazu müssen jedoch noch zusätzliche zwei Komponenten installiert werden, welche nicht im

Die beiden Komponenten 'OpenSimSearch.Modules.dll' und 'OpenSimSearch.Modules.dll.mdb' welche im

Zip Archiv enthalten sind ins 'bin' Verzeichnis kopieren und die OpenSim.ini so anpassen wie auf der rechten

wo Inhalte aus dem SecondLife und auch aus dem OSGrid gefunden werden können. Ich habe diese

Unter [Economy] habe ich bloss die Anzahl Prims auf 15'000 limitiert. Das sollte fürs erste genügen.

; ## Customized Cache Implementation

;

; The AssetCache value allows the name of an alternative caching

; implementation to be specified. This can normally be omitted.

; This value corresponds to the provider value associated with the

; intended cache implementation plugin.

; See also: asset_database

; AssetCache = "OpenSim.Framework.Communications.Cache.AssetCache"

; ## EMAIL MODULE

;emailmodule = DefaultEmailModule

[SMTP]

enabled=false

;enabled=true

;internal_object_host=lsl.opensim.local

;host_domain_header_from=127.0.0.1

;SMTP_SERVER_HOSTNAME=127.0.0.1

;SMTP_SERVER_PORT=25

;SMTP_SERVER_LOGIN=foo

;SMTP_SERVER_PASSWORD=bar

Die entsprechend neu aufgenommenen Module sind entweder unter Kommentar (;) oder ein Schalter

enabled=false ist gesetzt. Die Kommentare entfernen oder enabled=true setzen würde ich nur, wenn

bekannt ist, was die entsprechenden Optionen bewirken.

Aufgrund der schnellen Änderungsfrequenz des OpenSim Simulator, bitte diese Beschreibung der

OpenSim.ini nicht als abschliessend betrachten. Weitere Umbauten der OpenSim.ini sind bereits

“angedroht”.

Damit haben wir die Untersuchung der OpenSim.ini abgeschlossen. Wir können nun unsern OpenSim

Simulator starten.

Dazu wechsle ich ins 'bin' Verzeichnis des aktuellen opensim mit folgendem Befehl:

und starte dort den OpenSim mit folgendem Befehl:

oder falls ich einen dicken 64Bit Windows Server gemietet habe:

ist, wird nun folgendes abgefragt:

Zuerst der Name der neu zu erstellenden Region. 'OpenSim Test' wird sie heissen wenn nichts

nichts eingegeben wird.

Danach die X-Koordinate. Hier die entsprechende Zahl eines freien Platzes im OSGrid eingeben.

Oder die Vorgabe von 1000 belassen, wenn der Simulator Standalone betrieben wird.

Danach die Y-Koordinate. Hier die entsprechende Zahl eines freien Platzes im OSGrid eingeben.

Oder die Vorgabe von 1000 belassen, wenn der Simulator Standalone betrieben wird.

Danach die interne IP-Adresse des Servers angeben diese kann durch Eingabe von ipconfig in

einem andern Eingabeaufforderungs-Fenster in Erfahrung gebracht werden:

Die Vorgabe von 0.0.0.0 kann beibehalten werden, wenn der Simulator standalone betrieben

werden soll.

Die nächste Frage nach dem Port für einkommende UDP Verbindungen kann auf dem

Vorgabewert von 9000 belassen werden, wenn es die allererste Region ist, welche aufgesetzt wird.

Die nächsten Regions kriegen dann die Ports 9001, 9002 usw. Gilt für Standalone und Grid

Installationen.

Danach muss der externe Host-Name angegeben werden. Vorgabe ist 127.0.0.1 welches dem

lokalen Rechner ( localhost ) entspricht und für Standalone Installationen absolut stimmt. Im Grid

einfach die IP Adresse eingeben, die vom Vermieter vergeben wurde. Stimmt möglicherweise

sogar mit derjenigen überein, welche mittels ipconfig ausgelesen werden kann.

ein.

Im Standalone-Modus will er noch ein Master Passwort, welches nun ebenfalls eingeben werden

kann. Die Vorgabe ist 'test'.

Danach läuft noch einiges ab und wenn alles gut geht erscheint folgende Meldung:

Und unser Simulator läuft !!! Dass das Starten 18 Minuten 49 Sekunden dauert ist nicht üblich :-)

Der Grund liegt darin, dass ich während des Startens (ich habe im Standalone Modus aufgestartet)

noch all die oben beschriebenen Fragen beantworten musste und gleichzeitig Seite 18 und 19

dieses Dokumentes geschrieben habe.

Jetzt ist die Zeit gekommen wo wir den Viewer ( LindenLab oder Hippo oder was immer )

aufstarten und eine Region unseres schönen neu gebauten Simulators besuchen gehen können

um zu schauen ob alles in Ordnung ist!

Viel Spass

Akira Sonoda

Diese Checkliste kann zu Beginn hilfreich sein, damit die richtige Reihenfolge der Arbeitsschritte

eingehalten wird.

opensim_sicherung

OpenSim.ini.example vergleichen

seltener auch „RE“; auch Ausführungsumgebung oder seltener Ablaufumgebung

genannt) ist eine Softwareschicht, die sich zwischen der Anwendungs- und der

Betriebssystem-Schicht befindet. Sie stellt von Programmen benötigte Basis-

Funktionen zur Verfügung.

versteht man in der Informatik den für Menschen lesbaren, in einer

Programmiersprache geschriebenen Text eines Computerprogramms. Abstrakt

betrachtet kann man den Quelltext eines Computerprogramms auch als

Software-Dokument bezeichnen, welches das Programm formal so exakt und

vollständig beschreibt, dass dieses aus ihm vollständig automatisch vom

Computer generiert werden kann.

Bevor das Programm, das der Programmierer schreibt, von einem Computer

ausgeführt werden kann, muss es in Maschinensprache, also in eine vom

Computer verständliche Folge von Bits, umgesetzt werden. Dies kann entweder

offline durch einen Compiler oder – zur Laufzeit – durch einen Interpreter oder

JIT-Compiler geschehen. In vielen Fällen wird mittlerweile eine Kombination aus

beiden Varianten gewählt, bei der zuerst – meist vom Programmierer – der

Quelltext der eigentlichen Programmiersprache in einen abstrakten

Zwischencode übersetzt wird, welcher dann zur Laufzeit von einer

Laufzeitumgebung durch einen Interpreter oder JIT-Compiler in den eigentlichen

Maschinencode überführt wird. Dieses Prinzip hat den Vorteil, dass ein und

derselbe Zwischencode auf sehr vielen verschiedenen Plattformen ausführbar ist

und somit nicht für jedes auf dem Markt übliche System eine eigene Version der

Software erscheinen muss. Typische Beispiele für einen solchen Zwischencode

sind der Java-Bytecode sowie die Common Intermediate Language. Mittels eines

Debuggers kann die Funktionsweise des Programms zur Laufzeit verfolgt

werden.

umfasst eine Laufzeitumgebung, eine für Programmierer bestimmte Sammlung

von Klassenbibliotheken (API), und angeschlossene Dienstprogramme

(Services). Die Plattform ist bisher in ihrem vollen Umfang nur für Windows

verfügbar. Anwendungen für .NET laufen dank Projekten wie dem Mono-Projekt

auch teilweise auf unixoiden Betriebssystemen.

Dateien und Verzeichnissen.

Die Versionierung erfolgt in einem zentralen Projektarchiv (engl. repository) in

Form einer einfachen Revisionszählung. Wenn Änderungen an Inhalten verteilt

auf den Computern der Bearbeiter ausgeführt werden, werden zwischen dem

Projektarchiv und einem Arbeitsplatz jeweils nur die Unterschiede zu bereits

vorhandenen Ständen übertragen; anfangs das gesamte Projekt, später nur

Änderungen.