Alles im Eimer - Bukkit & Sponge für Desinteressierte

  • Momentan noch Work in Progress, ich bitte angesichts der Zeit, zu der ich das hier schreibe, um Verständnis für verwirrende Gedankengänge.
    In den letzten Wochen gab es zahlreiche Einschneidende Geschehnisse, die das Bukkit-Projekt und damit den meistgenutzten Minecraft-Servermod nachhaltig prägen können. Ich versuche hier, die Geschehenisse möglichst vollständig und gleichzeitig übersichtlich darzustellen. Dies geschieht nach bestem Halb- bis Dreiviertelwissen. Sowie ich auf weitere Informationen stoße werde ich dieses Posting erweitern, auch bei Unklarheiten und fehlerhaften Formulierungen werde ich nachbessern.



    Am 21. August 2014 erklärte EvilSeph seine Absicht, das Projekt einzustellen über Twitter und das Bukkit Forum. Die genauen Gründe sind nicht öffentlich gemacht worden, jedoch gilt als gesichert, dass unter anderem zwei gewichtige Faktoren eine Rolle spielen: Das Schrumpfen der Community und damit der Wegfall gleichermaßen kompetenter wie motivierter Entwickler und die relativ plötzliche Entscheidung von Mojang, eine EULA durchzusetzen, die den zahlreichen Pay to Win Servern den Saft abdrehen sollte. Angesichts dieser Hürden hielt EvilSeph es für nicht sinnvoll, zu versuchen, die riesige Menge an Änderungen, die mit Version 1.8 kommen sollten, zu stemmen.



    Allerdings antwortete nicht einmal zwei Stunden später Jeb im Namen von Mojang auf den Tweet und erklärte, Bukkit gehöre Mojang. Es wurde von EvilSeph und Dinnerbone bestätigt, dass Mojang 2012, als sie die Schlüsselfiguren des Projekts eingestellt hatten, auch, als Bedingung für diese Einstellungen, die Rechte am Projekt selbst erworben hatten. Das widerum bedeutete: EvilSeph kann Bukkit nicht beenden. Das kann nur Mojang. Und die hatten, wie Jeb erklärte, kein Interesse daran, Bukkit einfach sterben zu lassen. Sie erklärten, es sei bedauerlich, dass EvilSeph nicht mehr weitermachen wolle, aber dann müssten sie halt übernehmen. Dinnerbone erklärte, er würde es zu seiner persönlichen Aufgabe machen, Bukkit auf Version 1.8 zu bringen. Noch am selben Tag hatte Mojang die volle Kontrolle über Forum, Homepage und die Source Code Repositories des Projektes übernommen.


    Wie es zu den weiteren Vorfällen kam, ist mir selbst nicht ganz klar. Am 05.09. wurden alle Downloads von Craftbukkit und davon abgeleiteten Servermods sowie der dazugehörige Programmcode mittels einer DMCA-Notice gestoppt (das ist quasi ein "Die verbreiten Sachen, auf die ich ein Copyright habe"-Brief. Hat etwa den Effekt wie die GEMA-Nachricht auf Youtube). Ein Entwickler, der seit Anfang 2012 an Bukkit und CraftBukkit entwickelt hat, hat die große Gesetzeskeule geschwungen, weil er durch die Weigerung Mojangs, den Programmcode für den Minecraft-Server verfügbar zu machen, einen Verstoß gegen die GNU-Lizenz, unter der Bukkit (und damit auch sein eigener Code) veröffentlicht werden, gesehen hat. Damit befindet er sich zwar im Recht, hat aber eine Pattsituation geschaffen, aus der es nur drei Auswege gibt: Entweder er nimmt die Notice zurück und erlaubt die Nutzung seines Codes trotz Lizenzverstoß oder Mojang muss den Code für den Server öffentlich machen, um der Lizenz zu genügen. Der letzte Ausweg wäre, Craftbukkit auf Version 1.1 zurückzubomben und alles, was seitdem geschehen ist, ohne den Code des betreffenden Entwicklers nochmal neu zu machen. Was effektiv nicht sinnvoll durchführbar wäre und damit mit dem Tod des Projekts gleichzusetzen ist.


    Was nun?
    Das Projekt befindet sich in der Schwebe zwischen Leben und Tod. Laut (u.a.) EvilSeph und TnT ist es tot. Mojang ist sich durchaus bewusst, dass das Projekt von Bedeutung ist. Laut einem Chatlog zwischen Amaranth (einem Bukkit Entwickler) und Grum (von Mojang) hat Mojang kein Interesse daran, Bukkit weiterzuführen oder sich dort überhaupt einzumischen - sie sahen sich vielmehr gezwungen, einzuschreiten, um es nicht sterben zu lassen. TnT schrieb (ich persönlich bin geneigt, ihm da zuzustimmen), dass Mojang erfolgreich alles unternommen hat, um die verbleibenden Unterstützer des Projektes abzuschrecken. Sie haben alle Aspekte des Projektes an sich gerissen und dann tagelang mit nicht geringem Effekt weder irgendwelche Informationen über die Weiterführung bereitgestellt noch irgendwelche Kommunikationsversuche mit den verbleibenden Angehörigen des Projektes unternommen. Dieser Umstand führte unter anderem dazu, dass mittlerweile über 20 Mitglieder des Projektes, darunter (soweit mir bekannt) alle Administratoren und fast alle Moderatoren ihren Abschied von Bukkit genommen haben und von ihren offiziellen Funktionen zurückgetreten sind.


    Es gibt jetzt also zwei große Blockaden. Erst wenn diese gelöst sind, kann es mit Bukkit und damit mit gemoddeten Minecraft Servern weitergehen.
    Die eine ist die Lizenzfrage zwischen dem Entwickler Wolvereness und dem Projekt. Vubui (von Mojang) behauptete, Wolvereness habe gar kein Recht, die Weiterverwendung seines Codes zu verbieten. Damit es weiter gehen kann, muss dieser entweder die Verwendung seines Codes erlauben oder Mojang muss mit dieser Aussage vor einem Gericht Recht bekommen.
    Die andere ist die Vertrauensfrage zwischen Mojang und der Bukkit-Community. Mojang hat einen denkbar schlechten Start hingelegt, indem sie Hals über Kopf das Projekt an sich gerissen haben, und dann durch Verzicht auf sämtliche Kommunikation Unsicherheit und Spekulationen wild wuchern lassen. Wenn das Projekt dasselbe bleiben soll, wird sich da noch einiges zur Kommunikation tun müssen...

    There are only two difficult things in programming. Naming things, cache invalidation and off-by-one-errors.

    Einmal editiert, zuletzt von Saladoc ()

  • Ein kleines Update. Nachdem die Verbreitung von CraftBukkit und den entsprechenden Derivaten durch die DMCA Takedown Notice verhindert wurde, schoss eins wie Pilze aus dem Boden: Servermods, die diese Lücke füllen sollten. Dies ist vermutlich der Zeitpunkt, um über andere Servermods zu sprechen.
    Am Anfang waren es dunkle Zeiten für Minecraft Modder. Jeder machte im wesentlichen sein eigenes Ding. Bis unter der Leitung des Programmierers hey0 ein Projekt namens hMod entstieg. Dies war die erste Schnittstelle, die es für die Modifizierung und Erweiterung von Minecraft gab. Ende 2010 / Anfang 2011 ging es dann mit hMod zu Ende, da hey0 bekannt gab, er habe keine Lust mehr auf Minecraft und somit auch auf hMod. Diese Lücke versuchte das zu jener Zeit noch recht neue Bukkit Projekt zu füllen. Viele der ehemaligen hMod Entwickler wechselten, andere gingen zum Projekt CanaryMod. CanaryMod ist letztendlich eine direkte Fortsetzung des hMod Projektes, angestoßen vom User Shadow386. Diese Mod über lange Zeit von nur einem einzigen Programmierer gepflegt worden und hat momentan Minecraft Version 1.7.2 erreicht.
    Aus dem Bukkit Projekt entstanden auch noch weitere Servermods, unter anderem Spigot (Minecraft-Server mit Bukkit Schnittstelle, sehr stark auf Performance optimiert) und Cauldron (entstanden aus dem Bestreben, Bukkit und die Client-Modding Schnittstelle Forge zusammenzuführen). Alle diese sind nun durch die DMCA Takedown Notice eingefroren, lediglich CanaryMod könnte noch weiterarbeiten. (Und Spigot hat einen ziemlich halbseidenen Weg gefunden, bestehende Versionen noch mit Updates zu versehen - ich kann das gerne genauer erläutern, wenn Interesse besteht).
    Mit dem immer unausweichlicher scheinenden Tod von Bukkit sind jetzt also ein Haufen intelligenter Programmierer mit einer gewissen Leidenschaft für Minecraft ihre Freizeitbeschäftigung los. Was auch prompt in der Planung eines neuen Projektes resultierte. Diese Mod nennt sich Sponge und wird direkt für Minecraft 1.8 entwickelt. Die Schnittstelle basiert auf SpoutAPI, ist aber eine komplette Eigenkreation mit vielen Einflüssen verbreiteter Schnittstellen. Ich habe große Hoffnung, dass bis zum Erscheinen einer Offiziellen Plugin-Schnittstelle Sponge recht gut zu nutzen sein wird. Ich hoffe daher, dass dieses noch junge Projekt den Erwartungen, die in es gesteckt werden, gerecht werden kann und werde es weiterhin im Auge behalten.




    There are only two difficult things in programming. Naming things, cache invalidation and off-by-one-errors.

  • Damit so ein Projekt ins Laufen kommt, müssen erst einmal einige Dinge erledigt werden. Damit ich mir hier keinen Wolf schreiben muss, führe ich mal in Kurzform auf, was bereits passiert ist.

    • Sponge hat nun einen Issuetracker, über den die offenen Programmieraufgaben verwaltet werden: Link
    • es wurden Standards festgelegt, wie der Code im Projekt auszusehen hat, damit er einheitlich und klar verständlich ist.
    • Die Logische Struktur des Projektes wurde festgelegt, für einzelne bereiche wurde ein Hauptverantwortlicher festgelegt Link
    • Es wurde festgelegt, wie die einzelnen Programmierer zum Projekt beitragen können. Man unterscheidet zwischen Core-Programmierern und normalen (siehe unten)
    • Einige grundlegenden Designentscheidungen wurden getroffen


    Es gibt nach wie vor keinen offiziellen Release-Termin, aber das Team hat angekündigt, dass hoffentlich binnen eines Monats eine erste Version herauskommt. Die wird dann noch stark eingeschränkte Funktionen haben, aber dann natürlich auch zügig weiterentwickelt. Hoffen wir mal, dass es weiter so gut voran geht. Mir persönlich gefällt, dass die Projektleitung zum Schluss kam, es habe keinen Sinn, herumzudiskutieren, bevor Code geschrieben ist, und daher anstatt vorher zu diskutieren, wie man etwas am besten macht, einfach angefangen haben und gewissermaßen sagen: "Wenns euch nicht gefällt, schreibt nen Kommentar und Verbesserungsvorschläge"

    There are only two difficult things in programming. Naming things, cache invalidation and off-by-one-errors.

  • Nachdem sich ja nun wieder beim Sponge-Projekt wieder was getan hat, hier nochmal ein Update. Das wichtigste zuerst. Und weil es so wichtig ist, mach ich es fett:
    Die SpongeAPI wird im November released, die Serverimplementierung erst danach (nach wie vor kein Termin).


    Das bedeutet, die ganzen Pluginprogrammierer können ihre Plugins bereits ab November portieren, allerdings noch nicht testen. Dennoch ist es ein großer Fortschritt für das Projekt.


    Während jetzt also eifrig an der API gearbeitet wird, werden zudem schon Vorkehrungen getroffen, dass Sponge später auch effizient läuft. Sponge wird nämlich auf dem Forge-Servermod (nicht ganz das gleiche wie der Clientmod, den einige hier verwenden) aufsetzen - da Forge nicht unbedingt als der effizienteste Servermod gilt, hat das Team sich mit LexManos, dem Projektleiter von Forge zusammengesetzt. Dieser sagte zu, eng mit dem Team arbeiten zu wollen um die nötigen Grundlagen zu schaffen, dass der Server dann auch so flüssig läuft wie wir es uns erhoffen.

    There are only two difficult things in programming. Naming things, cache invalidation and off-by-one-errors.

  • Es ist mal wieder Zeit für ein Status-Update. Und heute gibts ein einfaches drei Punkte-Programm:


    1. API
    Die API wurde ja für November angekündigt. Wer die Meldungen in der Zeitung oder der unteren rechten Ecke des Bildschirms mitverfolgt, dürfte wissen, dass wir zur Zeit November haben.
    Passend dazu gibt es jetzt die finale ToDo Liste - sobald alles darauf erledigt ist, kommt der erste Release der API - vorraussichtlich Ende November, oder, wenn es unvorhergesehene Probleme gibt, erst Anfang Dezember. Leider kann ich zu den Möglichkeiten, die sie bietet, noch nicht viel sagen, da die meisten interessanten Events erst noch von den verschiedenen Pull-Requests in das Projekt übertragen werden müssen. Die Struktur von dem, was ich mir bereits angeschaut habe, sieht aber sauber und ordentlich aus. Bleibt nur zu hoffen, dass darunter die Effizienz nicht leidet.


    2. Dokumentation
    Das Projekt hat endlich von den Systemadmins ein offizielles Wiki spendiert bekommen und nun werden Leute gesucht, die es strukturieren und mit Inhalt füllen. Da die Suche nach Freiwilligen erst seit gestern läuft, gibt es im Wiki auch noch nichts zu sehen. Ich bin mal gespannt, ob man dort auch einzelne Seiten für seine Plugins erstellen kann oder ob es ausschließlich auf Sponge und SpongeAPI beschränkt bleibt


    3. Implementierung
    Die Implementierung von Sponge soll ja starten, sobald die API ihr erstes Release bekommen hat. Vorraussetzung ist auch, dass Forge für Minecraft 1.8 bis dahin fertig ist - was noch nicht der Fall ist. Das ist noch nicht abgeschlossen. Es sind auch keine Details zum derzeitigen Stand bekannt. Lediglich, dass LexManos daran arbeitet. Das kann durchaus auch etwas länger dauern, da 1.8 ja wirklich ein gigantischer Patch ist. Sobald die erste leidlich stabile Version von Forge da ist, kann mit der Arbeit an der Sponge Implementierung begonnen werden.


    Edit: Dinge korrigiert, nachdem ich bemerkt habe, dass sich eine Fehlinformation in meinen Quellen befand.

    There are only two difficult things in programming. Naming things, cache invalidation and off-by-one-errors.

    Einmal editiert, zuletzt von Saladoc ()

  • Ja wo isses denn? Der November ist rum.


    Hier! Zwar war zum Releasezeitpunkt auf dem größten Teil der Erde bereits Dezember, aber "technisch gesehen" wurde Version 1.0 der SpongeAPI noch im November released.


    Nun haben wir also eine API und fragen uns: Was haben wir davon? Ein Blick in die Dokumentation verrät: So einiges. Aber eben noch nicht alles. Dafür ist das, was da ist, ordentlich dokumentiert.


    Ich habe beim nun fast zweistündigen durchsehen der Dokumentation einige Dinge gefunden, die mir gefallen (zum Beispiel eine solidere, einfach erweiterbare Architektur) und auch ein paar, die mir missfallen. Dazu hole ich mal etwas weiter aus:
    Die Events, auf die ein Plugin reagieren kann, sind noch lückenhaft. Manche Events, die eigentlich geplant waren, sind noch gar nicht vorhanden, andere (zum Beispiel das PlayerChatEvent, welches anzeigt, dass jemand etwas im Chat schreibt) sind vollkommen verkrüppelt und so zu wenig zu gebrauchen. Auch gibt es noch kein Permissions-System und auch noch keine zentrale Möglichkeit, auf Datenbanken zuzugreifen. All diese Features wurden nicht rechtzeitig für Version 1.0 fertig und werden in den kommenden Releases nachgereicht.


    Für die nächste Zeit wird die SpongeAPI als Rolling Release entwickelt, was frei übersetzt so viel heißt wie "Wir hauen neue Features raus, sobald sie fertig sind und warten nicht immer auf eine neue Version", so dass die Pluginentwickler beständig mit den aktuellen Änderungen arbeiten können. Das ganze wird sich nach Schätzungen bis etwa Version 1.5 so fortsetzen, wonach die API dann aber fürs Erste final ist. Ich selbst habe während meiner Lektüre der Dokumentation noch einige Kommentare im Entwicklerchat sowie der Webseite hinterlassen mit Features, die so noch übernommen werden sollten. (Zum Beispiel eine Möglichkeit, Chunks geladen zu halten. Jeder mag geladene Chunks...)


    Zusätzlich gilt es zu berichten, dass Forge eine 1.8 Beta Version released hat. Da nun also beide Vorbedingungen erfüllt sind, also Forge und die API in einem Stadium, mit dem man bereits arbeiten kann, sind, kann die Arbeit an der Sponge Implementierung beginnen. Für die gibt es noch kein Release-Datum. Da Forge noch in der Beta und Sponge in der Alpha steckt, sind die Sponge-Versionen bis zum ersten offiziellen Release in jedem Fall mit Vorsicht zu genießen.

    There are only two difficult things in programming. Naming things, cache invalidation and off-by-one-errors.

  • Zum neuen Jahr gibt es natürlich wieder ein Update von den Sponge-Leuten und damit eine Zusammenfassung von mir.


    Implementierung
    Während wie im letzten Update beschrieben die API weiterentwickelt wird, arbeitet ein zweites Team daran, die Implementierung, also das, was letztendlich die Plugins laden und ausführen wird, zu programmieren. Und wie wir sehen, sind die seit dem Release der Version 1.0 der API schon fleißig gewesen. Während also das API-Team weiter an der Schnittstelle schraubt, zuckelt das Implementierungs-Team hinterher um all die definierten Funktionalitäten umzusetzen, dafür zu sorgen, dass die Events zum korrekten Zeitpunkt gefeuert werden etc...


    Dokumentation
    Das offizielle Wiki, was ich vor zwei Updates mal erwähnt habe, wurde wieder gekillt und stattdessen ein anderes Format genommen. Die Dokumentation ist damit jetzt (meiner Meinung nach) ansehnlicher. Auch dort geht es voran, auch hier nicht nur in einer Geschwindigkeit. Während das Team um Inscrutable die "original" Dokumentation auf Englisch schreibt, haben sich bereits weitere Freiwillige gefunden, die Übersetzungen für die gängigen Sprachen (Französisch, Spanisch, Deutsch, Polnisch, ...) anfertigen.


    Website
    Zusätzlich zu der neuen Dokumentation gibt es ein weiteres Projekt des webmaster und Serveradmin gratimax: Ein Plugin-Repository, quasi wie BukkitDev in gescheit bedienbar. Das Projekt heißt Ore. Zwar ist noch nicht allzu viel zu erkennen, aber es verspricht schonmal übersichtlicher zu werden als BukkitDev.


    Ansonsten gibt es mal wieder jede Menge Aufrufe, mitzuhelfen. Und dazu eine Ankündigung: Am 24.01.2015 gegen 22 Uhr abends wird in einer Kombination aus Livestream und IRC eine Live-Fragerunde mit dem Sponge Team stattfinden. Ich werde zusehen, dass ich mir das antue und biete dabei an, eure Fragen zu Sponge dahin mitzunehmen (sofern ich sie nicht selbst schon beantworten kann).

    There are only two difficult things in programming. Naming things, cache invalidation and off-by-one-errors.

  • Und wieder mal was neues, nachdem ich ja schon so lange schreibfaul bin.


    SpongeAPI
    Für die, die sich nicht mehr erinnern: Das ist der Bauplan, die Schnittstelle, mit der die Plugin-Programmierer arbeiten. Während neue Features hinzugekommen sind und definiert wurden, wurde auch die Versionsnummer immer weiter angehoben. So befinden wir uns mittlerweile in den Arbeiten an Version 2.1. Die Liste der bisherigen Features sieht schon sehr ordentlich aus und wenn die erstmal alle in der Implementierung vorhanden sind, kann man damit schon einiges machen.


    Bisher gibt es:

    • Block API - um Blöcke zu verändern und durch die Gegend zu schubsen.
    • Items API - eben um mit Items zu arbeiten, Verzauberungen auf Gegenstände zu legen, sogar eine komplett gefüllte Truhe ins Inventar legen...
    • Inventar API - ein sehr innovatives System zum Verwalten von Inventaren aller Art - anders als das, was man bisher aus Minecraft so kennt.
    • Befehle - sehr simple und mächtige Funktionen um mit Befehlen zu arbeiten, automatisch deren Argumente zu parsen...
    • Welten - Sponge unterstützt bereits von Haus aus die Arbeit mit mehreren Welten.
    • Bannsystem, Scoreboards, Text-API, eine mächtige Data API, die als Grundlage für Blöcke, Inventare und Items (und noch einiges andere) dient

    Und auch da wird noch konsequent weiter dran gefeilt. Das Problem ist, die Implementierungen müssen das natürlich erstmal alles aufholen.


    Sponge
    Die Hauptimplementierung wird ein Core Mod sein, der einen mit MinecraftForge gemoddeten Server benötigt. So kann bei der implementierung auf all das zurückgegriffen werden, was Forge bereits bereitstellt. Mittlerweile gibt es auch schon die Entwicklerversionen zum download. Darin ist natürlich längst nicht alles fertig, was die API anbietet. Aber sie nähern sich dem ganzen an.


    SpongeVanilla
    Ursprünglich existierte neben Sponge das Granite Projekt. Granite sollte ein Minecraft Server sein, der auch die SpongeAPI bereit stellt - nur im gegensatz zu Sponge selbst nicht auf Forge angewiesen ist. Irgendwann vor zwei Monaten hat man sich dann entschlossen, Granite in das Sponge Projekt zu integrieren, damit beide von einer gemeinsamen Codebasis profitieren können. Das Projekt heißt daher nun SpongeVanilla, hat aber noch keine öffentlichen Entwicklerversionen. Auch SpongeVanilla arbeitet daran, die von der API vorgegebenen Funktionalitäten bereitzustellen.


    SpongeDocs
    Die Dokumentation für Sponge ist der Teil, in den ich momentan am meisten Zeit investiere. Hier versuchen engagierte Schreiberlinge unter Leitung von Inscrutable, die einzelnen Teile der API zu beschreiben und sie angehenden Pluginentwicklern verständlich zu erklären. Auch hier hinken wir im Prinzip der API hinterher, doch in den letzten drei Wochen hat die Arbeit dort wieder ordentlich Fahrt aufgenommen. Zusätzlich wird die Dokumentation in diverse Sprachen übersetzt. Interessanterweise ist davon die Deutsche Übersetzung am weitesten fortgeschritten.


    Das Forum
    Da gratimax sich vorrangig auch an Sponge beteiligt, steht die Entwicklung von Ore (der Webseite, auf der man dann die Plugins finden wird) erst einmal hintenan. Da sich aber dennoch schon einige Leute daran gesetzt haben, Plugins zu entwickeln, gibt es übergangsweise im Forum Kategorien für in Entwicklung befindliche und sogar schon für fertige Plugins.

    There are only two difficult things in programming. Naming things, cache invalidation and off-by-one-errors.

  • Updates in Kürze



    • ein Beta-Release von Sponge ist für das Ende dieses Jahres angekündigt
    • Am Samstag, den 28.11.2015 um 22 Uhr findet State of Sponge VII statt, ein Livestream, bei dem die Entwickler über erreichtes und die nächsten Ziele sprechen und ausserdem Fragen beantworten. Ankündigung im Sponge ForumTwitch Kanal


    Updates in etwas länger



    Die Implementierung geht weiter voran. Das Flaggschiff des Projekts, die implementierung als Forge mod wurde von Sponge in SpongeForge umbenannt, um eine deutlichere Abgrenzung zu SpongeVanilla, der Implementierung auf Basis des von Mojang bereitgestellten Minecraftservers, zu erreichen. Entsprechend ist SpongeForge etwas weiter fortgeschritten.


    Das größte Community-Projekt ist die Implementierung der Data API. So gut wie alles, was Minecraft intern im NBT Format speichert, ist über die Data API für Plugins zu manipulieren. Sei es die Veränderung des Motivs eines Bildes oder die Verzauberungen auf einem Item - all das wird über die Data API gemacht. An der Implementierung der einzelnen Funktionen waren bis jetzt über 20 Autoren beteiligt; die offizielle Dokumentation wurde sogar um einen Beitrag erweitert, wie man dazu beitragen kann.


    Events sind ein weiterer großer Punkt. Grundsätzlich sind Events Herz und Seele einer Minecraft-Pluginschnittstelle. Ein Plugin teilt dem Server mit, über welche Arten von Events es benachrichtigt werden möchte, zum Beispiel wenn ein Spieler versucht, eine Truhe zu öffnen. Der Server wird dann, wann immer ein solches Ereignis eintritt, eine bestimmte Funktion (den EventHandler) aufrufen und dieser alle Daten, die mit dem Event zusammenhängen, übergeben. Dann kann das Plugin ans Werk gehen. Es könnte bei einem Teleport-Event die Zielposition verändern oder beim Versuch, eine Truhe zu öffnen, überprüfen, ob diese Truhe geschützt ist (und gegebenenfalls dem Event einen Abbruch signalisieren - was dazu führen würde, dass der Öffnungsversuch fehlschlägt). Nachdem die Programmierer feststellten, dass das anfängliche Eventsystem inkonsistent war, haben sie das komplette System noch einmal über den Haufen geworfen und neu organisiert. Diese Events arbeiten nun mit Ursachen (im Code: Cause). Für jedes Event werden alle Dinge angegeben, die zu diesem Event geführt haben. Wenn etwa ein Dispenser aktiviert wurde, enthält das Cause-Objekt, woher das Redstone-Signal kommt. Wenn ich einen Ghast spawne, der dann einen Feuerball nach Basel schießt und er durch die Explosion Schaden nimmt, enthält das Schadensevent sowohl den Feuerball als auch den Ghast - und mich als "Eigentümer" des Ghast. Die Schadensevents selbst geben einen Einblick in sämtliche Modifikatoren, die den Schaden verändern. Ein Beispiel dafür sieht man in diesem Log, wo man schrittweise nachvollziehen kann wie durch vier ausgerüstete Rüstungsteile und die auf ihnen liegenden Verzauberungen der anfängliche Schaden schrittweise von 17,0 (also 8 einhalb Herzen) auf 0.67 (etwas mehr als ein Herz) reduziert wird. Man kann also die Modifikatoren direkt verändern. Das ist ein himmelweiter unterschied zu Bukkit, wo man herausbekam wo der Schaden herkam und wie hoch er ist.


    Im übrigen zeigt sich mal wieder, dass das Design von Sponge es ermöglicht, Sponge Plugins gemeinsam mit Forge Mods zu nutzen. Dazu hat Zidane ein sehr nettes spontanes Demo-Video gemacht, wo er mithilfe eines Sponge-Plugins verschiedene Zaubersprüche des Thaumcraft-Mods aushebelt. Das ist dadurch beeindruckend, dass Thaumcraft als ein Mod gilt, der sehr tief in die Funktionen von Minecraft eingreift. Dass Sponge diese Vorgänge erkennen und blocken kann erlaubt es Schutzplugins wie WorldGuard ohne viel Zusatzaufwand auch die destruktiveren Funktionen irgendwelcher mods zu blocken, falls nötig. (Zumindest wenn die Mods halbwegs sinnvoll programmiert sind...)

    There are only two difficult things in programming. Naming things, cache invalidation and off-by-one-errors.

  • Hier mal ein paar Bilder der Sponge Demo Servers von gestern. Dort haben wir direkt mal Neu-Hügelingen gegründet. :)