Viewer

Das mit den Gemütslagen mancher Opensourcentwickler ist ja so eine Sache. Das Leben ist natürlich nicht einfach, meistens ist es sogar recht undankbar, längst nicht alles, was man programmiert, wird auch von Projektleitern dann übernommen. Das empfinden viele als einen Schlag ins Gesicht, kommt aber täglich vor und damit muss man eben einfach leben, fertig. Nicht umsonst hieß das Essay von Eric S. Raymond damals “Die Kathedrale und der Basar.”

NiranV Dean hat nun bei Linden Lab einen Bugreport eingereicht, dass die Attachments im Viewer nicht genau symmetrisch dargestellt werden und, wie es sich gehört, das alles schön fein säuberlich dokumentiert plus eine mögliche Problemlösung gleich mitgeliefert. Das klingt im Prinzip erstmal nach einer runden Sache, das Ticket nennt sich Open-162. Da gibt es auch einige Bilder dazu, inwieweit nun sich der bisherige Fehler genau auswirkt. Eigentlich ist es mehr eine Kleinigkeit kosmetischer Natur.

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.

Auch in Firestorm gibt es den praktischen Dialog, mit dem man sich Beacons aller Art anzeigen lassen kann, zum Beispiel wenn man herausfinden will, wer denn nun gerade da mit Sounds um sich wirft. Die dazugehörende Tastenkombination ist Strg+Alt+Umschalt+N. Sehr praktisch!

Dieser obige Gedanke kam mir, als ich bei Maddys Wochenumschau die Neuigkeiten von Nalates Urriah in Bezug auf den Mesh Deformer gelesen habe. Nun, was ist geschehen? Zunächst einmal die gute Nachricht: es wird nach wie vor am Mesh Deformer mit Hochdruck gearbeitet und die Entwicklung geht offenkundig weiter, auch wenn man davon in der Öffentlichkeit momentan weniger mitbekommt, so stehen die Räder da dennoch nicht still. Das ist schon mal eine gute Sache, vor allem wenn man auch bedenkt, wie lange dieses Feature nun bereits in der von SL-Bewohnern finanzierten Entwicklung steckt! Wer zahlt, der will schließlich auch irgendwann etwas dafür sehen, und man sieht es auch!

Wo liegt das Problem? Das Problem liegt nach Nalates Urriah darin, dass der sagenhafte Mesh-Deformer momentan vor allem auf älteren Rechnern das Tempo einer Weinbergschnecke vorlegt im Bereich seiner Berechnungen.

Die Avatare werden nacheinander, also seriell, abgearbeitet und die Kalkulationen sind sehr umfangreich. Die Zeit, die sich dann ein älterer Rechner gönnen soll bis er mit Deformieren fertig ist, soll im Bereich von mehreren Minuten liegen und das ist einfach für ein fluffiges SL-Erlebnis viel zu lange.

Ich habe mir zu der Änderung im Umgang mit dem JIRA-Tracker noch so einige, weitere Gedanken gemacht.

Die einen sehen darin einen notwendigen Schnitt und Schritt in die Normalität. Ein Bugtracker ist schließlich zum Melden von Fehlern gedacht und nicht als Abstimmungssystem über Features, die viele nun sehr gerne hätten oder um in den Kommentaren Druck auf die Entwickler auszuüben. Aber gerade das war sehr häufig im Laufe der Zeit im JIRA geschehen, wer kennt es nicht, dass irgendjemand ein Ticket zu irgendwas eröffnete, dann den Link weiter reichte und darum bat, man möge bitte dafür abstimmen, damit Linden Lab mal den Arsch hochkriegt und das behebt? Eben!

Dafür war das System nie gedacht gewesen, andererseits ist es aber auch so, wenn man es wirklich systematisch ausgewertet hat, konnte man daraus eine Menge über die Wünsche seiner Kunden erfahren.

Also ist das aus Sicht Linden Labs ein Schritt in die richtige Richtung, diese Unkultur im Bugtracker zu unterbinden, für die er niemals gedacht gewesen ist.

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

Die Entwickler vom Exodus Viewer erweitern in Zusammenarbeit mit Linden Lab den Second Life Viewer um die Möglichkeit der Verwendung von Normal und Specular Maps - Linden Lab kümmert sich um die Serverseite, Exodus um den Viewer. Da ein Video mehr als tausend Worte sagt, schaut euch oben das Video dazu an, danach sieht man klarer was da bald auf uns zukommt (das Video ist aus dem offiziellen Secondlife-Kanal bei Youtube und taufrisch).

Das sind Eigenschaften, die manche Designer schon lange gerne gehabt hätten - und nun bald kommen werden. Zudem soll es möglich sein genauer festzulegen, wie Licht von Oberflächen reflektiert werden wird. Alles in allem eine schöne, neue Sache Second Life grafisch noch opulenter zu gestalten (auch wenn sicherlich viele nun wieder sagen werden, dass Linden Lab besser erstmal einen Haufen bereits bestehender Features mit dem notwendigen Feinschliff vollenden sollten, bevor sie da schon wieder eine weitere Baustelle eröffnen).

Linden Lab hat letzte Woche in ihren eigenen Beta- und Entwicklungsviewern den Kommandozeilenparameter “-loginURI” ersatzlos gestrichen, mit dem es bisher möglich gewesen ist mit Linden Labs eigenen Viewern per Hand andere Grids anzusteuern.

Dazu gibt es folgenden Chatlog mit Oz Linden, in dem er es Nebadon Izumi erklärt:

[10:07] OzLinden : ping [10:09] pong [10:10] are you guys really removing -loginURI support from the viewer? [10:10] or is that just a mistake? [10:10] cause latest Dev and Beta viewers get an error if you try to use it [10:11] that was deliberate, but there is a related bug that I’m working on now [10:12] ok so it will eventually be back? [10:12] no, I don’t believe so [10:12] why is it being removed? [10:13] part of cleaning up grid handling - it really doesn’t serve much useful purpose [10:13] sure it does [10:13] it lets us connect to opensim [10:14] this essentially kills all support for OpenSim [10:14] which our Havok license does not allow

[Mehr]

Es ist ja schon seit längerem still geworden um den Imprudence-Viewer bzw. dessen offiziellen Nachfolger Kokua. Jacek Antonelli hörte bereits vor Monaten auf, an den Viewern zu entwickeln und Nicky Perian übernahm das Ruder.

Nur weil es aber im Blog von den Machern still geworden ist, so heißt das noch lange nicht, dass sie nicht weiter am Viewer arbeiten würden. Weit gefehlt, am Kokua Viewer wird gerade munter geschraubt und gehämmert, und es gab einige Ankündigungen von Nicky Perian in der Opensim-Users-Mailingliste, das neue Betas zum Download bereit stünden.

Interessant ist das auch und vor allem für Benutzer von 64bit-Linux, da es Kokua in einer nativen Version für diese Plattform gibt.

Also - wer Kokua in der aktuellen Beta mal testen will, der wird hier fündig: https://bitbucket.org/NickyP/kokua-dev/downloads. Es gibt dort Downloads für Linux und Windows, der Stand ist Mitte Juni. Have fun!

Im März wurde Oz Linden bei Treet.TV zur Viewerentwicklung befragt. Unter anderem ließ er dabei diese Aussage vom Stapel:

“Our own viewer users are a minority. A significant minority – we’re the number three viewer behind, behind the two… Phoenix is far and away the number one viewer, although it’s quite steadily losing market share these days, has been for some months now. And Firestorm is the newer technology viewer from your project, is the number two, and it’s gaining market share… And our viewer is number three behind Firestorm.”

Damit bestätigt er nur das, was man mit den Viewertags alltäglich sah und sich so noch immer dachte: die Benutzer des lindeneigenen Viewers sind eine Minderheit. Die meisten Benutzergruppe hat nach wie vor der Phoenixviewer, der sich auf Platz 1 befindet aber an Marktanteilen verliert, gefolgt vom Firestormviewer, der Marktanteile langsam aber stetig gewinnt, und der Lindenviewer kommt dann auf Platz 3.

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!