Alles im Eimer - Bukkit & Sponge für Desinteressierte

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

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

      Was ist Bukkit?
      Bukkit ist eine Schnittstelle für Programmierer, die das Schreiben von Minecraft Server Plugins vereinfacht und standardisiert. Daraus ergeben sich zwei Vorteile: Zum einen ist ein für Bukkit geschriebenes Plugin auf allen Servern, die die Schnittstelle bereitstellen, lauffähig. Zum anderen wird dadurch, dass die Schnittstelle standardisiert ist, das Risiko von ungewollten Wechselwirkungen und Konflikten zwischen Plugins stark verringert.
      Das Bukkit-Projekt ist eine Community aus zumeist wunderbaren Personen, die in ihrer Freizeit und völlig unentgeltlich diese Schnittstelle pflegen und weiterentwickeln. Zudem pflegen sie noch ein weiteres Projekt, Craftbukkit. Craftbukkit ist ein Minecraft Server, der die Bukkit-Schnittstelle bereitstellt.

      Das Bukkit-Projekt wurde am 21. Dezember 2010 von dem Entwickler Dinnerbone gestartet. Auch wenn er zu beginn die treibende Kraft und der Hauptentwickler war, überließ er die Projektleitung einem Mitstreiter, der unter dem Namen EvilSeph bekannt ist. Ende Februar 2012 erhielten die zentralen Figuren des Projektes, unter anderem Dinnerbone, EvilSeph und Grum, Jobangebote von Mojang. EvilSeph kehrte ein Jahr später Mojang wieder den Rücken, Dinnerbone und Grum blieben dem Projekt weitestgehend fern und konzentrierten sich auf ihre Arbeit mit Mojang.

      Im August 2014 waren die zentralen Personen des Bukkit Teams EvilSeph (Projektleiter), TnT und mbaxter (Administratoren)


      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.

      Warum gefährdet die EULA Bukkit?
      Das Bukkit Team war sich immer bewusst, dass ihr Fortbestehen von der Gnade der Zuständigen bei Mojang abhält. Zwar haben die Entwickler auch ein Gespräch mit Notch und Jeb darüber geführt, aber Lizenztechnisch bewegte sich Bukkit immer auf dünnem Eis. Da Notch und Jeb zu verstehen gegeben hatten, sie fänden zwar die Methoden des Bukkit Teams nicht gut, würden sie aber tolerieren, da es keinerlei sinnvolle Alternative gäbe, konnte man auch nicht von einer unbedingten Unterstützung durch Mojang sprechen.

      Mit den Änderungen der EULA ist es verboten "irgendwas zu verteilen, was wir [Mojang] gemacht haben" (frei übersetzt). Da Bukkit mit Craftbukkit jedoch eine modifizierte Version des originalen Minecraft-Servers verteilt, also Craftbukkit Dinge enthält, die Mojang gemacht hat, wäre Craftbukkit bei strenger Auslegung durch die EULA verboten.


      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.
      -Gadarol.de Werbung-

      Dieser Beitrag wurde bereits 1 mal 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.

      Wer arbeitet mit?
      Wer?
      Was?
      Woher?
      sk89q
      Projektleitung
      Autor von WorldEdit und WorldGuard

      blood
      Projektleitung
      Autor von Cauldron
      mbaxter, zml, TnT
      Entwickler / Forenmods
      Bukkit Projekt
      ganz viele Leute
      Entwickler
      CanaryMod Team
      noch mehr Leute
      Entwickler
      Spigot Team
      einige
      Entwickler
      Bukkit Plugin Entwickler
      mindestens 6 Personen
      Entwickler
      Spout Team (teilweise)

      Und noch etliche weitere.

      Und wenn das gleiche passiert wie bei Bukkit?
      Um das genauer zu beleuchten, müssen wir noch einmal schauen, woran Bukkit gescheitert ist. Zum einen daran, dass Mojang das Recht hatte, Hals über Kopf alles an sich zu reißen und damit die lebensrettenden Maßnahmen zu vergeigen, zum anderen, und das ist das größere Problem, die Lizenz. Die GNU Lizenz, unter der das Projekt stand, gilt nämlich in manchen Kreisen als "Krebslizenz". Sie zwingt jeden, der Bukkit verwenden will, die gleiche Lizenz zu verwenden. Das führte letztendlich dazu, dass Craftbukkit selbst, welches ja auf Bukkit aufbaute, das eigentlich nicht verwenden durfte, da CraftBukkit nicht die GNU Public License verwendet, sondern die LGPL, die Lesser GNU Public License. Damit hätten sie streng genommen aber Bukkit nicht verwenden dürfen, da dessen GNU Lizenz nicht erlaubt, dass es in Projekten verwendet wird, die nicht exakt dieselbe Lizenz haben.
      Dieses gewichtige Problem kann bei Sponge nicht auftreten, da man sich dort für die MIT License entschieden hat. Die besagt, kurz formuliert: "Du darfst meinen Code verwenden, wofür du willst, solange du mein Copyright drin lässt und eine Textdatei mit dieser Lizenz zum Nachlesen beilegst. Aber du kannst mich nicht dafür Verantwortlich machen, wenn etwas in meinem Code nicht richtig funktioniert." Damit hat später kein Entwickler die rechtliche Handhabe, es wie bei Bukkit zu tun und seine Rechte am Code einzuklagen - wer sich an Sponge beteiligt, erlaubt, dass sein Code für alles verwendet werden darf.

      Umstieg von Bukkit auf Sponge?
      Viele Konzepte von Sponge werden ähnlich zu Bukkit sein, alleine aus dem Grund, dass es manchmal nur einen wirklich sinnvollen Weg gibt, etwas bestimmtes zu tun. Dennoch ist es eine andere Schnittstelle und sämtliche Plugins müssen angepasst werden. Es gibt bereits eine Liste, welche Plugins die Community gerne auf Sponge portiert sehen möchte. Darunter sind auch TrainCarts und WorldGuard, die man als für unseren Server essentiell ansehen kann. Bei beiden haben die Entwickler bereits bestätigt, dass ihre Plugins für Sponge verfügbar sein werden.
      There are only two difficult things in programming. Naming things, cache invalidation and off-by-one-errors.
    • Statusupdate Sponge

      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
      Core-Developer

      Es gibt für Entwickler zwei Möglichkeiten, Programmcode zu Sponge beizutragen. Entweder sie erhalten von der Projektleitung direkte Schreibrechte auf das Projekt, oder aber sie arbeiten über sogenannte Pullrequests. Dazu muss ich ein klein wenig ausholen. Der Programmcode liegt auf der Seite github.com in etwas, was sich Repository nennt. Da können alle Änderungen, die jemals am Projekt gemacht wurden, einzeln nachvollzogen werden. Auf das Repository kann man direkte Schreibrechte haben, was heißt, dass man seine Änderungen direkt dort hinein schickt. Nun kann man aber auch, wenn man keine Schreibrechte hat, einen fork ("Gabel", meint eine Abspaltung) von einem Repository erstellen. Ich erhalte dann eine vollständige Kopie des Repositorys als meine eigene Version - da kann ich persönlich dann rumschreiben wie ich will. Ich kann sogar, wenn am Hauptrepository änderungen gemacht werden, die zu mir übernehmen. Das nennt sich "pull". Ebenso kann ich, wenn ich etwas ganz tolles programmiert hab, von dem ich glaube, dass die es auch im Hauptrepository brauchen, eine Pullrequest schicken, also quasi eine Nachricht "hier habe ich tolle Änderungen, macht mal einen pull und übernehmt die". Auf die Art und Weise kann jeder mitwirken, da die letztendliche Entscheidung, ob das Pullrequest angenommen wird, immer noch bei den Core-Developern liegt.
      Der Nachteil an einem Pull-Request ist, dass es zusätzliche Arbeit für die Core-Developer bedeutet. Deshalb haben sie die Regel aufgestellt, dass nur größere Sachen über Pullrequests angeboten werden sollen. Wäre ja blöd wenn sie in der Zeit, die sie brauchen, um das Pullrequest zu bearbeiten, dasselbe viermal programmiert hätten. In den nächsten Tagen kann man sich übrigens bei Sponge noch als Core-Developer bewerben. Man gibt an, an welchem Teil von Sponge man arbeiten möchte und auch Ideen und Pläne, die man dafür hat. Wenn das die Projektleiter überzeugt, erhält man Schreibzugriff auf das Projekt direkt und kann so viel schneller mitarbeiten (und auch Pull-Requests bearbeiten).


      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.
      -Gadarol.de Werbung-
    • 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.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Saladoc ()

    • API 1.0 released, Implementierung beginnt

      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.
    • Schwammige Aussichten auch im neuen Jahr

      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.
      -Gadarol.de Werbung-
    • 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 Forum Twitch 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. :)
      Dateien
      -Gadarol.de Werbung-