Programming

Am 17. Dezember 2012 verkündete das Phoenix-Team das Ende der Entwicklung des beliebten Phoenix-Viewers. Die Gründe dafür sind unter anderem, dass man nicht mehr weiterhin zwei unterschiedliche Codebasen pflegen will und 2013 neue Features wie Serverside Baking erscheinen werden, die ohnehin die Kompatibilität mit der 1er-Viewercodebasis brechen werden.

Festzuhalten dabei ist: man kann seinen Phoenix noch weiterhin benutzen, die Entwicklung aber wurde Ende 2012 eingestellt. Eine lange überfällige Ankündigung, bei der man förmlich die Freude des Teams, endlich diesen Zombie losgeworden zu sein, spüren könnte. Die Reaktionen auf den Post sind zweigeteilt: die einen haben absolut kein Problem damit, und sich beim Phoenix-Team für all die Arbeit bedankt, sie nutzen in Zukunft nun entweder eben Firestorm, Singularity oder den Cool Viewer. Andere aber tun so, als sei dies der Untergang des Abendlandes und überziehen das Team mit überbordender Häme und Flames.

Ein bekannter Vertreter war früher beispielsweise S.C.U.M.M. von Lucas Arts, in dem viele von deren berühmten Adventures (wie Monkey Island, Day of the Tentacle und weitere) programmiert worden sind. Heutzutage aber ist der bekannteste Vertreter dieser Art eindeutig Lua.

Wo kommt es her? Lua ist ursprünglich eine Entwicklung einer katholischen Universität aus Rio de Janeiro in Brasilien. Die Entwickler beschreiben Lua als schnelle, leichtgewichtige, mächtige und einbettbare Skriptsprache. Es ist sehr einfach möglich, Lua in beliebige Spiele als Skriptsprache einzubetten und dann zu benutzen. Der gepackte Download hat gerade einmal 182 Kilobyte und Lua selber ist in nur 20.000 Zeilen C-Code implementiert. Damit ist die Codebasis klein und überschaubar, also auch sehr gut wartungsfähig.

Linden Lab wusste sicher, dass mit der Einführung von Pathfinding einiges an Arbeiten auf sie zukommt, da Teile der Physik massiv geändert worden sind.

Interessant ist es dabei wenn man mal einen Blick ins JIRA-System wirft, was sich so bisher dort an bekannten Bugs versammelt ha t. Ich gehe davon aus, dass diese Fehler zügig bereinigt werden, denn manche davon sind richtig unschön. Man sieht auch daran vor allem, dass trotz dem längeren Test auf den Magnum RC-Regionen damit längst nicht alle möglichen Fehlerquellen entdeckt worden sind, sonst wäre das JIRA nicht voll davon.

In der Kategorie Showstopper (also die höchste Stufe, so etwas wie ein GAU, weil damit eine extrem wichtige Funktion nicht mehr funktioniert) befindet sich das Ticket PATHBUG-181. Die Funktion llVolumeDetect() ist fehlerhaft gemeldet. Dies betrifft vor allem Vehikel, wenn die auf ein Prim mit dieser Funktion prallen (typischerweise der Start/Zielstreifen einer Renstrecke), dann ist das Prim entweder auf einmal lange genug nicht mehr Phantom und schleudert so das Vehikel zufällig in eine andere Richtung oder aber während einer Kollission auf einmal nicht Phantom und lässt das Vehikel gar nicht mehr passieren. Damit sind Rennen momentan schwer bis unmöglich, die Besitzer von Rennstrecken schäumen vor Wut und lassen in den Kommentaren ihren Gefühlen freien Lauf. Ich bin mir sicher, der Fehler wird schnellstmöglich behoben sein. Kurioserweise tritt der Fehler umso wahrscheinlicher auf je größer das Prim mit dem Skript ist.

Linden Lab hat seine diesjährige Lagbekämpfungsintiative unter dem Namen Projekt Shining veröffentlicht. Das Hauptziel soll es sein, die Geschwindigkeit des Aufbaus von Avataren und Sims zu erhöhen.

Das Projekt gliedert sich dabei in drei Teilprojekte namens Projekt Sunshine, Objekt Caching und HTTP-Bibliothek. Als Begleitmaßnahme wird Linden Lab gleichzeitig die Anzahl der Rechenzentrenstandorte von drei auf zwei reduzieren und nach Angaben von Rod Humble in diesem Jahr noch die höchste Investition der Firmengeschichte in neue Hardware tätigen.

Projekt Sunshine Projekt Sunshine ist das Teilprojekt, welches das korrekte Rendern von Avataren deutlich beschleunigen soll. Bisher läuft das Spielchen so: damit ein Avatar nicht als Wolke erscheint, holt sich zunächst der Viewer vom Benutzer alle angezogenen Texturen des Avatars, es werden einige simple Bildbearbeitungsalgorithmen darüber laufen gelassen - stellen wir uns das einfach wie verschiedene Ebenen in Photoshop vor, die man übereinander legt und exportiert - und das Ergebnis wird dann an den Simulator hochgeladen. Diese im Fachjargon Baked Texture genannte Datei wird dann an alle weiteren Benutzer in der Nähe gesendet.

Nirans Viewer macht es mit dem Release 1.36 gerade vor: es ist ein Errungenschaftssystem (Englisch: Achievements) eingebaut, wie man es von moderneren Spielen und MMORPGs kennt. Wie das aussieht, kann man bei Maddy ausführlich bewundern, daher erspare ich mir hier einfach die Screenshots davon.

Zudem ist der Viewer inzwischen offiziell in der TPVD drin, herzlichen Glückwunsch!

Nun ist es ja so, dass nach Rod Humble Linden Lab im Moment genau darauf setzt, was Niran vormacht, nämlich Gamification. Achievementsysteme sind irgendwie das neue Buzzword in der Branche, und werden in Zukunft häufiger vorkommen, als man meint. Selbst so dröge Software wie die Compilersuites von Microsoft sollen Achievementsysteme verpasst bekommen, um die Programmierer zu Entdeckungen und besserer Arbeit zu animieren. Muss also was dran sein, und man kann sich das bei Kleinstweich für umme bereits runterladen!

Niran und Microsoft zeigen, was Gamification bedeuten kann. Nachdem Rod Humble in der Spieleindustrie jahrzehntelange Erfahrung hat, weiß er das auch auf dem Effeff. Die Frage ist daher: wie lange dauert es denn noch, bis auch der offizielle Lindenviewer solch ein System spendiert bekommt? Ist so etwas bei Linden Lab überhaupt bereits in Planung? Denn wenn Linden Lab es ernst mit der Gamification ist, dann wird sich das zu alleerst im Viewer zeigen müssen, wo denn auch sonst!

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.

Nachdem es einige Zeit lang um das Projekt sehr ruhig geworden war, hat nun Qarl Fizz Version 0.3 des parametrischen Mesh-Deformers veröffentlich t. Die Hauptänderungen sind die folgenden:

1. der Patch funktioniert nun sauber mit dem aktuellen Code der Lindenviewer, was ja ein erklärtes Ziel gewesen ist und
2. die Deformationstabellen werden nun in einem extra Thread im Hintergrund berechnet, so dass es zu keinen Einbrüchen bei den FPS mehr kommen soll.

Es ist zu erwarten, dass die üblichen Verdächtigen (Nirans Viewer, aber auch Cool Viewer usw.) den Patch bald bei sich eingebaut haben werden.

Second Life selber ist schön bunt anzusehen, ein netter Zeitvertreib und macht vielen einfach Spaß. Wer sich in Second Life begibt und dort bewegt, der hat sicherlich alles andere am Hut, als sich mit Mathematik zu beschäftigen, und doch ist höhere Mathematik in Second Life allgegenwärtig, man muss nur einmal genauer hinschauen, um es zu begreifen. Mehr noch: ohne Mathematik wäre eine Welt wie Second Life gar nicht möglich!

Geometrie allüberall Das beginnt schon mit den Prims: diese sind nichts anderes als einfache, geometrische Formen. Damit man sich in Second Life bewegen kann, wird jedem Punkt in einer Sim eine eindeutige Koordinate zugeteilt, das ist nichts anderes als ein dreidimensionales, kartesisches Koordinatensystem.

Nun bewegt man sich aber auch in Second Life oder gewisse Objekte bewegen sich, und damit kommt schon höhere Mathematik ins Spiel, denn um genau solche Effekte zu beschreiben, benötigt man Vektoren. Vektoren selber sind Bestandteil der sog. linearen Algebra, und mit diesen kann allerhand angestellt werden.

Ist Nirans Viewer tot? Zumindest gerüchtet das gerade der selbsternannte “Secondlife Technologist” JayR Cela.

Nach seinen Worten habe Nirans Viewer ins Gras gebissen, da Nirans Rechner einen Festplattenschaden erlitten habe und - wie leider so oft üblich - es kein Backup gäbe. Es sei kein großer Verlust, da ohnehin niemand den Trumm hätte laufen lassen können.

A-ha. Was daran wohl nun wahr ist? Keine Ahnung. In Nirans Blog steht nichts, in Sluniverse auch nichts weiter, im offiziellen Forum zum Viewer ist nichts zu finden und der Sourcecode ist nach wie vor auf Sourceforge.net verfügbar. Wenn, dann fehlen bestenfalls einige Tage an Neuerungen, das dürfte es gewesen sein und den Rest kann man sich wieder flott unter Windoof zusammenbasteln.

Dazu kommt - und das ist noch wichtiger - dass die letzten Commits am Code von Niran selber auf der Projektseite bei Bitbucket gerade mal 21 Stunden zurück liegen. 21 Stunden! Ein totes Projekt sieht für mich nun wirklich anders aus, ich halte die Meldung daher für substanzlosen Müll und Panikmache. Mehr dürfte da auch nicht dran sein!

Ivy Sunkiller entwickelt seit einiger Zeit eine python-ähnliche Skriptsprache namens slurp, deren Ziel es ist, die Programmierung mit LSL zu vereinfachen. Slurp dabei selber ist in Second Life nicht lauffähig, sondern wird durch einen Übersetzer nach LSL konvertiert. Die Idee dahinter ist dabei dieselbe wie Coffeescript, welches nach Javascript umgewandelt wird: man kapselt Teile der Syntax von LSL sowie der Komplexität vom Benutzer ab, dadurch soll das reine Programmieren einfacher und schneller von der Hand gehen. So fehlen in Slurp zum Beispiel die Strichpunke am Ende jeder Zeile und die geschwungenen Klammern völlig, die in LSL ja überall Standard sind, und auch will Ivy einige fortgeschrittene Datentypen bereitstellen, die LSL von Haus aus nicht bietet - was nichts anderes bedeute, als dass sie diese in LSL selber programmieren werden muss.

Eine Demoimplementierung des Projektes ist hier zu finden, da sieht man auch den bisherigen Stand recht gut. Eigentlich wollte er schon längst eine lauffähige Beta veröffentlicht haben, warten wir einmal ab, wann diese kommen wird.