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.
Das ist ja das Schöne daran heutzutage, Fluch und Segen für Linden Lab zugleich, dass man es sich aussuchen kann, mit welchem Viewer man denn im Grid unterwegs sein will.
Der Firestorm selber hinterlässt dabei mir in der aktuellen Version einen zwiespältigen Eindruck: ich finde es beachtlich, was hier ein Team von Freiwilligen in mühevoller Kleinarbeit alles aus dem Stock Lindenviewer herausgeholt hat und dabei geschafft hat. Das kann man nicht hoch genug schätzen.
Wenn ich denn aber den Firestorm benutze, so stellt sich bei mir sehr schnell ein Eindruck ein, den die Amis mit fünf einfachen, vernichtenden Worten so beschreiben: it leaves me completely underwhelmed.
Auf gut Deutsch: für mich ist der Viewer in der aktuellen Version nach wie vor unbrauchbar, ganz einfach weil er zu langsam läuft. Was nützt es mir denn mal überspitzt gesagt, wenn ich in der Aufmachung einer S-Klasse von Mercedes den Boxermotor eines Käfers stecken habe? Genau das ist für mich nach wie vor der Firestorm. Da nehme ich mir dann doch gleich lieber einen VW Golf (Lindenviewer u.a.), der kann dann zwar nicht allzuviel und hat im Vergleich zum Armaturenbrett des Firestorms viel weniger Stellschrauben, aber bringt mich flott genug und zuverlässig an mein Ziel. Oder anders gesagt: der aktuelle Lindenviewer läuft auf meiner Hardware um Längen schneller als das aktuelle Firestormrelease. Das ist für mich ein KO-Kriterium.
Aber der neue Lindenviewer hat so eine tolle Performance … der flutscht einfach wie in Babyöl getaucht. Leute-die-wo-Firestorm-am-machen-am-sein-sind – hört mich an! Euer Viewer ist das Beste seit geschnitten Brot – ihr müsst ihn nur etwas flotter und weniger hardwarehungrig machen!
Bis das soweit ist, lasse ich den Firestorm lieber auf meiner Platte links liegen und benutze ganz einfach direkt den Lindenviewer oder Abkömmlinge, die direkt auf dem aktuellen Code des Lindenviewers basieren. Vielleicht wird es ja beim nächsten Release des Firestorms besser, bis dahin ist er für meine Bedürfnisse nach wie vor nicht alltagstauglich. Sobald es dann dieses Release gibt, werde ich mir das anschauen und mir erneut meine Meinung überdenken.
Schön also, wenn man die Wahl hat. Nach wie vor gilt dabei natürlich: your mileage may vary, also man personlich macht vielleicht ganz andere Erfahrungen damit. Die Welt ist bunt, und ich bin auf das nächste Release des Firestorms gespannt!
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.
Die Hauptplattformen, für die man in Zukunft entwickeln und dazu Binaries zur Verfügung stellen will, sind Windows 32 bit, Linux 32 und 64 bit. Man will weiterhin einen Viewer entwickeln, der sowohl für Second Life als auch Opensimulator gleichermaßen gut funktioniert.
Was bedeutet dies im Endeffekt? Die Tage von Imprudence sind so langsam endgültig gezählt. Ich gehe davon aus, dass es noch in nicht zu ferner Zukunft das finale Release von Imprudence 1.4.0 geben wird, danach wird man diesen Viewer nur noch im Wartungsmodus pflegen. Das bedeutet, dass neue Features für Imprudence nicht mehr zu erwarten sind, höchstens die wichtigsten Sicherheitslöcher gestopft werden und ansonsten man ihn eben solange noch benutzen können wird, solange sich Second Life/Opensimulator nicht zu sehr verändert hat. Das ist für Imprudence, sollte nicht jemand es übernehmen, den Code weiter zu pflegen und zu aktualisieren, der langsame Tod auf Raten.
Kokua wird der Viewer sein, dem das Team dann seinen eigenen Stempel aufdrücken will und an dem es hauptsächlich arbeiten werden wird. Dieser Schnitt mag hart klingen, ist aber nur logisch, denn es macht einfach besonders bei einem kleinen Team einfach keinen Sinn, auf Dauer zwei sehr unterschiedliche Codebasen zu pflegen, wovon eine mehr und mehr dem Bitrot ausgesetzt ist.
Imprudence selber wird nicht der einzige Viewer dieser Art sein, der langsam aber sicher verschwindet, das Team um Jessica Lyon hat dasselbe ja auch schon mehr als oft genug für den Phoenixviewer angekündigt – deren Flaggschiff heißt denn nun eben Firestorm.
Einige alte, bekannte Rollenspieler haben etwas großes vor. Lurch Swindlehurst, Haron Strom, Marthy Mesmer und Hoshy Rhapsody planen im auf Opensimulator basierenden German Grid 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.
Es sind große Pläne und könnte durchaus interessant werden, sofern man es eben schafft, genügend Spieler zur Registrierung im German Grid zu bewegen und dann noch vom Alter her zu verifizieren. Die alleinige Lage dort hat den Vorteil, dass man vollkommen unabhängig von der Finanzierung agieren kann und daher ein ganz anderes Spiel ausziehen können wird, ebenso wird man nicht von den allseits bekannt-berüchtigten und meist nur störenden Ballertrupps verschont bleiben, einfach weil es diese dort nicht gibt. Das sind, wenn es denn sonst stabil läuft, gute Voraussetzungen für gediegenes Rollenspiel der dichteren Art und Weise.
Die Knackpunkte dabei sind aber die Altersverifizierung, die wird nicht jeder mitmachen wollen, und der fehlende Content für die Avatare. Aber es könnte durchaus interessant 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.
MySQL dagegen ist ein ausgewachsenes Datenbanksystem, das viel mehr Funktionen als SQLite bietet. Es könnte zwar auch embedded laufen, aber in den meisten Programmen wird das wegen der Größe nicht so realisiert. Da es um einiges komplexer als SQLite ist, bedeutet es zunächst erst einmal einigen Aufwand das System so einzurichten, bis es läuft. Ist es aber erst einmal installiert und am Laufen, dann kann das System sehr gut skalieren und vor allem ist es bei der Abarbeitung der Writes dann SQLite überlegen. Wenn dann natürlich MySQL mal nicht laufen sollte, funktioniert die Sim sicher auch nicht mehr richtig.
Als Fazit kann man grob sagen: wer nur mal eben so eine Opensim für sich aufsetzen will, dem wird SQlite ziemlich sicher ausreichen und es funktioniert einfach. Fährt man aber dann ein größeres Setup wird es interessant, MySQL aufzusetzen. Läuft MySQL natürlich sowieso schon auf dem Rechner, spricht auch nichts dagegen, es gleich zu nutzen. Für Opensim-on-a-stick wiederum ist SQLite die erste Wahl. Wer seine Sim in ein bestehendes Grid reinhängt, dem reicht wiederum SQLite auch allemal aus, da sich die Writes dann doch stark in Grenzen halten (z.B. Terrainänderungen und dergleichen).