Opensim

In letzter gibt es immer und immer wieder eine Diskussion, die sich darum dreht, ob Opensimulator endgültig mit der Kompatibilität zu Second Life brechen sollte oder nicht.

Geschichtlich gesehen war die Kompatibilität gewollt, da sie vieles einfacher machte: man konnte bereits vorhandene Software in Form des Second Life Viewers benutzen und weiter entwickeln, das erleichterte vieles und sorgte am Anfang dafür, dass man aus dem SL-Reservoir trinken konnte, sich SL-Residents in Opensimulator auch recht gut zurecht fanden und und und.

Nun ist es so, dass Opensimulator aber nicht unbedingt auf Dauer unbedingt diese Kompatibilität aufrecht erhalten muss. Es könnte sich auch in Richtungen entwickeln, die interessant sind, wenn man mit der Kompatibilität bricht. Aber macht das dann auch einen Sinn? Das ist dann die Frage.

Denn man kann sehr wohl großteils mit Second Life kompatibel sein und dennoch erfolgreiche, eigene Akzente setzen, man schaue sich dazu nur einmal das Hypergrid oder die Megaregionen an.

Und noch einen zu Opensim: jemand fragte nach, ob es denn ein für OS funktionierendes Collarskript gäbe, denn die letzten Postings dazu im Forum seien aus dem Jahr 2009.

Als Antwort darauf kam, man solle einfach die Region Littlefield im Osgrid besuchen, dort gäbe es so ziemlich alles, was man sich für RLV/RLVa vorstellen könne. Na dann.

Und noch einen aus der OS-Mailingliste, jemand fragte nach, ob Opensimulator multiple Attachments beherrschen würde, da das für vielerlei Zwecke wie RP sehr nützlich wäre.

Justin Clark-Casey antwortete selber darauf:

Not yet.  More detail at [1].

Implementing multiple attachments on a single attachment point looks perfectly doable though unfortunately it means navigating and maybe cleaning up some foolishness in the way attachments are stored (e.g. at the moment there are two duplicate data structures that store attachment information).

[1] http://opensimulator.org/wiki/Feature_Matrix#Users

Auf Deutsch: nein, bisher kann Opensimulator das nicht, aber es sei wohl nicht weiter schwer das Opensim beizubringen, aber man müsse dafür wohl einigen grottigen Code aufräumen sowie die Datenbankstruktur anpassen.

Folgendes ist ein Crosspost aus der Opensim-Users-Mailingliste, vielleicht ist das ja für den Einen oder Anderen interessant.

Hallo,

Opensim wird auf dem LinuxTag in Berlin vom 23. - 26. Mai mit einem
Stand vertreten sein. Fuer diesen Stand suchen wir noch einige
Helfer um den Besuchern Opensim vorzustellen.

Es gibt viel Arbeit und kein Geld, dafuer aber das schoene Gefuehl,
der Community geholfen zy haben und das koennt ihr auch mit nach
Hause nehmen!

Wenn ihr interessiert seit, Opensim zu helfen mehr Benutzer zu
finden schreibt bitte an melanie@opensimulator.org . Bitte postet
keine Hifeangebote auf dieser Liste, da wir sie nicht durchgehend lesen.

Melanie

Diva Canto (bürgerlicher Name Crista Lopes), die Erfinderin des Hypergrids, erklärt in einem ihrer seltenen Blogposts bei sich, was für die Version 2.0 des Hypergrid-Protokolls geplant ist und wie es funktionieren soll.

Zunächst geht sie dabei ein wenig auf die Geschichte der verschiedenen Versionen ein: so war HG 1.0 ausschließlich als “proof of concept” gedacht gewesen, um zu testen, ob das Konzept überhaupt funktionieren könnte, nicht mehr aber auch nicht weniger. Die Implementierung irgendwelcher Sicherheitsmaßnahmen stand dabei noch nicht zur Debatte, es ging ausschließlich darum, ob man dem Viewer glauben machen könnte, dass er sich noch im selben Grid bewege - und man konnte. Das Hauptziel zu testen, ob und wie man den Viewer für Zwecke mißbrauchen könne, für die er niemals gedacht gewesen war, war erfolgreich erreicht.

Als nächstes Ziel mit HG 1.5 ging es darum, erste einfache Sicherheitsmaßnahmen zu etablieren. Mit dieser Version wurde eine fälschungssichere Identität eingeführt, ein etwas sicherer Zugriff auf das Inventar und gridübergreifende IMs sowie Freundeslisten. Das ist der aktuelle Stand der Dinge, für den große Teile von Opensimulator umgeschrieben werden mussten, damit es überhaupt funktionierte.

Wer mit Opensimulator experimentieren will, aber dabei das Editieren der Konfigurationsdateien per Hand mittels eines Editors zuwider ist, dem könnte dieses Tool hier eine gute Hilfe sein: der Region Ini Generator.

Es setzt .NET unter Windows voraus, ist auf Englisch und ansonsten soweit selbsterklärend.

Da liegt sie also nun vor mir, das zweite offizielle Release des Viewers, auf den viele Lindenviewerhasser all ihre Hoffnungen projiziert haben, dem designierten Nachfolger des erfolgreichen Phoenixviewers aus derselben Schmiede, das Ergebnis von mannjahrelanger Arbeit: Phoenix Firestorm 3.3.0.24480.

Habe ich vom ersten Release, welches damals eigentlich genauso gut die Versionsnummer 1.0 nicht allzuviel erwartet, da man von solchen Versionen ohnehin nicht allzuviel erwarten darf, so ist es mit der Version nun anders. Bei konservativer Versionierung würde diese Phoenix Firestorm Viewer Version 1.1 heißen.

Es ist üblich, dass bei solchen Versionen hauptsächlich die gröbsten Fehler bereinigt werden, Sicherheitslöcher beseitigt werden und die Effizient erhöht wird. Genau das wurde mit dem Firestorm nach offizieller Aussage auch getan plus dem Hinzufügen einiger, weitere Features.

Ich habe mir den Viewer unter Windows 7 64 bit Professional nach einem Clean Install installiert und dabei getestet, ganz einfach weil ich es immer interessant finde, was es alles so auf dem Markt gibt - die Viewer stellen ja inzwischen so etwas wie ein eigenes Ökosystem dar - und welcher Viewer wohl für meine Bedürfnisse am Besten geeignet ist.

Diese Meldung ist zwar nicht mehr ganz taufrisch, aber dennoch bin ich gerade jetzt erst darüber gestolpert: es gab am 31. Januar ein Treffen der Entwickler des Imprudence-Viewers, auf dem beraten wurde, was die Hauptziele der zukünftigen Entwicklungsarbeit sein sollen.

Das Problem der Crew ist dabei ganz einfach, dass sie zur Verwirklichung aller hoch gesteckten Ziele zu wenig Manpower haben und daher Prioritäten setzen müssen. Das ist allemal besser als der Status Quo, denn in der letzten Zeit stagnierte die Entwicklung des Viewers gewaltig.

Das Hauptergebnis des Treffens ist, dass man fortan sein Hauptaugenmerk auf die Entwicklung von Kokua, dem auf V2/V3-Code basierenden Viewer des Teams, legen will. Es wird noch ein offizielles Release von Imprudence 1.4 geben, aber danach nichts mehr in dem Bereich, was zu viel Zeit kosten wird.

Ausserdem will man endlich die Trennung zwischen Imprudence und Kokua vornehmen; Imprudence ist das alte Viewerprojekt, währenddessen Kokua den Next Generation Viewer darstellen soll - auch wenn es da noch sehr viel zu tun gibt.

Einige alte, bekannte Rollenspieler haben etwas großes vor. Lurch Swindlehurst, Haron Strom, Marthy Mesmer und Hoshy Rhapsody planen im auf Opensimulator basierenden German Gri d einen goreanischen Kleinverbund namens Brundisium.

Im Endausbau wird dieser aus sechs Sims bestehen und ausschließlich dieser Stadt gewidmet sein. Es soll buchnahes Spiel betrieben werden, Combat Meter wird es keinen geben und Kämpfe werden nach noch zu findenden Regeln ausgewürfelt werden. Wer daran teilnehmen will, und das wird wohl für Viele ein Showstopper sein, wird irgendwie rechtsverbindlich wegen des Jugendschutzes seine Volljährigkeit nachweisen müssen. So etwas heißt in Deutschland Verfahren wie Postident, Kopie des Personalausweises schicken, persönliches Treffen oder anderes mehr, wie das genau aussehen soll, ist ebenfalls noch in der Diskussion, auch der Nachweis über Xing- oder andere Accounts ist im Gespräch.

Das Spiel selber in Brundisium soll einem moderierten Hauptstrang folgen und es sind ein, später zwei feste Spieltage in der Woche geplant. Alles in allem handelt es sich dabei also um ein sehr ambitioniertes Projekt für Leute mit ordentlich Pioniergeist, weil man seine lieb gewonnenen Objekte aus Second Life nicht mit hinüber nehmen kann. Man fängt im German Grid bei Null an, und wird sich erst einmal damit umtun müssen, sich mit den notwendigen Items auszustatten. Es ist unwahrscheinlich, dass die großen Hersteller für die RP-Klientel nun ausgerechnet im kleinen German Grid deswegen eine Dependance aufmachen werden.

Eines der Themen, das bei der Benutzung von Opensimulator immer und immer wieder auftritt, ist die Frage nach der Datenbank: soll man nun SQLite oder MySQL für seine Installation nutzen? Die Gründe für die Wahl sind nicht immer für jeden verständlich, dabei ist es wenn man es aufdröselt recht simpel.

Zunächst einmal zur Grundlage: beides sind Datenbanken und damit fähig, die von Opensimulator benötigten Daten zu speichern und zur Verfügung zu stellen. Allerdings gibt es zwischen beiden Ansätzen einige Unterschiede. Beide Produkte sind stabil und reif genug für den Produktiveinsatz in ihren jeweiligen Einsatzgebieten, also man holt sich damit keine Bananensoftware ins Haus.

SQLite ist eine sog. embeddable Database Engine, das bedeutet es handelt sich dabei um eine kleine Programmbibliothek in C geschrieben, die man in Programme einbetten kann und dann da direkt Datenbankfunktionen zur Verfügung stellt. Da die Engine direkt im Programm abläuft, entfällt sehr viel an Overhead und SQLite ist da in seinen Anwendungsgebieten natürlich rasend schnell. Der Vorteil an SQLite ist, dass ein Programm es out of the box mitbringen kann und man muss wirklich Null administrieren, es funktioniert einfach. Aufgrund seiner Zielsetzung ist SQLite auf das schnelle Verarbeiten von Reads aus der Datenbank optimiert worden. Solange es darum geht, viel aus einer Datenbank zu lesen, ist es die erste Wahl. Ein Problem dagegen stellen die Writes dar, wenn man also etwas in die Datenbank schreiben will. Da kann nämlich SQLite nur einen zur selben Zeit bearbeiten und arbeitet zudem mit einem globalen Lock, sprich in der Zeit werden keine andere Transaktionen durchgeführt. Die Datenbank selber ist bei SQlite eine einzige Datei, die man problemlos kopieren kann.