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

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

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

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

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!

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.