OpenSimulator vom Manni

[Pius Noel]

[...]Die Idee dahinter bzw. den Ansatz finde ich gut, hat nur einen kleinen Nachteil,
dadurch das die MySQL Daten Zentral eingegeben werden, und geladen werden im Robust und in der OpenSim bzw. Gridcommon, müsste man das mühseelig ändern, bei mir z.b läuft jede Sim 1. in einem eigenen OpenSim.exe und B. hat jede Sim eine eigene MySQL Datenbank, die so getrennt vom Robust ist
Klar ist es mehr aufwand dadurch, aber dadurch bleibt der Robust relativ sauber, und die assets werden dezentral für jede opensim für sich gespeichert.

Obwohl ich zur Zeit nur noch ein lokales Grid zum Testen und Basteln verwende, habe ich die Idee gerade mal in meine .ini-Dateien übernommen. Da bei mir Robust und jede Instanz eines Simulators in einem eigenen bin-Verzeichnis läuft verstehe ich den von dir beschriebenen "Nachteil" nicht. Oder habe ich da etwas falsch verstanden?

Die erforderlichen Anpassungen der Robust.ini, OpenSim.ini und GridCommon.ini mache ich genau einmal in einem separaten Verzeichnis das ausserhalb der OpenSim Installationen liegt. In diesem Verzeichnis habe ich auch für jede Instanz ein Unterverzeichnis mit der Const.ini Datei, die ich natürlich entsprechend anpassen muss. In dieser Const.ini habe ich aber nur das drin, was nicht in allen Instanzen ohnehin gleich ist. Dinge wie GridName oder GridNick gibt es bei mir nicht. Die sind fest in den einzelnen Hauptdateien drin.

Erstelle ich einen neuen Simulator dann muss ich jetzt nur noch die Const.ini erstellen und anpassen. Dann kann ich diese zusammen mit den angepassten Haupt-.ini-Dateien in ihre Ziel-Verzeichnisse kopieren. Somit ist Schluss mit der Sucherei der passenden Stellen in den einzelnen .ini-Dateien. Zum Erstellen der Datenbanken habe nutze ich ein Script.

Dasselbe gilt bei Updates, bei denen ich immer gleich das ganze OpenSim-bin-Verzeichnis neu erstelle. Verzeichnis leeren, OpenSim.zip entpacken (oder so), .ini's kopieren und fertig. Mit meinen vorgefertigten Scripts dauert das ein paar Sekunden.

Einen Nachteil gibt es noch. Man muss immer aufpassen, dass man Änderungen am Quellcode der .ini-Dateien nicht verpasst. Da ich immer nahe an den aktuellen Dev-Versionen bin, ist mir das schon öfters passiert. Da ich nur ein Testgrid betreibe, darf das auch mal passieren. Hält man sich an die Releases, dann sollte man die .ini-Dateien immer auch auf Änderungen prüfen.

Was die Regionen betrifft, so ist das nochmals was anderes. Ich hatte das immer wie Manni gehalten. Wichtig war für mich war immer möglichst flexibel zu bleiben.

Was die Assets betrifft, so sind diese immer in der Datenbank des Robust Servers. Was in den Datenbanken der Simulatoren liegt, sind die Prim- und PrimShape-Daten (inkl. Texturen) der gerezten Objekte und der PrimItems (Daten zu Asstes das sich im Inventar des Objekts befinden). Es ist aber absolut richtig (und meines Erachtens zwingend notwendig) die gridweit von Robust verwalteten Daten separat zu halten.

Ich müsste mal wieder über die Bücher. Aber soweit ich mich erinnere, gibt es auch andere Optionen zur Trennung von Code und Konfiguration. Eine davon ist, dass die Konfiguration in einem hartcodierten config-Unterverzeichnis liegt und die andere, dass OpenSim.exe mit einem /config Parameter gestartet werden kann. Ob das heute noch möglich ist oder ob das sogar nur eine von mir selbst programmierte Variante war, weiss ich nicht mehr. Das war um 2014, dass ich mich damit befasste und auch eine Konfiguration hatte, bei der alle laufenden Instanzen das gleiche Programmverzeichnis nutzten. Sowas würde ich heute nicht mehr machen.