Sollte Opensim mit der Kompatibilität zu Second Life endgültig brechen?

Bartholomew Gallacher 7. Mai 2012 0 Kommentare

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.

Die Frage ist, was hätte man gewonnen aber was auch verloren, wenn man die Kompatibilität komplett aufgeben würde? Der Vorteil wäre, man könnte wohl viel alten Ballast abwerfen, den so das Projekt mit sich herumschleppt und auch die Viewer. Der Nachteil wäre aber, dass die potentielle Benutzerbasis viel kleiner werden würde und es auch schwieriger werden würde, den Viewer und anderes noch zu entwickeln.

Außerdem nutzen viele eben wegen der Kompatibilität Opensimulator als Bauplattform oder genauer Vorbauplattform für SL. Diese Benutzer würde man mit einem Bruch verlieren.

Ich denke daher, dass es besser ist, die Kompatibilität weitestgehend aufrecht zu erhalten, denn wie das Hypergrid zeigt kann man trotz dieser mit Opensimulator Bereiche als Pionier belegen, die Second Life eben bewusst nicht besetzt.

Wer wirklich einen Server für virtuelle Welten sucht, der mit Second Life gebrochen hat, der wird bei realXtend fündig. Dies ist in der Tat ein Fork von Opensimulator, der sich aber stark von SL weg entwickelt hat, inklusive eines eigenen Viewers der von Grund auf neu programmiert worden ist.

Eine Sache, die allerdings wirklich Sinn machen würde für Opensimulator wäre es, einen Viewer als offiziellen Viewer des Projekts zu wählen, der dann möglichst umfassend alle Spezialfunktionen von Opensimulator auch wirklich abdeckt, die der SL-Viewer nicht beherrscht. Ein guter Kandidat dafür dürfte der Cool Viewer von Henri Beauchamp sein, denn der kann das bereits fast alles in der Tat.

Collar in Opensim

Bartholomew Gallacher 7. Mai 2012 0 Kommentare

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.

Opensim kann bisher keine multiplen Attachments

Bartholomew Gallacher 7. Mai 2012 0 Kommentare

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.

Opensim sucht freiwillige Helfer für den Linuxtag

Bartholomew Gallacher 7. Mai 2012 0 Kommentare

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

Hypergrid 2.0: die Zukunft ist jetzt!

Bartholomew Gallacher 5. April 2012 0 Kommentare

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.

Also was wird mit Hypergrid 2.0 kommen, was sind die Ziele?

Inventar
Zuerst einmal  soll das Inventar zu 100% abgesichert werden und der Ordner „My Suitcase“ wird endlich ohne externe Webapplikationen benutzbar sein [Anm.: 100% Sicherheit kann und wird es niemals geben, bei solchen vollmundigen Claims werde ich immer skeptisch!]. Wenn ein Benutzer in ein anderes Grid teleportiert, dann hat das Grid nur noch Zugriff auf den Ordner „My Suitcase“ und der Rest ist nicht sichtbar. Teleportiert der Benutzer dann zurück, wird der Ordner „My Suitcase“ wieder durch den echten Root-Ordner ersetzt und fertig.

Ob und wie der Ordner genau genutzt werden kann, wird dabei konfigurierbar sein. Es kann beispielsweise sein, das manche Grids den Export ihrer Assets mit diesem Ordner nicht erlauben wollen, und so wird der Benutzer dann extern leicht anders ausseehen.

Zugriffskontrolle auf Benutzerebene
Es werden verschiedene Richtlinien an Zugriffskontrollen implementiert werden: wer teleportieren kann und wie, wer zu einem teleportieren kann und von wo. Diese Kontrollen werden auf verschiedenen Richtlinien basieren, die die Information über die Benutzer selber als auch deren Herkunftsgrids berücksichtigen werden.

So wird es beispielsweise möglich sein, dass nur Benutzer ab einem bestimmten Level über das Hypergrid andere Grids besuchen können werden, während andere unterhalb dieses Levels es nicht können – das ist ein Wunsch, den gerade Bildungseinrichtungen häufig fordern. Es wird möglich sein, eine Liste an Grids festzulegen, die die Benutzer besuchen dürfen – oder nicht.

Für mögliche Gäste ist es ebenfalls analog möglich zu bestimmen, von welchen Grids Besucher erlaubt sind und für welche nicht – oder es ganz einfach ganz abzuschalten.

Zugriffskontrolle auf Asset-Ebene
Es wird eine Möglichkeit geben um einzustellen, ob das Grid Assets exportieren darf und wenn ja, zu welchen Grids oder generell. HG 2.0 wird dabei allerdings keine feinere Einstellungsmöglichkeit unterstützen, man wird also nicht sagen einstellen können, das ein bestimmtes Set an Assets exportiert werden darf und das andere nicht. Dies benötigt eine Möglichkeit, so etwas einzustellen und bisher ist diese noch nicht existent.

Region Ini Generator für Opensim

Bartholomew Gallacher 21. März 2012 0 Kommentare

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.

Phoenix Firestorm 3.3.0.24880 im Test

Bartholomew Gallacher 10. Februar 2012 1 Kommentare

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.

Zasta selber hat das im November 2011 so beschrieben, und für mich hat sich am aktuellen Release des Firestorms daran nichts geändert:

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!

Imprudence Tage sind endgültig gezählt

Bartholomew Gallacher 10. Februar 2012 0 Kommentare

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.

Brundisium oder: Totgesagte leben länger

Bartholomew Gallacher 1. November 2011 0 Kommentare

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…

Opensim: SQLite vs. MySQL

Bartholomew Gallacher 26. August 2011 0 Kommentare

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