Die rabiate Phoenix-Fanbase und noch ein paar Statements von Henri Beauchamp zum Thema Serverside Baking

Bartholomew Gallacher 12. Januar 2013 2 Kommentare

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.

Diese Flamer haben dabei offensichtlich nicht verstanden, was Opensource ausmacht. Opensource heißt, du kannst den Code nehmen und damit im Rahmen der Lizenz machen, was du willst. Es heißt aber nicht, dass nun die Entwickler eines Projekts unentgeltlich nach der Pfeife ihrer Benutzer tanzen müssen und machen müssen, was die wollen. Wenn die Entwickler keine Lust mehr haben, etwas weiter zu entwickeln, dann ist das eben so und fertig. Dann kann man entweder selber die Initiative ergreifen und da weitermachen, oder lebt damit und lässt es eben sein. Punkt, aus, fertig!

Alles in allem sind aber die anhaltenden Flames der Phoenixfanbase mit bisher 178 Kommentare im Blogpost oben dermaßen überzogen, dass sich die Entwicklerin Tonya Souther zu dem Kommentar „Go ahead, fork Phoenix!“ hinreißen ließ. Souther beschreibt die Codebasis des Phoenix-Viewers als hoffnungslos veraltet, dass es schon massiver Arbeit bedürfe, alleine das Meshrendering auf den Level von 3.4 zu bringen – es basiere noch auf Viewer 2.8.

I’m not kidding when I say it’s an unmaintainable tissue of hacks held together by spit, chewing gum, duct tape, and baling wire.

Ich übertreibe nicht, wenn ich sage, dass es [Phoenix] eine unwartbare Masse an Hacks ist, die von Spucke, Kaugummi, Tesafilm und losen Drähten zusammengehalten wird.

Das Zitat lässt dann schon tief blicken, und weil die Fanbase so rabiat weiterhin auf Phoenix pocht, soll sie doch den Mist einfach übernehmen, warten und fertig. Der Rest könne ja mit Singularity oder dem Cool Viewer glücklich werden.

Kurz: Undank ist wohl der Welten Lohn und manche Hohlpfosten fordern da von Freiwilligen eine Arbeitsleistung ein, auf die sie kein Recht haben das einzufordern. Klar, dass da einem schon mal die Galle überlaufen kann.

Übrigens schwebt über all diesen Probleme Henri Beauchamp, denn der bastelt ja nach wie vor an seinem eigenen Viewer, dem Cool Viewer, alleine. Diesen entwickelt er vor allem für sich selbst und wenn jemand Gefallen daran hat, bitte, kann er ihn gerne nutzen. Beauchamp gibt an, über 35 Jahre Programmiererfahrung zu verfügen und dementsprechend kein unbeschriebenes Blatt zu sein.

Gut, Beauchamp hatte mal wieder Langeweile, und daher kann die aktuellste Version vom Cool Viewer bereits Server Side Baking. Ein Feature, das der Phoenix-Viewer nie mehr bekommen wird, es sei denn jemand macht einen Fork und nennt den dann anders. Der Cool Viewer ist damit der erste TPV, der dieses Feature offiziell unterstützt.

Übrigens gibt’s zu dem Thema auch noch eine launige Mail von Beauchamp in der Entwicklerliste an Oz Linden, die es in sich hat. Beauchamp wirft Linden Lab in Sachen Opensource schlichtweg Vollversagen vor, anders kann man es nicht nennen. So schreibt er dies:

I’d rather not judge „Oz, the man“ because it is hard to tell whether his actions are the only result of his own decisions and doings, or are the materialization of LL’s policy towards OpenSource and, if we can judge from the resulting actions their policy would clearly be: „take benefit of all the advantages OpenSource can bring to us (i.e. free coding and debugging horsepower provided by volunteering developers), and dismiss all the duties OpenSource cooperation involves in return (such as providing clean diffs for changed we made behind closed doors(*) before releasing them, but also providing an *open* list of known bugs to developers)“.

Kurz und gut: Linden Lab würde gerne die Vorteile der Community wie kostenlosen Code und Debugging abgreifen, dafür im Gegenzug aber nicht mal die grundlegendsten Selbstverständlichkeiten an die Community, wie eine offene Liste der bekannten Bugs, zurückliefern. Eine Klage, die nun überhaupt nicht neu ist, sondern genau so schon Nicholaz Beresford vor fast fünf Jahren formulierte. Linden Lab bleibt also sich und seiner Linie treu. Das Hauptproblem von Linden Lab sei, dass sie hinter verschlossenen Türen monatelang neues Zeug entwickeln würden und dann – BUMM! – ist es auf einmal eben da. Das sei nicht die Art und Weise, wie Opensource funktioniere, und vor allem käme da Linden Lab seinen Pflichten nicht wirklich nach…

Daran angehängt ist eine Email von Beauchamp an Oz Linden vom Juli 2012, in dem sich Henri lange und breit darüber auslässt, wieso er die Art der Implementierung – basierend auf dem „Current Outfit Folder“ für eine denkbar schlechte Idee hält.

Und jetzt, wo die ersten Testimplementierungen da sind und das Feature offenkundig so bockt wie Beauchamp voraussagte, zeigt Beauchamp denen mit Freuden den Stinkefinger und sagt dazu: „Ich habe es euch doch gleich gesagt!“ – Tja, und er hat damit sogar noch Recht, aber Linden Lab wollte ja nicht hören…

Die Programmiersprache Lua

Bartholomew Gallacher 19. August 2012 0 Kommentare

Viele Spiele kommen ja heutzutage nicht mehr ohne eine irgendwie geartete Programmiersprache aus, in denen gewisse Sachen geskriptet sind und die ggf. zur Entwicklung von Erweiterungen zur Verfügung gestellt wird.

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.

Was bedeutet der Name? Ist das eine Abkürzung?
Nein, Lua ist einfach nur portugiesisch für Mond. Das ist alles.

Was kostet das?
Nichts. Lua wird unter der wohlbekannten MIT-Lizenz zur Verfügung gestellt, die grob gesagt „Mach damit, was dir beliebt, Hauptsache du nennst irgendwo unseren Namen“ als Bedingung hat. Daher ist Lua sehr weit verbreitet.

Wo gibt es Dokumentationen zu Lua?
Zu allererst in Englisch auf der Seite des Projekts, daneben aber auch auf Deutsch wie beispielsweise hier ein Einsteigerkurs und noch eine Referenz.

Welche Spiele nutzen denn nun Lua?
Die Liste ist lang, bekannte Spiele sind unter anderem Die Siedler: das Erbe der Könige, Monkey Island ab Version drei, World of Warcraft, Angry Birds, Baldur’s Gate, Civilization V, Sim City 4, Mafia II und viele andere.

Warum sollte man sich mit Lua beschäftigen?
Ganz einfach: wer schon immer mal wissen wollte, wie eine Spielmechanik geskriptet worden ist oder für Spiele wie World of Warcraft, bei denen die Erweiterungen komplett in Lua geschrieben sind, vielleicht selbst Add-Ons schreiben will oder diese zumindest verstehen, der kommt um Kenntnisse in Lua nicht herum.

Ist Lua neben Spielen noch weiter verbreitet?
Kaum.  Es gibt Ausnahmen wie beispielsweise Prosody, ein komplett in Lua geschriebener Jabberserver, aber die Liste dieser Programme ist dann doch sehr überschaubar.

Pathfinding-Bugs

Bartholomew Gallacher 11. August 2012 0 Kommentare

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

Dazu kommen teilweise fehlerhafte Berechnungen des Land Impacts und ein Haufen weiterer Fehler, die gerade noch kategorisiert werden.

Ich denke mal, in so zwei bis drei Wochen dürften die gröbsten Bugs allesamt beseitigt sein und dann wird man langsam, aber sicher anfangen können damit richtig zu arbeiten.

All work and no play makes Jack a dull boy

Bartholomew Gallacher 3. Juli 2012 0 Kommentare

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.

Im Prinzip eine einfache Sache, aber man sieht, wo es zu Problemen kommen kann: zunächst einmal muss der Client des Avatars einiges an Texturen runterladen, das dauert, dann muss er die Textur berechnen, als JPEG2000 kodieren und wieder hoch laden. Da gibt es genügend Punkte, wo es zu Problemen kommen kann und wenn der Upload nicht richtig funktioniert, sieht der Rest einen möglicherweise grau oder gar nicht.

Dem Abhilfe verschaffen soll eine neue Instanz an Servern, deren einzige Aufgabe es werden wird, die Baked Textures zu berechnen und den Simulatoren zur Verfügung zu stellen. Damit wird diese Aufgabe von den Clients hin zu Servern im Rechenzentrum von Linden Lab verlagert. Das Ergebnis wird eine spürbare Beschleunigung des Rezzens von Avatartexturen sein und wenn Linden Lab es richtig implementiert, dann werden auch graue Avatare endlich der Vergangenheit angehören.

Verbesserter Objekt-Cache
Der lokale Cache des Viewers soll persistenter und performanter werden, das Ziel ist eine massive Erhöhung der Hitrate. Auch soll die Kommunikation vom Viewer beim Aufbau einer Szene mit der Sim optimiert werden.

Das ist eine Maßnahme, die schon lange überfällig ist, denn die schlechte Performance des Viewercaches ist ja geradezu legendär. Außerdem spart das Linden Lab mitunter auch bares Geld, wenn es massiv zu weniger Kommunikation kommen sollte.

Bessere HTTP-Bibliothek
Die HTTP-Bibliothek auf den Simulatoren soll durch eine deutlich besser funktionierende Variante ausgetauscht werden. Man darf gespannt sein, wie sich das auswirken wird, Linden Lab wird wohl kaum veröffentlichen, was sie da genau nehmen und bisher genommen hatten.

Wer damit nichts anfangen kann: HTTP ist ein Transportprotokoll des Internets, das zur Übertragung von Daten – meistens Webseiten – genutzt wird. Festgelegt wurde HTTP/1.0 in RFC 1945 und HTTP/1.1 in RFC 2616. Eine HTTP-Bibliothek stellt nichts anderes als für Programme aller Art die Transportfunktionen bereit, so dass man sie nicht selber erst implementieren muss. Nachdem HTTP ein alter Hut ist, gibt es heutzutage eine Vielzahl an zur Verfügung stehenden Bibliotheken genau für diesen Zweck.

Eine bekannte Bibliothek dieser Gattung, die neben HTTP noch andere Protokolle beherrscht, ist cURL. Diese wird auch standardmäßig im Second Life Viewer zur Kommunikation mit dem Simulator verwendet. Eine Auflistung mit weiteren Bibliotheken für HTTP-Transport findet sich denn hier.

Gamification – ein Weg auch für den offiziellen Second Life Viewer?

Bartholomew Gallacher 15. Mai 2012 11 Kommentare

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!

Linden Lab könnte es sich sogar einfach machen und einfach Nirans Änderungen bei sich für umsonst einbauen, the joy of open source eben! Ob sie das aber machen oder nicht – wir werden sehen. Jedenfalls erwarte ich früher oder später solch ein System auch im offiziellen Lindenviewer, alles andere widerspricht dem neuen Credo der Firma.

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.

Mesh Deformer v0.3 erschienen

Bartholomew Gallacher 26. April 2012 2 Kommentare

Nachdem es einige Zeit lang um das Projekt sehr ruhig geworden war, hat nun Qarl Fizz Version 0.3 des parametrischen Mesh-Deformers veröffentlicht. 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 und die höhere Mathematik

Bartholomew Gallacher 21. April 2012 2 Kommentare

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.

Wer also irgendwann mal mit Rotationen arbeitet oder Objekte skriptgesteuert irgendwelche Bewegungen vollführen lassen will, der kommt nicht wirklich darum herum. Gleiches gilt für das Partikelsystem und vieles, vieles mehr…

Das Geburtstagsparadoxon
Eine weitere Sache, die in Second Life täglich Anwendung findet, ist die Wahrscheinlichkeitsrechnung. Genauer gesagt geht es dabei um das sog. Geburtstagsparadoxon, welches ein altbekanntes und gut diskutiertes Problem der Mathematik darstellt.

Angenommen, in einem Raum befinden sich 23 Personen. Wie hoch ist dann die Wahrscheinlichkeit, dass mindestens zwei von ihnen ohne Berücksichtigung des Jahrgangs am selben Tag Geburtstag haben?

Die Antwort selber ist überraschend: die Wahrscheinlichkeit liegt höher als 50%, bei 36 Personen ist sie sogar bei 83%. (Eine genauere, mathematische Erklärung befindet sich hier in diesem PDF).

Nun möchte man aber fragen: was bitte hat das Geburtstagsparadoxon denn mit Second Life zu tun? Sehr viel, sogar sehr sehr viel, man nutzt es ständig, und die Form der Anwendung ist zum Beispiel solch eine Zahl: 5fe9759e-03e2-4268-8af0-ed165a158df1.

Das ist nichts anderes als die altbekannte UUID (128 bit breit), also der fundamentale Bestandteil aller Assets. Die Sache bei der UUID ist diese, dass diese rein zufällig innerhalb eines gewissen Namensraumes vergeben wird und man mit Hilfe des Geburtstagsparadoxon abschätzen kann, wie hoch denn die Wahrscheinlichkeit einer Kollision (die Vergabe derselben UUID zweimal also) innerhalb dieses Namensraums ist.

Diese ist trotz der stetigen Vergabe von UUIDs so gering, dass sich das System noch auf lange Zeit halten wird.

Nirans Viewer – nicht tot!

Bartholomew Gallacher 21. April 2012 12 Kommentare

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!

Update: so, ich bin nun auf Sluniverse.com doch noch fündig geworden. Zuerst einmal kann man hier nachlesen, das NiranV tatsächlich folgendes schrieb und zwar bereits vor sechs Tagen:

HD suddenly crashed , first whole Windows began to freeze , then after restart HD was gone…nice 2 TB of Data gone , with it my compiling Windows , all my Snapshots , Videos , programs , sourcecode and everything else… i hate self destruction HD…. will probably take many days to get my Windows back up to the point at which it is able to compile…

Sprich: es gab einen Festplattenschaden und alles war weg. So. Aber das ist ja kein Problem, wenn man seinen Sourcecode wie NiranV es tat auch bei Sourceforge.net hostet, und so gab es dann schon nach einigen Stunden folgende Statusmeldung:

good news , everything went ok… downloaded my source and compiled instantly without any error

Was nichts anderes heißt als dass es weitergeht, und man kann auch schon die nächsten, kommenden Fixes dann im Thread lesen. Hätte JayR Cela da ein wenig weiter gelesen, dann wäre es zu seiner komischen Meldung da erst gar nicht gekommen.

Ich verabschiede mich von hier mit einem aktuellen Video von NiranV, das die neuen Voreinstellungen für die Kamera zeigt, bitte sehr:

HJXxXYkPBA4

Slurp

Bartholomew Gallacher 7. April 2012 0 Kommentare

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.

Die Hintergründe zu dem Projekt sind dabei im Post „Fixing LSL – one step at a time!“ zu finden. Alles in allem bin ich auf die Beta gespannt, wenn diese denn mal verfügbar ist.