Das hier ist ein Datum, das sich jeder Benutzer von veralteten Viewern wie Phoenix und dergleichen gut merken sollte: der 9. Juli 2013.

Wie vom gewöhnlich gut unterrichteten Firestorm-Entwicklungsteam zu erfahren ist, plant Linden Research die endgültige Einführung des lange angekündigten Features der Server Side Appearance (SSA), einer Verbesserung im Rahmen des Project Sunshines, ab den 9. Juli 2013 oder kurz danach.

Wer ab diesem Datum also noch immer einen Viewer wie Phoenix benutzen sollte, der die dazu notwendigen Programmroutinen nicht enthält, wird fortan auf dem Grid nur noch haufenweise graue Avatare sehen. Es kann also keiner sagen, er wisse nicht Bescheid, denn SSA ist schon lange genug in der Mache und Linden Research hat schon lange genug angekündigt, was SSA bedeuten wird und dass es kommen wird.

Nun sind offensichtlich alle bösen Bugs eliminiert und SSA ist bereit für seinen großen Auftritt. Man darf gespannt sein, ob die Verbesserung der Qualität wirklich so drastisch ausfallen wird, wie Linden Research sich das erhofft und angekündigt hat.

Wer bis dato noch den Phoenix Viewer oder - hust - Imprudence einsetzt, der wird umsteigen müssen, wenn er noch Avatare in Farbe sehen will. 1er-Viewer, die das Feature unterstützen, sind beispielsweise der Cool Viewer von Henri Beauchamp oder aber der Singularity Viewer von Siana Gearz. Der aktuelle Firestorm unterstützt es natürlich auch und sollte inzwischen soweit fehlerfrei sein, dass man ihn wieder benutzen kann.

Auswahl an Viewern für jeden Geschmack gibt es also genug, und wer nach dem 9. Juli graue Avatare sieht, der ist eben selber schuld.

Die Firestorm Version 4.4 stößt bei vielen gerade auf wenig Gegenliebe. Der einfache Grund: sie ist relativ fehlerhaft und macht keinen Spaß. Das kann bei einem Opensourceprojekt schon mal vorkommen, vor allem wenn die Firma Linden Research eben Druck macht und man gewisse Sachen einfach drin haben muss, wenn sie den Schalter umschalten.

Nun gibt es dazu passend auch den entsprechenden Heulthread in Slinfo. Sehr schön.

Was ich bei all diesen Sachen immer nie verstehe, ist folgendes: wenn alles so schlecht ist, und dieser Viewer so furchtbar - wieso benutzt man ihn dann noch? Es gibt genügend andere Viewer, die man genau so gut benutzen kann und wenn man mag, kann man ja auch die ältere Version benutzen. Alles kein Problem.

Und wer meint, Second Life sei voller Fehler und nur noch schlecht - was macht er dann noch hier? Warum ist er nicht schon gegangen? Es zwingt einen keiner dazu, Second Life zu benutzen, wenn man es nur noch unerträglich findet und es zwingt einen keiner dazu, einen Viewer zu benutzen, den man nicht mag.

Es ist nunmal so: die Entwickler um Firestorm arbeiten umsonst, das ist ihr Hobby und sie bekommen dafür gar nichts. Sie können tun und lassen, was sie wollen, und wenn sie keine Lust mehr haben, werden sie einfach aufhören. Fertig. Manchen Benutzern aber scheint in ihrem Anspruchsdenken das zunehmend aus dem Sinn zu entfliehen, denn sie halten sich für Kunden, die Ansprüche stellen können. Und das können sie nunmal eben nicht.

Die Blogengine WordPress, welche auch dieses Blog verwendet, wurde genau heute 10 Jahre alt. Bei Basic Thinking gibt es daher eine interessant zu lesende Würdigung zu dem Thema. Wer also schon mal immer wissen wollte, woher WordPress kam, wird da fündig.

4

Opensimulator hat ein schönes Feature namens Hypergrid. Das bedeutet kurz gesagt, dass egal wo man hingeht immer sein eigenes Inventar mitnehmen kann und - mehr noch - externe Sachen im eigenen Inventar landen. Das ist eine nette Sache und funktionierte anfangs recht gut.

Die Implementierung stammt von Diva Canto und die erste Version hieß Hypergrid 1.0. Diese war als Proof of Concept gedacht und lief dafür schon recht gut. Sie hatte allerdings einen konzeptionellen, großen sicherheitstechnischen Fehler: der fremde Simulator sah das komplette Inventar des Besuchers und der Assetserver des Besuchers arbeitete treudoof ohne die Überprüfung der Legitimität jedwede Anweisung des fremden Simulators ab. Das konnte einfach das Einpacken eines neuen Objektes sein, aber auch Löschanweisungen.

Da es keinerlei Sicherheitsüberprüfungen gab, war und ist es mit dem Stand von Hypergrid 1.0 möglich, dass ein fremder, bösartiger Server mein komplettes Inventar mal eben so löscht und ich selber bekomme das gar nicht mit. Nun sagen viele: weit hergeholt und davon habe ich noch nie etwas gehört. Tja, aber Jungs und Mädels, nur weil ihr es noch nicht erleben musstet heißt das noch lange nicht, dass es unmöglich ist. HG 1.0 hat einfach sicherheitstechnisch genau dieses riesengroße Loch in Form eines offenen Scheunentors, und ich bin mir sicher, keiner wird dafür die Hand ins Feuer legen, dass nicht doch irgendwo da draußen solche Simulatoren sein könnten und wenn man die dann besuchen sollte, dann hat man eben Pech gehabt!

Diva Canto sah das Problem und es wurde Hypergrid Version 1.5 geboren. Die wesentliche Neuerung dieser Version (es gab i5 und i7) war, dass es fortan einen recht schlechten und holprig zu bedienenden Ordner namens "My Suitcase" gibt. Der fremde Simulator sieht fortan nur noch diesen und kann nur noch in diesem wüten, mehr aber auch nicht. Das ist ein erheblicher Zuwachs an Sicherheit, genau dafür ist es gedacht. Das Problem in der Handhabung des Ordners ist aber, dass die normalen Inventarfunktionen wie Objekte ins Inventar rüberziehen oder Zeug aus dem Ordner löschen nicht funktionierten und bockig sind. Ohnehin ist er nur als Übergangslösung für Hypergrid 2.0 gedacht, das inzwischen aktiv ist und alle drei Protokollversionen beherrscht. Man muss sich dabei eben für eine entscheiden.

Nun ist es also so, dass die Handhabung dieses Ordners viele Benutzer überfordert. Also was machen nun einige Grids? Sie steigen wieder auf die veraltete und in dem Punkt sicherheitstechnisch bedenkliche Protokollversion 1.0 für das Inventar des Hypergridprotokolls um und preisen das sogar noch als Fortschritt für die Benutzer an! So geschehen im Osgrid, Metropolis und Dorenas World.

Die genauere technische Erklärung dabei ist diese: Opensimulator verfügt inzwischen standardmäßig über Hypergrid 2.0, aber man kann das Inventarhandling wenn man will auf frühere Versionen "runterfahren", um mit diesen kompatibel zu sein.

Übrigens hält die Macherin des Hypergrids von solch einem Schritt genau das: nämlich rein gar nichts. Aber lest selbst:

[UPDATE 9/23] I should be more clear. The existing HG1.5 inventory service, which lets users still access their entire inventory abroad, will still be available in the future. Grids can continue to use that. They can even use the normal inventory service (HG1.0 style) on the Hypergrid, which has no restrictions whatsoever about inventory manipulation. Both of these, however, especially the normal inventory service, are horribly insecure and expose users to all sorts of risks regarding their inventory. Unless the networked grids have 100% trust in each other, I don’t recommend using them.

Also ist das Downgrading auf das vrealtete Inventarhandling nun wirklich gut? Nein! Sicher, die Handhabung wird wieder für die Benutzer einfacher, aber wer um das Problem von Hypergrid 1.0 nicht weiß und nicht regelmäßig Backups seines Inventars erstellt, der wird möglicherweise irgendwann wenn er mal wirklich auf einen solchen Simulator treffen sollte nur noch dumm dastehen. Denn es hat schon seine guten Gründe gehabt, wieso Diva Canto "My Suitcase" als notwendig erachtete und das ist eine Sache, auf die die Benutzer dieser Grids wohl kaum hingewiesen werden.

Im Blog "Android and Me" gibt es eine ständige Rubrik der 10 besten Android Apps der letzten Woche. Platz 1: Creatorverse von den Linden Lab.

Na, wenn das nicht mal ein Grund zur Freude für die Lindens ist, dann weiß ich es auch nicht...

Joel Burgess hat bei sich einen extrem interessanten Artikel auf Englisch veröffentlicht, wie Bethesda Game Studios beim Entwerfen von Skyrim modular vorgeht. Wer schon immer mal wissen wollte, welche Art von Baukastensystem da vorherrscht und welchen Aufwand man dafür betreiben muss, der sollte es unbedingt mal in einem ruhigen Moment lesen. Es ist höchst interessant, wie da ein mit 90 Personen recht kleines Team eine solch große Spielewelt gestalten konnte, wofür andere Spiele deutlich größere Entwicklungsteams beschäftigen.

Philip Rosedale baut ja nun an der nächsten Generation von virtuellen Welten mit einem neuen Startup, das er "High Fidelity" getauft hat. High Fidelity oder auch kurz Hi-Fi ist bisher ein im Audiobereich bekannter Begriff, der eine besondere Wiedergabetreue des Verstärkers mit Abspielgerät plus Lautsprecher von Aufzeichnungen kennzeichnet. Festgelegt wurde dieser Standard als DIN 45500 in den 60ern, früher war er etwas besonderes, heute dagegen erreicht jede Noname-Soundkarte für 20 Euronen bereits mühelos diesen Bereich!

Das Neue an Rosedales Projekt sind vor allem zwei Dinge: erstens will er mit Voxeln arbeiten und zweitens soll es eine Art verteiltes, dezentrales Netz werden, an dem jeder teilhaben kann und für das Bereitstellen von Rechenzeit dann sich so virtuelle Münzen verdienen können. Bitcoin und Peer to Peer lassen grüßen!

Beide Techniken sind an und für sich schon ein alter Hut und verteile Währungen so ein Thema für sich, was aber ist das interessante an Voxeln? Voxel selber sind ein alter Hut in der Spielebranche, es gab durchaus eine Reihe von Spielen, die diese einsetzten, wie 1992 beispielsweise Comanche, eine Hubschraubersimulation bei der Voxel die Landschaft zeichneten. Gehalten haben sich die Voxel bisher in der Medizintechnik, während sie in der Spielebranche lange Zeit ein Nischendasein fristeten, weil die gängige Grafiktechnologie auf Polygone setzt und Voxel im Einsatz so einige Probleme mit sich bringen.

Aus diversen Gründen wie vor allem der Speicherbedarf waren Voxel für aktuelle Spiele meist uninteressant, auch wenn es wie bei Crysis aktuelle Titel gibt, wo Voxel zur Darstellung der Landschaft eingesetzt werden.

In der Tat aber sind Voxel und die Entwicklung von voxelbasierten Spieleengines seit einigen Jahren eines der ganz heißen Themen der Spieleindustrie. Spieleentwickler wie John Carmack (ID Software, Doom) beschäftigen sich schon seit längerem damit und forschen daran. Voxelsettings lassen sich sehr gut komprimieren und laufen dann extrem flott auf heutigen Rechnern.

Dieses Video hier zeigt sehr schön den Vorteil von Voxeln: man kann stufenlos von sehr klein nach sehr groß gehen. Ich bin mal gespannt, was da Rosedale am Ende präsentieren wird.

http://www.youtube.com/watch?v=km0DpZUgvbg

Dazu äußerte sich Oz Linden wie folgt:

 There are so many possible failure modes and performance bottlenecks in client-side baking that solving one of them is almost insignificant

Auf Deutsch: es gibt so viele Fehlerquellen und Leistungsengpässe im clientseitigen Baking, dass es nicht ausreicht nur einen davon zu beheben.

Anders gesagt: das bisherige System ist solch ein Mist, dass es einfacher ist es komplett rauszurupfen und durch ein neues zu ersetzen als daran einzelne Fehler zu beheben, denn das wäre nur Flickschusterei.

10

Wir erinnern uns: Phoenix ist seit Anfang des Jahres tot wie ein Dodo. Da kann und wird keinerlei Weiterentwicklung stattfinden, da Firestorm nun das einzige Projekt der Macher ist. Ich kann sie gut verstehen, dass sie ihren Zombie endlich beerdigt haben und froh darum sind.

Nun macht Linden Lab mit seinen Änderungen im Simulatorbereich langsam, aber sicher ernst, und erste neue Features wie die neuere HTTP-Bibliothek sind bereits auf gewissen Servern live. Da wird es auch nicht mehr lange dauern, bis das Serverside Baking (SSB) kommt und damit dann veraltete Viewer wie Phoenix die Avatare nur noch in schickem Grau sehen werden.

Also ist es langsam aber sicher für die Phoenix-Benutzer an der Zeit, ihren Phoenix in den wohlverdienten Ruhestand zu schicken und über einen geeigneten Ersatz nachzudenken. Wer sich mit Firestorm und dem Interface nicht anfreunden kann (obwohl es ein Phoenix-Skin hat!), der sollte sich mal den Cool Viewer von Henri Beauchamp oder Singularity Viewer 1.8.0 anschauen. Beide sind auf diese kommenden Änderungen nämlich vorbereitet und werden ihre Benutzer da nicht im Stich lassen.

8

Während Linden Lab ja mit Hochdruck dabei ist, seine Technik und die Plattform mit Hochdruck um neue Features zu erweitern, die so wirklich Sinn machen - Serverside Baking, Material System usw. - tritt Opensim scheinbar auf der Stelle. Zumindest findet dort nicht wirklich erkennbar eine Entwicklung von solchen Sachen statt.

Die Folge wird schlicht und ergreifend sein, dass Second Life Opensim technisch bis auf einige, wenige Spezialitäten wie das Hypergrid massiv abhängen wird und Opensim wird es immer schwerer haben, den technischen Vorsprung von Second Life aufzuholen.

Vielleicht wollen sie das auch nicht, nur wird so die Schnittmenge an gemeinsamer Funktionalität eben deutlich kleiner im Laufe der Zeit. Vielleicht wäre jetzt mal endlich so langsam ein guter Zeitpunkt, dass Opensim den Schnitt der da facto sowieso kommen wird endlich praktiziert und gewisse Sachen selbst in die Hand nimmt. Warten wir es ab.