Kategorie: Building

Opensim: SQLite vs. MySQL

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).

Meshes und das Viewer-Ökosystem

Die jetzt verfügbaren Meshes sind ja eines der Killerfeatures, die Linden Lab schon lange versprochen hat und nun endlich verfügbar sind. Sie kamen wahrlich nicht über Nacht, es gab lange Zeit eine geschlossene Beta mit ausgewählten Designern und auch mindestens sechs Monate lang eine offene Beta, an der jeder teilnehmen konnte, der wollte. Viele Designer waren da auch fleißig, sammelten im Betagrid reichlich Erfahrungen, so dass sie nun ihre bereits damals erstellten Objekte einfach im Maingrid einführen können, um damit zu arbeiten. Sicherlich ist es zuerst noch eine Sache für die sog. Early Adopters, aber es wird nicht lange dauern, bis sie sich auf breiter Front durchgesetzt haben werden und die kaufbaren Meshes eine ähnliche Qualität erreicht haben werden wie bereits jetzt die Sculpties. Die Vorteile sind einfach zu groß, einfachere Erstellung der Objekte in Blender/Maya/Sketchup/…, dazu wenn man es richtig macht sind sie noch für die Grafikkarte einfacher darzustellen, da man die Anzahl der Polygone hinreichend gut optimieren kann, und und und… kurz, ein Werkzeug nicht nur für Professionelle, aber gerade auch für diese. Die Geschwindigkeit allerdings, mit der sie dann letzten Endes doch kamen, war flotter als erwartet. Rodvik Linden kehrt wohl ganz gut bei Linden Lab und gibt den Leuten die richtigen Arschtritte, damit sie in die Gänge kommen, was kein Nachteil ist.

Nun ist es aber so, dass zur Darstellung der Meshes und damit man in den Genuss derselben kommt, der Viewer diese darstellen können muss und damit fangen dann für die Benutzer die Probleme an. Momentan gibt es genau drei Viewer, die das nämlich können: der Standardviewer von Linden Lab ab Version 3.0, der Snowstorm-Viewer von Linden Lab sowie der aktuelle Kirstens Viewer. Der Rest wird die Meshes zwar von den Daten her auch empfangen können, aber er sieht dann nur Basisprims und nicht die gesamte Pracht. Es wird also durchaus Situationen geben wie „Guck mal, Leo, meine neue, tolle Meshjeans!“ und der guckt und meint: „Was sollen denn da die Pyramiden?“ Das wird kommen.

Meshes treiben also einen Graben in die Viewerwelt, es gibt die Viewer, die sie darstellen können und die Viewer, die es bisher nicht können. Die Viewer, die es können, basieren auf der 2.xer-Codebasis von Linden Lab, weil nur in dieser Linden Lab selber die Meshfunktionalität eingebaut hat. Das bedeutet, dass der Phoenix Viewer, Imprudence, Cool Viewer, Singularity usw. mit Meshes null komma gar nichts anfangen können. Der in der Entwicklung befindliche Phoenix Firestorm soll in einer späteren Version mit Meshes arbeiten können, aber noch sind die entsprechenden Funktionen nicht eingebaut und stehen bisher nicht zur Verfügung. Der Zeitrahmen, den es dauert, bis das soweit ist, wurde von offizieller Seite aus mit „einige Wochen“ bezeichnet. Entgegen bisheriger Befürchtungen wurden die Viewer mit der 1.xer-Codebasis von Linden Lab bisher nicht „abgeschaltet“, aber der Drang sie nun aufzugeben wird bei einigen durch Meshes doch sicher groß.

Damit ist klar, wer Meshes sehen will, der braucht entweder Kirstens Viewer oder den Linden Viewer, daran führt bisher kein Weg dran vorbei. Allerdings gibt es für die Fans der 1.xer-Viewer etwas Hoffnung, denn der Macher vom Cool Viewer – Henri Beauchamp – arbeitet schon nach eigenen Aussagen seit Wochen daran, Meshes auf die alte Viewercodebasis zu portieren, aber das ist eine größere Baustelle und eben dann fertig, wenn es fertig ist. Auch Siana Gearz vom Singularity Viewer schrieb Mitte Juli, dass sie Meshes zur Verfügung haben werden, aber das auch ein wenig dauern würde und sie dafür 120.000 Zeilen Code innerhalb von sechs Monaten umgeschrieben hätten. So oder so, sobald einer dieser Viewer Mesh haben wird, ist es wahrscheinlich, dass die Implementierung auch den Weg in andere 1.xer-Viewer finden wird, bis es aber soweit ist, wird wohl noch einige Zeit vergehen.

Endlich: Meshes sind auf dem Maingrid angekommen!

Was lange währt, wird endlich gut – oder so ähnlich: jedenfalls sind seit einigen Tagen Meshes auf dem Maingrid angekommen und jeder, der will, kann von nun an damit bauen. Damit man Meshes hochladen kann, muss im SL-Konto eine Zahlungsinformation hinterlegt sein (Payment Info) und man muss einen kleinen Quiz von zehn Fragen auf Englisch absolvieren, der einen Crashkurs in Sachen Urheberrecht darstellt. Keine Angst, das geht in unter fünf Minuten und Linden Lab gibt genügend Hilfestellung, den nicht zu bestehen ist unmöglich.

Danach kann man also, einen aktuellen Viewer 3 oder Kirstens Viewer vorausgesetzt, Meshes nach Second Life hoch laden und/oder selber nutzen. Die Benutzer von Phoenix, Firestorm Beta, Imprudence, Cool Viewer und was es sonst noch so alles gibt, schauen dabei momentan in die Röhre, sie sehen die Meshes nur bestenfalls als komische Dreiecke, mehr auch nicht. Hoch laden ist mit den Viewern bisher auch nicht möglich.

Meshes selber werden nun zweierlei bewirken: erstens eine neue Qualität im Bau von Kleidern, Gebäuden und dergleichen mehr, zweitens mal wieder das übliche Gejammere, das sich die Hobbyisten von den Profis aus SL hinaus gedrängt fühlen. Mag sein, muss aber so nicht kommen, und sicherlich werden viele nun anfangen, 3d-Modelle aus den bekannten Datenbanken wie Google Warehouse nach SL zu importieren.

Mit Meshes zum Beispiel kann man endlich Avatarkleidung bauen, wo es keine sichtbaren Nahtstellen mehr gibt zwischen Avatar und Prim. Sehr schön. Ebenso leistet die Schattenfunktion vom Viewer bei Meshes auch eine genaue Schattenberechnung an Klamotten, was sie bei sonstigen Kleidern nicht tut. Sweet!

Wichtig ist eben, dass wie bei Sculpties auch der eigentliche Bau außerhalb von SL stattfindet. Das Hochladen eines Meshes kostet je nach Komplexität des Konstrukts. Die Faustregel dabei ist, je komplexer das Gebilde, desto höher und je komplexer die Physikhülle, die ich brauche, ebenso. Ein Mesh wird dabei nach irgendeiner obskuren Formel letztendlich in eine Anzahl an Primäquivalenten umgerechnet (PE auf Englisch abgekürzt), sprich wenn man es rezzed, dann nimmt es diese Anzahl an Prims auf der Parzelle ein.

Ungewöhnlich und sicher bei manchen Kunden dann Grund für Ärger ist, dass das Vergrößern eines Meshs automatisch die Anzahl an PEs vergrößert. Das wird längst nicht nur für Freude sorgen. Mit der Einführung von Meshes wurde zugleich die Maximalgröße für erstellbare Prims auf 64x64x64 m angehoben. Nifty!

Was wir jetzt erleben werden, ist eine Spaltung in der Viewernutzung. Wer Meshes nutzen und sehen will, der ist darauf angewiesen, den Linden Viewer oder von Kirsten zu benutzen, der Rest schaut in die Röhre. Außerdem kann es zu komischen Situationen kommen, wenn man Meshattachments trägt und der Rest sieht sie nicht richtig.

Auf Dauer werden sie sich sicherlich durchsetzen und bleiben, irgendwann wird man sie so selbstverständlich nutzen wie Sculpties, und das wird sehr schnell geschehen. Wenn denn Firestorm Mesh eingebaut haben wird, wird der Viewer die neue Nummer Eins bei den alternativen Viewern werden, da bin ich mir sicher.

 

Echte Rollenspieler und ihr blinder Fleck

Wir sind ja je nach Ansichtsweise im besten oder schlechtesten aller Leben, und das Leben könnte doch so schön sein: wir sind alle freiwillig im Rollenspiel, wir sind alle hier um miteinander Spaß zu haben und es ist für uns alle ein Hobby. Ja, so einfach könnte doch das Leben sein, nicht wahr? Ist es aber nicht, weil längst nicht alle mit denselben Voraussetzungen ins Rollenspiel einsteigen und das merkt man auch!

Eine Gruppe, die eigentlich besonders pflegeleicht sein sollte, ist dabei leider meiner Meinung nach  in der Praxis öfters auffällig und schwerer zu handhaben, nämlich die echten Rollenspieler aus der Pen&Paper-Ecke. Woher kommt das und was ist das Problem?

Ich erkläre es mir so: beim P&P-Spiel sitzt man sich gegenüber und erlebt das gesamte Spektrum der menschlichen Kommunikation ungefiltert, also Stimmlage, Mimik, Körperhaltung und Körpersprache. Dazu kommt, dass das Setting relativ feststeht, es meistens umfangreiche Regelwerke gibt und vor allem auch einen akzeptierten Spielleiter, der seine Pappenheimer kennt und dementsprechend mal einschreitet, wenn jemand zu sehr ausufernd spielen will. Dazu ist der Kreis der Mitspieler überschaubar, man kennt sich mitunter schon jahrelang untereinander und ist möglicherweise noch gut befreundet.

Dem gegenüber steht nun Second Life. Man spricht nicht, sondern spielt mittels von Avataren, die keine wirkliche Mimik rüberbringen sondern mehr emotionslosen, wenn auch schön ansehbaren Puppen gleichen. Um zu spielen bedient man sich des Textchats mittels Emotes. Nicht jeder tippt gleich schnell und gleich gut, die Sprache als Werkzeug beherrscht nicht jeder gleichermaßen virtuos. Dazu kommt, dass der Kreis der potentiellen Mitspieler ungleich größer ist, anonym ist, man sich eben nicht reell kennt und es auch meistens keinen Spielleiter gibt, der das Spiel lenkt oder von sich aus präventiv lenkend eingreift.

All das wäre kein Problem, wenn alle gleichermaßen diszipliniert spielen würden und vor allem auch die Erkenntnis hätten, das nicht jeder mit denselben Ansichten und Grundvoraussetzungen wie man persönlich ins Spiel einstieg eingestiegen sind. Das ist eben aber nicht der Fall.

Die echten Rollenspieler sind häufig eben, weil sie vom P&P es so gewohnt sind, an epischen Rollen mitsamt einer tollen Charakterentwicklung interessiert. Sie wollen Geschichten schreiben, mitgestalten, erleben, durchleben, viele auch gerne in wichtigen Positionen, also sind oft an Plots interessiert, die sich mitunter Wochen wenn nicht gar Monate hinziehen. Das ist ja an und für sich kein Problem.

Problematisch wird es aber dann, wenn die echten Rollenspieler anfangen in erster Linie nur ihr Ding zu sehen und dieses mit der Brechstange durchsetzen wollen. Oft haben sie dazu die nötige Erfahrung, sie wissen wie man sich eine Rollengeschichte auf den Leib schneidert, dass man in einer Stadt/Gesellschaft in einer mächtigen und nahezu unangreifbaren Position landet, so dass sie in character dazu die Möglichkeit haben und der Rest der Spielerschaft es bestenfalls genervt ignorieren kann. Wenn er Pech hat, dann ist es aber so, dass sich dabei ein gehöriger OOC-Unmut aufbaut, weil die nicht so ganz erfahrenen Rollenspieler sich nicht mitgenommen fühlen, sondern es zu einem Konflikt kommt. Es wandelt sich das Miteinander zu einem Gegeneinander, es kommt schlimmstenfalls in der Gruppe selber zur Grüppchenbildung, und diese Minigruppen stehen noch zueinander unversöhnlich gegenüber.

Nun ist es dann aber so, und das ist der blinde Fleck, dass die echten Rollenspieler da ab einem gewissen Punkt eben nicht mehr mit sich reden lassen, sondern sie in erster Linie nur ihr Spiel sehen und gar nicht verstehen wollen oder können, wieso sich der Rest der Spielerschaft so über sie aufregt. Wenn sie dann noch nicht einmal OOC mit sich reden lassen, sondern es nach dem Motto „Macht mir doch bitte OOC nicht mein Spiel kaputt, sondern löst das IC, danke.“ abbügeln, dann ist meistens völlig der Ofen aus. Spätestens ab dann wird der Konflikt zu einem veritablen Kleinkrieg oder aber die ersten Spieler verlassen wegen der ignoranten, echten Rollenspielfraktion entnervt die Sim und suchen fortan lieber woanders eine neue RP-Heimat, wo das Miteinander noch wirklich gepflegt wird.

Das Problem dabei ist eindeutig, dass in einer P&P-Session schon längst mal der Spielleiter dem Delinquenten die Ohren lang gezogen hätte, aber so etwas im RP in Second Life meistens – wenn überhaupt – zu spät und zu zaghaft passiert. Da aber die echten Rollenspieler so eine ungeahnte Freiheit in der Rollenentwicklung haben, nutzen sie diese – und das muss nicht einmal boshaft sein – auch entprechend aus und finden das dabei noch sogar toll. Was das allerdings für den Rest der Gruppe bedeutet, tja, das sehen sie oft leider nicht.

Das habe ich schon oft genug erlebt, teilweise selbst mitgemacht und es wird auch weiterhin oft genug im SL-RP passieren.