Plugin API

Vorlage:In Zukunft

Dieser Artikel behandelt die Programmierschnittstelle des Spiels. Für die Webschnittstelle von Mojang siehe Mojang API.

Eine Plugin API ist eine Programmierschnittstelle (Application Programming Interface) für Veränderungen an Minecraft, die ohne Umprogrammieren der Java Klassen-Dateien des Programms minecraft.jar realisiert werden, sondern nur durch Hinzufügen (= plugin) von bestimmten Dateien mit bestimmtem Inhalt in einen bestimmten Ordner, wo sie von Minecraft geladen und somit ins Spiel eingefügt werden.

Veränderungen an Minecraft ermöglichen völlig neue Spielerlebnisse, indem dem Spiel neue Spielinhalte (Blöcke, Kreaturen, Menüpunkte etc.) hinzugefügt werden. Der Hersteller Mojang unterstützt solche Veränderungen seines Spiels in gewissem Rahmen:

“

If you've bought the Game, you may play around with it and modify it. We'd appreciate it if you didn't use this for griefing, though, and remember not to distribute the changed versions of our software. Basically, mods (or plugins, or tools) are cool (you can distribute those), hacked versions of the Game client or server are not (you can't distribute those). Wenn du das Spiel gekauft hast, darfst du damit experimentieren und es verändern. Aber wir würden es begrüßen, wenn du das nicht für zerstörerische Zwecke tust (Griefing). Und denke daran, veränderte Versionen unseres Programmes nicht zu verbreiten. Grundsätzlich sind Mods (oder Plugins oder Zusatzprogramme) cool (du darfst sie verbreiten), gecrackte Versionen von Client oder Server sind es nicht (du darfst sie nicht verbreiten).

„

Die Veränderungen oder Erweiterungen für Minecraft müssen also getrennt vom Originalspiel verbreitet werden. Man darf nicht das Spiel verändern und dann verbreiten. Das bedeutet, dass der Anwender die Veränderung selbst an seiner Originalversion des Spiels durchführen muss. Dabei unterscheidet man zwischen Mod und Plugin:

• Die Veränderung des Spiels mit einer Mod (= Modifikation) geschieht von innen heraus, d. h. durch Umprogrammieren von minecraft.jar. Dies ist nicht nur für den Mod-Entwickler umständlich, sondern auch für den Anwender, denn er muss mit Hilfsprogrammen (ModLoader) die Mod mit dem Spiel minecraft.jar verbinden und so ein modifiziertes minecraft.jar erzeugen. Der Eingriff in die Programmierung kann unvorhersehbare Folgen bis hin zu Programmabstürzen und Datenverlusten haben.
• Die Veränderung des Spiels mit einem Plugin geschieht von außen: Das fertige Plugin wird vom Anwender einfach nur in einen bestimmten Ordner gestellt (= eingestöpselt, engl. plugin), damit es vom Spiel erkannt und angewendet wird. Auch der Plugin-Entwickler hat es einfacher: Er schreibt sein Programm getrennt von minecraft.jar und greift auf die Funktionen des Spiels über eine API zu. Die API ist wie ein großer Baukasten von Einflussmöglichkeiten auf das Spiel. Der Hersteller Mojang liefert die API und stellt sicher, dass sie funktioniert.

Die geplante Minecraft-Plugin API wird als Ressourcenpaket realisiert werden. Ein Ressourcenpaket ist bereits ein Plugin, denn es erlaubt die Änderung von Texturen, Sounds, Sprache, Shadern und Konstruktionsmodellen durch Hinzufügung einer zip-Datei. Es gibt auch bereits eine API, denn nichts anderes sind die Befehle: Mit ihnen kann man auf Programmfunktionen zugreifen und z.B. Kreaturen erscheinen lassen, das Wetter verändern und Blockbereiche kopieren. Die NBT-Parameter einiger Befehle erlauben sogar schon den Zugriff auf einen Großteil der Minecraft-Daten, nämlich alle Blöcke, Gegenstände, Kreaturen und sonstige Objekte (Drops, Geschosse etc.). Es gibt mit JSON auch schon ein Datenformat, mit der ein programmierbarer Zugriff auf Minecraft von außen möglich ist. Man kann so z.B. Blocktexturen animieren oder neue Sounds hinzufügen. Was noch fehlt, ist eine Vervollständigung der Möglichkeiten und die Verknüpfung aller Elemente zu einem fertigen Ganzen.

Durch die Plugin API werden dem Spiel Veränderungen auf eine genau festgelegte Weise hinzugefügt werden können, was viele Vorteile hat:

• Die Installation von Veränderungen wird einfacher.
• Die Anpassung der Veränderungen an neue Minecraft-Versionen wird einfacher.
• Das Kernprogramm bleibt unverändert, sodass Mojang die Qualität bestimmen kann.
• Die Lizenzrechte der Firma werden nicht berührt.

Funktionen

Plugins sollen so einfach wie möglich zu finden, herunterzuladen und zu installieren sein. Die API wird nicht die selbe wie Bukkit sein.

Die folgenden Features sollen Teile der Plugin API werden:

• Plugins sind einzigartig gekennzeichnete Dateien im Minecraft-Installationsordner.
• Sie werden mit der Welt geladen. Das bedeutet, dass Plugins z.B. nicht das Hauptmenü oder die Spiel Engine selbst modifizieren können.
• Plugins werden kompatibel mit Mehrspieler-Servern sein und werden bei den Server-Informationen im Mehrspieler angezeigt.
• Mods (Plugins genannt) sollen einfacher und sicherer zu installieren sein.
• Die Webseite von Minecraft wird umstrukturiert, um interessante Community-Plugins und Welten hervorzuheben.
• Das Hinzufügen und die Animation von Modellen wird einfacher.
• Änderungen bezüglich der Speicherung der Spieldateien mit den vielen Materialien und Gegenständen.
• Plugins können über die offizielle Minecraft Repository oder über das Internet manuell heruntergeladen werden.
• In der Minecraft Repository können Plugins bewertet und gemeldet werden, dies soll vor schädlichen Plugins schützen.
• Plugin-Einstellungen basieren auf der jeweiligen Welt, jede Welt kann ihre eigenen Plugin Einstellungen haben.
• Wenn man Plugins ändert, muss man eventuell die Welt konvertieren.
• Plugins im Multiplayer werden in den Einstellungsdateien definiert.
• Wenn ein Spieler einen Server betritt, muss er das Plugin vorinstalliert haben oder es von der Minecraft Repository downloaden und installieren.
• Plugins müssen manuell aktualisiert werden - automatisches Updaten wird nicht möglich sein.
• Sie werden mit Java programmiert und müssen eine API Schnittstelle (Plugin API) implementieren, weitere Details sind noch unklar.
• Plugins können durch die Repository veröffentlicht werden, die Administrations-Seite dafür wird auf dev.minecraft.net sein. Dort können Updates und Changelogs hochgeladen werden. Das Entfernen von Updates wird nicht möglich sein.
• Über das offizielle Repository oder über das Spiel wird es nicht möglich sein, Plugins kostenpflichtig bereitzustellen; Alle Plugins werden darüber kostenlos zur Verfügung stehen und Plugin Entwickler werden auch kein Geld für das Veröffentlichen bekommen.
• Minecraft Vanilla soll selbst ein Plugin werden, so kann man z.B. bestimmte Funktionen deaktivieren.
• Plugins (auch Minecraft Vanilla selbst) werden eigene Ressourcenpakete mit eigener Musik, Geräusche, Sprachdateien, Credits, Splash-Texte und Schrift darstellen.

Auf der Minecon 2012 verkündete Mojang die Pläne für die Plugin API. Die volle (englische) Präsentation kann hier angeschaut werden:

Geschichte

Hier wird ein Überblick über die Entwicklung der Plugin API gegeben, der Schwerpunkt liegt dabei auf den tatsächlich durchgeführten Änderungen. Wer auch etwas über die im Laufe der Zeit veröffentlichten (und mittlerweile teilweise überholten) Pläne und Konzepte wissen möchte, kann sie in dieser ausführlichen Übersicht finden.

• Mit Veröffentlichung der ersten Mehrspielerversion Classic 0.0.15a im Juni 2009 entstanden die ersten gemoddeten Minecraft-Server. Notch reagierte und wies darauf hin, dass Modding okay sei, aber man dürfe nur die Mod selbst verbreiten, nicht das gemoddete Spiel. Kurz darauf erläuterte er seine Pläne bezüglich einer Modding-Unterstützung: "Ich werde eine Art Server-API veröffentlichen, damit man Plugins einfacher schreiben kann, als in den Datenfluss zwischen Client und Server einzugreifen. Die API wird solche Dinge zur Verfügung stellen, wie Blockplatzierungen, welche Blockart, Spielerbewegungen und Chateingaben. Die API wird es dann ermöglichen, Nachrichten zu senden, Spieler zu teleportieren, Blöcke zu setzen und wahrscheinlich auch die Welt zu laden und zu speichern."
• Ein Jahr später, als Notch seinen bisherigen Job gekündigt hatte und sich nun vollzeit der Weiterentwicklung von Minecraft widmete, griff er im Juli 2010 zu Beginn der Alpha-Versionen das Thema wieder auf: Er plante, dass Server-Funktionen beliebig zuschaltbar sein können (pluginable) und dies jedem möglich sein soll (open API). Man sollte seine eigenen Mods in Java schreiben und die Java-Klassendateien in den Server-Ordner stellen und dann über die server.properties dem Server mitteilen können, welche Mod er laden soll. Es sollte auch möglich sein, mehrere Mods zu laden.
• Im September 2010 (zu Zeiten von Alpha 1.1) erstellte eine unabhängige Gruppe von Programmierern - darunter Dinnerbone und Grum, die damals noch nicht bei Mojang waren - eine Minecraft-Mod namens hMod, die Minecraft-Server mit verbesserten Funktionen ausstattete. Wie jede Mod musste auch diese laufend an neue Minecraft Versionen angepasst werden. hMod wurde mit Beta 1.2 eingestellt.
• Mit der Alpha 1.2.2 (10. November 2010) wurde der neue Menüpunkt "Mods and Texture Packs" im Hauptmenü eingeführt, mit dem man dem Programm Mods und Texturenpakete hinzufügen können sollte. Allerdings funktionierte er nur für Texturenpakete.
• Im Dezember 2010 begann die Beta-Phase, in der das Spiel fertiggestellt werden sollte. Notch schrieb in seinem Blog: "Mit Beta wird das Spiel aufpoliert und es wird mehr Inhalt hinzugefügt. Wir werden früh damit beginnen, eine anständige Modding-Unterstützung einzubauen mit einer stabilen API und wir würden uns über jeden Vorschlag freuen, den wir von den Moddern da draußen bekommen können." Dieses Angebot nahmen einige ehemalige hMod-Programmierer (unter anderem Dinnerbone und Grum) wahr, die gerade dabei waren, unter dem Namen Bukkit eine neue Mod für Minecraft-Server zu entwickeln. Sie trafen sich mit Mojang-Mitarbeitern, um über die Modding-Unterstützung zu sprechen.
• Im April 2011 wurde der Fertigstellungstermin der ersten Vollversion auf Mitte November 2011 festgelegt und Notch machte sich genauere Gedanken über die API, die er bis dahin noch einbauen wollte: "Es werden bereits großartige Mods gemacht und es wird unmöglich sein, dass wir eine API zur Verfügung stellen können, die so gut und dynamisch sein wird, um all das zu unterstützen, was es bereits gibt. Ich möchte weiterhin unbedingt, dass Modding ein Teil von Minecraft ist, aber ich bin nicht davon überzeugt, dass der richtige Weg darin besteht, monatelang an einer API zu programmieren, die zum Schluss die Modder nicht überzeugen wird. Es gibt wahrscheinlich bessere Wege. Die Hauptprobleme sind, zu verhinden, dass jemand anderes unser Spiel verkaufen würde (außer er hat einen Lizenzvertrag mit uns) und sicherzustellen, dass Mods nicht mit jedem Spiel-Update neu geschrieben werden müssen."
• Am 26. April 2011 veröffentlichte Notch einen Plan zur Unterstützung von Mods: "Nach einigen internen Diskussionen und allgemeinen Bedenken haben wir einen Plan gefunden, um Mods zu unterstützen. Es ist noch ein bisschen vage und die Details könnte sich noch ändern, nachdem es unsere Rechtsanwälte bearbeitet haben, aber das haben wir vor:
  • Spieler können sich kostenlos als "Mod-Entwickler" eintragen lassen. Dabei stimmen sie einem Lizenzvertrag zu.
  • Mod-Entwickler können den Quellcode aus unserer Versionsverwaltung herunterladen. Sobald wir eine Änderung am Programm vornehmen, wird sie allen Mod-Entwicklern zur Verfügung stehen, unverschleiert und unzensiert.
  • Mod-Entwickler erhalten ein eindeutiges Zertifikat, um ihre Mods zu signieren. Das heißt, dass die Spieler genau sehen können, wer welche Mod gemacht hat und wählen können, welchem einzelnen Entwickler sie vertrauen wollen.
  • Die Lizenz wird folgende Regeln enthalten:
    • Mods dürfen nur von Spielern benutzt werden, die Minecraft gekauft haben.
    • Mods dürfen nicht verkauft oder anderweitig an ihnen verdient werden, außer man hat einen Lizenzvertrag mit uns.
    • Mods dürfen nicht schädlich sein (selbstverständlich).
    • Wir behalten uns das Recht vor, die Mod-Idee in das Spiel aufzunehmen. Diese Regel soll verhindern, dass wir eine bestimmte neue Funktion nur deshalb nicht ins Spiel bringen können, weil es irgendwo eine Mod gibt, die etwas Ähnliches macht. Außerdem können wir so Bugfixes ins Spiel nehmen, die von der Gemeinschaft kommen.

Auf lange Sicht hoffen wir, dass so viele atemberaubende neue Sachen mit Minecraft entstehen und damit gespielt wird. Wir haben vor, gute Mods zu kaufen oder zu lizensieren und sie selbst zu verkaufen. Wahrscheinlich wird es einen Marktplatz für Mods geben, wo man Mods verkaufen und kaufen kann, die Fans geschrieben haben oder wir kaufen und integrieren schöne Mods, die zum Minecraft -Konzept gut passen."

• Am 10. Juni 2011 hieß es: "Mit Beta 1.7 wird die Modding-Unterstützung in kleinem Rahmen beginnen. Wir werden den Quellcode vor der Veröffentlichung von Beta 1.7 einer sehr SEHR kleinen Gruppe von Mod-Entwicklern zur Verfügung stellen. Die Erfahrungen mit dieser Aktion lassen wir in die endgültigen Details zur Ausgestaltung einfließen. Dann werden wir die Modding-API so bald wie möglich nach der Beta 1.7 veröffentlichen."
• Doch am 15. November, drei Tage vor der Veröffentlichung des fertigen Spiels hieß es leider: "Die letzten Wochen waren unglaublich stressig und in vielerlei Hinsicht emotional aufwühlend und ich bin so erleichert, endlich eine fertige Minecraft-Version zu haben, die wir der Welt am Freitag präsentieren können. (...) Eine Sache, die uns irgendwie durch die Lappen gegangen ist, ist die Mod-Unterstützung. Das tut mir leid und ich übernehme die volle Verantwortung dafür, dass das vergessen wurde. Aber wenn der neue Launcher kommt, wird das Teil eines neuen, aufregenden Projektes sein, über das ich jetzt noch nicht sprechen kann."
• Mit Veröffentlichung der Vollversion 1.0 am 18. November 2011 hatte der Menüpunkt "Mods and Texture Packs" für Mods immer noch keine Funktion und wurde daher in "Texture Packs" umbenannt. Notch übergab die weitere Entwicklung von Minecraft in die Hände von Jeb. Dieser erklärte in einem Interview, dass seine absolute Hauptpriorität auf der Erstellung einer Mod API läge. In einem anderen Interview sagte er, dass die größte Herausforderung einer Mod API darin läge, dass die Modifikationen ohne Änderung des Minecraft-Programms möglich sein sollen. Obwohl er es noch nicht so genannt hatte, beschrieb er damit das Konzept einer Plugin API.
• Die Vollversion 1.1 (12. Januar 2012) enthielt eine neue Kommunikation zwischen Client und Server, die sogenannten Plugin Channels. Das löste das große Problem, sich mit einem beliebig modifizierten Client an einem beliebig anders modifizierten Server anzumelden, ohne dass das Spiel abstürzt. Das Konzept für die Plugin Channels wurde nicht von Mojang, sondern vom Bukkit-Team, das als Server-Mod-Hersteller sehr an einer Lösung interessiert war, mit Unterstützung von Mojang für Minecraft entwickelt. Version 1.1 war somit der erste von vielen Schritten zur Mod API.
• Mit der Vollversion 1.2 (12w07a) wird am 5. Februar 2012 das Anvil Format eingeführt, das unter anderem die maximale BlockID von 256 auf 4096 erhöht, womit genug Platz für zusätzliche Blöcke von Mods geschaffen wird.
• Einen Tag vor Veröffentlichung der Vollversion 1.2 (28. Februar 2012) verließen die vier Hauptentwickler von Bukkit (Dinnerbone, Grum, EvilSeph und Tahg) ihr Projekt und wechselten zu Mojang. Sie hatten die Aufgabe, den Vanilla Minecraft-Server genauso flexibel und vielseitig zu gestalten, wie er es mit der Bukkit-Mod war. Geplant war zuerst eine neue Mod API für Server, später soll dann auch das Modding auf Client-Seite unterstützt werden. Die offizielle Bezeichnung für die Mod API lautete nun Minecraft API.
• Bei Veröffentlichung der Vollversion 1.2.5 (1.2.5 Pre) (30. März 2012) verkündete Mojang, dass die Minecraft API mit Beteiligung der Minecraft-Community entwickelt werden sollte. Am 30. Juni war es dann soweit: im Minecraftforum fand eine öffentliche Diskussionsrunde statt. Eine Zusammenfassung der Ergebnisse wurde von Mojang-Mitarbeiter EvilSeph hier veröffentlicht.
• Mit der Vollversion 1.3 (12w18a) (3. Mai 12) wurde die Möglichkeit von Server-Texturenpaketen eingeführt. Ein Server-Texturenpaket konnte in den server.properties angegeben werden und wurde dem Client zum Download angeboten, falls er es nicht installiert hatte. Dieses Feature war ein weiterer Schritt zur Minecraft API.
• Mit der Vollversion 1.3 (12w27a) (5. Juli 2012) wurde im Hinblick auf die Minecraft API die bislang getrennt programmierte Einzel- und Mehrspielerversion von Minecraft zusammengefasst, damit man eine Mod nicht zwei Mal hinzufügen musste.
• In der Zeit der Veröffentlichung der Vollversion 1.3 (1.3 Pre) (26. Juli 2012) schrieb Dinnerbone die erste Java-Klasse für die Minecraft API und nannte sie Workbench.
• Mit Veröffentlichung der Vollversion 1.3 (1. August 2012) startete Mojang eine Webseite, auf der Vorschläge für die Minecraft API gesammelt werden konnten: Minecraft API Proposal System.
• Am zweiten Tag der Minecon 2012 (25. November 2012), kurz nach Veröffentlichung der Vollversion 1.4.5 verkündete Jeb in einer Präsentation die Pläne für die API, die nun offiziell Plugin API genannt wurde, weil man die Minecraft-Modifikationen ohne Änderung der Programmdatei hinzufügen (= plugin) können sollte. Auf die Entwicklung der Plugin API wird auch auf den aktuellen Hilfeseiten des Mojang Customer Support hingewiesen.
• Mit der Vollversion 1.5 (13w02a) (10. Januar 2013) wurden die Texturen für Gegenstände, die im Programm minecraft.jar bisher in gemeinsamen Dateien zusammengefasst waren (terrain.png und /gui/items.png) in einzelne Dateien aufgeteilt (in den Ordnern textures/blocks und /textures/items). Dadurch wurde die Änderung einer einzelnen Textur wesentlich vereinfacht. Gleichzeitig wurde die Animation von beweglichen Texturen aus dem Programm in den Texturenordner ausgelagert. Jetzt konnte man animierte Texturen ändern, ohne in den Programmcode eingreifen zu müssen. Außerdem konnten nun HD-Texturen mit höherer Auflösung als nur 16×16 Pixel erstellt werden.
• Mit der Vollversion 1.5 (13w03a) (17. Januar 2013) wurde der Menüpunkt für das Aktivieren von Texturenpaketen vom Hauptmenü in das Pausenmenü verschoben, wodurch man Texturenpakete jetzt während des Spiels aktivieren und deaktivieren konnte. Das war ein Schritt in die Richtung, dass Texturenpakete nicht mehr für das gesamt Spiel gelten sollten, sondern für jede einzelne Welt individuell hinzugeschaltet werden könnten.
• Mit der Vollversion 1.6 (13w16a) (18. April 2013) wurde ein neuer Launcher veröffentlicht, der den Weg für die Plugin API ebnete. Er erhielt kurz darauf einen "Local Version Editor", der alle Einstellungen zum Starten des Programms minecraft.jar anzeigte, die man in diesem ersten Schritt allerdings noch nicht ändern konnte. Gleichzeitig wurde die Ordnerstruktur der Standard-Ressourcen geändert, die ab jetzt assets (Bestandsdaten) genannt wurden:
  • Im Programm minecraft.jar wurden im /assets-Ordner neben den Texturen auch einige Texte (Splash-Texte, Epilog) und eine Datei für die Schriften hinterlegt.
  • Im .minecraft-Ordner wurden im /assets-Unterordner die Sounds und die aus minecraft.jar ausgelagerten Sprachendateien als Standard-Ressourcen zusammengestellt.

Das deutete an, dass man zukünftig alle diese Ressourcen ändern können wird.

• Mit der Vollversion 1.6 (13w24a) (13. Juni 2013) wurde der bisherige Menüpunkt zum Aktivieren von Texturenpaketen ersetzt durch das Menü/Optionen/Ressourcenpakete, mit dem man nun Ressourcenpakete während des Spiels aktivieren und deaktivieren konnte. Gleichzeitig bekamen die Ressourcenpakete eine Hierarchie, so dass man jetzt ein Mini-Ressourcenpaket zum Ändern einer einzigen Textur oder eines einzigen Sounds erstellen konnte. Die Einführung der Ressourcenpakete war ein großer Schritt Richtung Plugin API. Ein Minecraft-Ressourcenpaket ist eine Sammlung von Dateien, die ohne Veränderung des Programms hinzugefügt (= plugin) werden kann. Dinnerbone erklärte, dass zukünftig jede Mod (Programmmodifikation), jedes Plugin (Änderung ohne Programmmodifikation) und auch die Standard-Ressourcen von Minecraft als Ressourcenpaket behandelt werden würden. In diesem Zusammenhang wurde mit JSON ein strukturiertes Datenformat für Metadaten eingeführt. Teil der Plugin API sind also JSON-Dateien.
• Mit der Vollversion 1.7 (13w36a) (5. September 2013) wurden die ersten Befehle zur Verfügung gestellt, die NBT-Daten als Parameter enthalten konnten. Das war ein gewaltiger Schritt, denn die NBT-Daten sind nichts anderes, als sämtliche Daten des Spiels. Sie werden beim Speichern des Spiels in Dateien geschrieben. Mit Hilfe der NBT-Parameter konnte man jetzt ohne Mods auf Spielelemente zugreifen, die bislang nicht erreichbar waren (z.B. Riesen).
• Mit der Vollversion 1.7 (13w37a) (12. September 2013) wurden die ID-Namen eingeführt. Statt einer Zahl (1 für Stein) bekam jeder Gegenstand nun einen Namen (minecraft:stone), dem das Präfix "minecraft:" vorangestellt war, so dass man zukünftig mit anderen Präfixen im ID-Namen auch auf Gegenstände von Mods zugreifen können wird.
• Mit der Vollversion 1.7 (13w38a) (19. September 2013) wurden die Shader eingeführt. Zuerst war das nur eine einfache Sammlung von Grafikeffekten, ab Vollversion 1.8 (14w05a) wurden dann die ersten Shader im Spiel verwendet. Die Shader sind Teil der Standard-Ressourcen und können folglich über ein Ressourcenpaket geändert werden. Die zugehörige API besteht aus GLSL- (OpenGL Shader Language) und JSON-Dateien.
• Seit der Vollversion 1.7 (13w39b) (27. September 2013) weist Minecraft im Startbildschirm auf eine veraltete OpenGL-Version hin. Das Spiel wird zukünftig mit OpenGL 2.1 laufen, was eine der Voraussetzungen für die Plugin API ist.
• Große Teile der Vollversion 1.7 (1.7.2 Pre) (25. Oktober 2013) wurden als Vorbereitung für die Plugin API umgeschrieben. Das war mit ein Grund, warum das Update 1.7 den Namen The Update that changed the World trug.
• Auf der Minecon 2013 (2. November 2013), die kurz nach der Veröffentlichung der Vollversion 1.7 stattfand, wurden zwei neue Mojang-Mitarbeiter vorgestellt die die Arbeit an der Plugin API unterstützen sollen: Michael Stoyke, der das Minecraft Coder Pack entwickelt hat, und Ryan Holtz von der amerikanischen Spieleentwicklerfirma Bat Country Entertainment.
• Mit der Vollversion 1.8 (14w06a) (6. Februar 2014) wurden die Konstruktionsmodelle für die dreidimensionale Darstellung als Standard-Ressource ausgelagert. Das war wieder ein wichtiger Schritt für die Plugin API, denn nun konnte man - zunächst nur für Blöcke - erstmals ohne Programmänderung das dreidimensionale Aussehen von Spielelementen ändern. Mit einem Ressourcenpaket konnte man nun nicht nur fotorealistische HD-Texturen ins Spiel bringen, sondern auch z.B. die Rillen in Gemeißelten Steinziegeln plastisch darstellen.
• Mit der Vollversion 1.8 (14w07a) (14. Februar 2014) konnte man in einer Welt ein Welt-Ressourcenpaket integrieren. Damit konnte man z.B. Abenteuerwelten mit veränderten Ressourcen erstellen: Abenteuerwelten, die durch das Hinzufügen (= plugin) einer Datei modifiziert wurden. Außerdem wurde mit dieser Version das komplette Inventarsystem in Vorbereitung auf die Plugin API intern umgestellt: Gegenstände im Inventar konnten jetzt fremde NBT-Daten haben, die von Vanilla-Minecraft nicht beachtet wurden. Damit war es möglich geworden, Gegenständen Eigenschaften zu geben, die nicht von Minecraft, sondern von Plugins verarbeitet werden.
• Mit der Vollversion 1.8 (14w08a) (19. Februar 2014) wurden die Generierungscodes von Flachland-Welten auf ID-Namen umgestellt.
• Mit der Vollversion 1.8 (14w11a) (13. März 2014) wurde das Konzept des Blockzustands hinzugefügt. Damit wird für jeden Block festgelegt, welche Zustände er haben kann und wie sich diese optisch voneinander unterscheiden.
• Mit der Launcher-Version 1.4.2 (2. Mai 2014) wurde der "Local Version Editor", der bislang den Zusatz "NYI" (not yet implemented = noch nicht fertiggestellt) hatte, wieder entfernt.
• Mit der Vollversion 1.8 (14w25a) (18. Juni 2014) wurden die dreidimensionalen Konstruktionsmodelle auch für Gegenstände eingeführt (wenn man sie in der Hand hält oder als Drop).
• Mit der Vollversion 1.8 (14w26a) (25. Juni 2014) wurde der Welttyp Debug-Modus hinzugefügt, der alle Blöcke in allen Zuständen anzeigt, so dass man Änderungen an den Texturen oder Blockmodellen leicht testen kann.
• Mit der Vollversion 1.8 (14w28a) (9. Juli 2014) wurden ID-Namen auch für Statuseffekte und Verzauberungen eingeführt. Gleichzeitig wurde nach 5 Monaten die Arbeit an den Konstruktionsmodellen für abgeschlossen erklärt.
• Am 30. April 2015 präsentierte Microsoft das Minecraft Mod Developer Pack, einen neuen Zusatz für sein Entwicklungswerkzeug "Visual Studio", mit dem man Minecraft-Mods erstellen kann. Das führte zu einiger Verwirrung, weil es so schien, als ob damit die offizielle Mod-API veröffentlicht sei - immerhin ist Microsoft seit Ende 2014 der neue Eigentümer von Mojang und Minecraft. Doch Dinnerbone stellte klar, dass Mojang das Modden zwar duldet, aber nicht offiziell unterstützt. Der offizielle Weg wird die Plugin API sein, an der weiterhin gearbeitet würde. Auf die Frage, wo die Plugin API denn bleibe, antwortete Dinnerbone, dass man nicht etwas Unausgegorenes herausgeben, sondern es solange verbessern möchte, bis es wirklich gut ist.
• Mit der Vollversion 1.9 (15w43a) (21. Oktober 2015) wurden die bisher im Programm enthaltenen Regeln zur Generierung von Beute in Truhen, von getöteten Kreaturen und beim Angeln in Beutetabellen ausgelagert. Damit können nun Truhen mit beliebigem Inhalt und Kreaturen mit beliebigen Drops erzeugt werden, verknüpft mit Wahrscheinlichkeiten und Bedingungen.