Eigentlich sollte der Umstieg auf 1.17 nicht besonders aufwendig sein, wie hier beschrieben. Doch mit 1.17 gibt es bei Spigot ein neues Build-System, an das unsere Plugins angepasst werden müssen. Was das genau bedeutet, erklärt der folgende Text.
Servermods und Plugins
Spigot und das davon abgeleitete Paper, auf dem unsere Serversoftware basiert, sind Servermods, d. h. modifizierte Minecraft-Serverprogramme. Das Original-Minecraft-Serverprogramm ist nicht wirklich benutzbar. Für einen richtigen Serverbetrieb fehlen wichtige Funktionen. Die Servermods ermöglichen das Hinzufügen eigener Funktionen als sogenannte Plugins.
Wir haben ziemlich viele Plugins, eigene und fremde. Alle Befehle, die ihr auf dem Server nutzt, von /achievements bis /zone, sind als Plugin realisiert. Dazu kommen zahlreiche Serverteambefehle, WorldEdit, Dynmap, Minigames sowie weitere Funktionen im Hintergrund.
Quellcode, Zwischencode, Maschinencode
Ein Plugin muss erstmal programmiert werden. Das ist der Quellcode, den jeder Java-Programmierer lesen, verstehen, schreiben und ändern kann. Wir spielen mit der Java-Edition von Minecraft, unsere Plugins sind in der Programmiersprache Java geschrieben. Um ein fertiges Plugin benutzen zu können, muss es in maschinenlesbaren Code umgewandelt werden. Das passiert bei Java in zwei Schritten:
Die Bedrock-Edition hat keinen Zwischencode. Sie ist in C++ programmiert und wird für jede Plattform direkt in hochoptimierten Maschinencode kompiliert. Dies muss der Herausgeber tun. Er muss eine Vielzahl von Versionen für unterschiedliche Betriebssysteme vorhalten und beim Download die richtige ausliefern. So macht es Microsoft mit der Bedrock-Edition. Das ist für den Herausgeber wesentlich aufwendiger, aber weil der Zwischencode eingespart wird, ist das Spiel schneller.
Verschleierung und Mapping
Die Java-Edition hat für die Anwender außerdem den Riesenvorteil, dass sie relativ leicht modifizierbar ist. Dazu muss man "nur" den kompilierten Zwischencode dekompilieren. Damit das Spiel aber nicht kinderleicht kopiert und unter anderem Namen verkauft werden kann, hat Mojang den Zwischencode verschleiert (obfuscated).
Fun Fact: Der Minecraft-Vorgänger "Infiniminer" war ebenfalls ein Java-Programm und hatte diese Maßnahme 2009 einmal vergessen. Sofort wurde das Spiel vielfach kopiert und verändert. Daraufhin hatte der Entwickler das Spiel aufgegeben, sein Original war nur noch eine von vielen Alternativen. Einer dieser Kopisten hieß Notch und aus seiner Alternative entstand Minecraft.
Die Verschleierung ändert alle Namen (Klassen, Methoden und Felder) in nichtssagende, durchnummerierte Texte wie a1, a2, ab1, ab2. Ein verschleierter Zwischencode lässt sich auch mit bedeutungslosen Namen einwandfrei von der JRE ausführen. Wird der Zwischencode aber dekompiliert, bleibt das Ergebnis dem Leser inhaltlich unverständlich. Daher sind mit einem verschleierten Code nicht nur dreiste Kopien, sondern auch gut gemeinte Modifikationen (Mods) nicht möglich. Aber Mods waren in der Minecraft-Szene dringend erwünscht, nicht zuletzt, weil man mit dem Original-Serverprogramm keinen Server betreiben konnte, es fehlte einfach zu viel. Daher haben schon in der Anfangszeit, als das Spiel noch im Vergleich zu heute winzig klein war, einige Spieler in mühsehliger Kleinarbeit den verschleierten Quellcode analysiert und den Funktionen eigene Namen gegeben. Die Zuordnung von verschleierten Namen zu verständlichen Namen wird Mapping genannt. Nur mit einem Mapping konnten die ersten Mods entstehen, darunter auch die Servermod hMod mit den Nachfolgern Bukkit, Spigot und Paper.
Bei der Bedrock-Edition sind Mods, wie man sie von der Java-Edition kennt, nicht möglich, weil man aus dem Maschinencode nicht schließen kann, wie der Quellcode ursprünglich ausgesehen hat.
Modding
Bereits 2010 zu Zeiten der Version Alpha 0.2.1 entwickelten zwei Spieler das "Mod Coder Pack" (MCP, anfangs "Minecraft Coder Pack"), mit dem jeder Mod-Entwickler das Original-Minecraft-Programm dekompilieren und durch ein Mapping verständlich machen konnte, um es erweitern zu können. Fun Fact: Die beiden Spieler wurden später von Mojang eingestellt und sind als Entwickler Searge und ProfMobius bekannt.
Für Clients gibt es noch viel mehr Mods als für Server. Das bekannte OptiFine ist so eine Clientmod. Früher musste man das Originalspiel für jede Mod entschleieren, dekompilieren, verändern und neu kompilieren. Später haben einige Spieler Modloader wie Forge entwickelt, die Mods in das Spiel laden können, ohne das Originalspiel selbst neu kompilieren zu müssen. Auch diese Modloader arbeiten mit einem Mapping, um auf die Originalfunktionen zugreifen zu können.
2014 gab es eine entscheidende Änderung in der Modding-Community. Die monetäre Ausnutzung von Minecraft hatte mittlerweile unschöne Ausmaße angenommen. Immer mehr Eltern wollten Hunderte Dollars von Mojang zurück haben, die ihre Kinder auf Abzockservern verloren hatten. Mojang verwies auf die Lizenzbedingungen, die das Abzocken verbieten, formulierte diese nochmal deutlicher und setzte eine neue Abteilung zur Überwachung derselben ein, was es bis dahin nicht gegeben hatte. Daraufhin gab es einen Riesenaufschrei in der Modding-Community, denn Modden war nur mit dem Dekompilieren und Entschleiern des Originalspiels möglich, was streng genommen illegal war, auch wenn es von Mojang toleriert wurde.
Zum Umstieg auf 1.8 eskalierte das Thema beim Bukkit-Team. Bukkit war zu der Zeit die wichtigste Servermod, weil sie das Pluginsystem eingeführt hatte und damit sehr leicht erweiterbar war. Das Bukkit-Team wollte von Mojang eine offizielle Erlaubnis für ihre Servermod haben in Form einer Änderung der Lizenzbedingung. Das war so nicht möglich, woraufhin Bukkit die Weiterentwicklung beendete. Dadurch konnte vorerst weltweit kein Server auf 1.8 umsteigen, auch wir nicht. Nur Spigot (ein Bukkit-Klon) machte weiter und setzte auf die weiterhin inoffizielle Toleranz von Mojang.
Fun Fact: Vier Spieler, die die Servermod Bukkit entwickelt hatten, waren schon vor 2014 von Mojang eingestellt worden, zwei sind immer noch da (Dinnerbone und Grum).
Auch Searge machte mit dem MCP weiter und brachte mit jeder neuen Minecraft-Version eine aktualisierte MCP-Version heraus, weil ohne MCP kaum eine Mod-Entwicklung möglich war. Pikant daran ist die Tatsache, dass er für sein Mapping den Code entschleiern musste, was eigentlich illegal war, aber als Mitarbeiter von Mojang durfte er es, wobei das MCP jedoch nicht von Mojang kam, sondern weiterhin von ihm privat. Die meisten Modder interessierten sich jedoch nicht für solche juristischen Feinheiten.
Offizielles Mojang-Mapping
Das Ende des MCP kam mit Version 1.13. Mit dieser Version machte Minecraft erstmalig mehr als 256 Blöcke möglich, was die interne Programmierung so grundlegend geändert hat, dass die Aktualisierung des MCP zu aufwendig gewesen wäre. Ohne MCP konnten viele Mod-Entwickler und Server ihre Programme nicht auf 1.13 anpassen, sie blieben bei 1.12. Mojang konnte deutlich erkennen, dass auch nach längerer Zeit und nach Veröffentlichung der 1.14 viele Spieler bei 1.12 blieben. Die Modding-Community ist lebenswichtig für die Java Edition, das weiß Mojang. Daher veröffentlichte Mojang mit Version 1.15 erstmalig ein offizielles Mapping (rückwirkend auch für 1.14). In der Ankündigung hieß es:
"Um das Modden des Spiels zu erleichtern, haben wir uns entschieden, ab sofort und für alle zukünftigen Versionen unser Verschleierungs-Mapping zu veröffentlichen. Jeder, der daran interessiert ist, kann den verschleierten Quellcode nun entschleiern ohne monatelang selbst die Bedeutung des Codes herausfinden zu müssen. Wir hoffen, dass Entwickler von Mods, Servermods und Modloadern dieses Mapping zukünftig benutzen. Unser Mapping wird stets und sofort als Teil jeder neuen Version verfügbar sein. Das ändert aber nichts an den Einschränkungen, was man mit unserem Code machen oder nicht machen darf."
Lizenzbedingungen
Diese Einschränkungen sind in den Lizenzbedingungen formuliert. Die Formulierungen müssen rechtlich exakt sein, damit Nachahmer nicht einfach Minecraft kopieren und unter neuem Namen herausbringen können.
Die Verwendung des offiziellen Mappings verlief schleppend. Einige Modder benutzten es, aber langjährige Projekte wie der Modloader Forge oder die Servermod Spigot hatten längst ihr eigenes Mapping entwickelt und an jede neue Version angepasst. Auch die Programmierer von Forge-Mods oder Spigot-Plugins benutzten natürlich weiterhin die Forge- und Spigot-Mappings.
Zu der Zeit schlug die Ankündigung eines neuen Konkurrenten namens Hytale wie eine Bombe in die Minecraft-Community ein. Hytale hatte das Modding ganz oben auf seine Fahnen geschrieben. Im Gegensatz zu Minecraft, bei dem Modding immer noch umständlich und nur für Eingeweihte möglich ist, soll es bei Hytale offiziell und mit kostenlosen Tools unterstützt werden und kinderleicht sein.
Vielleicht war diese Ankündigung mit ein Grund, warum Mojang endlich seine Lizenzbedingungen änderte. Seither wird die Anwendung des offiziellen Mojang-Mappings nicht nur geduldet, sondern explizit gewünscht. Im Sommer 2020 twitterte der Mojang-Chefentwickler Dinnerbone: "Wir würden uns freuen, wenn Projekte das offizielle Mojang-Mapping benutzen würden, um die gesamte Modding-Community zusammenzubringen und den Austausch zu vereinfachen. Dazu gibt es eine Änderung der Lizenzbedingungen."
Vorher hieß es in den Mapping-Lizenzbedingungen: "Du darfst das Mapping für interne Zwecke kopieren und benutzen. Du erwirbst damit keinerlei Rechte." Der neue Text lautete: "Du darfst das Mapping für Entwicklungszwecke kopieren und benutzen, aber du darfst es nicht komplett und unverändert weitergeben. Die Bedingungen für das Modifizieren der Minecraft Java Edition wird von der Endbenutzer-Lizenzvereinbarung (EULA) abgedeckt."
In besagter EULA steht zum Modding: "Wenn Sie das Spiel erworben haben, dürfen Sie damit herumspielen und es ändern, indem Sie Modifikationen, Tools oder Plug-Ins hinzufügen, die wir zusammen als "Mods" bezeichnen. Der Begriff "Mod" bezeichnet ein Originalwerk von Ihnen oder jemand anderem, das keinen wesentlichen Teil unseres urheberrechtlich geschützten Codes oder Inhalts enthält. Wenn Sie Ihre Mod mit der Minecraft-Software kombinieren, nennen wir diese Kombination eine "modifizierte Version" des Spiels. Was eine Mod ist und was nicht, bestimmen letzten Endes wir. Sie sind nicht berechtigt, modifizierte Versionen unseres Spiels oder unserer Software zu verteilen, und wir wären Ihnen dankbar, wenn Sie Mods nicht zum Griefing verwenden würden. Grundsätzlich gilt, dass Mods verteilt werden dürfen, jedoch gehackte Versionen oder modifizierte Versionen der Client- oder Serversoftware des Spiels nicht verteilt werden dürfen."
Modifizierte Versionen des Spiels
Vereinfacht gesagt bedeutet das, Mod-Anbieter dürfen keine modifizierten Minecraft-Versionen anbieten, sondern nur Zusätze, mit denen die Nutzer ihre legal erworbene Minecraft-Version selbst verändern. Technisch gibt es dazu unterschiedliche Ansätze:
Die Änderung der Lizenzbedingung war eine erfreuliche Entwicklung für die Modding-Community und der Wunsch wuchs, dass auch große Projekte wie Forge und Spigot auf das Mojang-Mapping umsteigen. Dies wird nun bei Spigot mit 1.17 geschehen.
Der Spigot Chefentwickler md_5 schreibt dazu, dass die Namen der Minecraft-Originalfunktionen in der neuesten Spigot-Version nicht mehr wie früher durch das Spigot-Mapping lesbar enthalten sein werden, sondern in der originalen verschleierten Form. "Das ist ein entscheidender Schritt in dem lange gewünschten Umstieg zum sogenannten Mojang-Mapping für die Weiterentwicklung von Spigot."
Damit Unlimitedworld auf 1.17 umsteigen kann, benötigen wir die 1.17-Version der Servermod Paper, die auf der 1.17-Version von Spigot beruht. Und um diese benutzen zu können, müssen wir unser Build-System umstellen.
Build-System
Ein Build-System baut Quellcode-Dateien, verschiedene Funktionsbibliotheken und weitere Dateien nach vorgegebenen Regeln zu einem ausführbaren Programm zusammen. Dabei werden JAVA-Dateien (Quellcode) kompiliert und in einer JAR-Datei (Java Archive) gespeichert. Andere Dateien, wie z. B. Bilder oder Texte, werden direkt in der JAR-Datei gespeichert. So entsteht aus vielen Einzeldateien im Ergebnis eine JAR-Datei, die mit der Java-Laufzeitumgebung (JRE) ausgeführt werden kann.
Wir haben zwei Arten von ausführbaren Programmen, die unterschiedlich zusammengebaut werden: Serversoftware und Plugins.
Auch Java selbst wird ständig weiterentwickelt. Minecraft wurde bisher mit der Java-Version 8 programmiert, ab Version 1.17 wird die Java-Version 16 verwendet. Mit diesem Umstieg ist einiges neu und einiges anders. Auch dies muss in unserem Build-System beachtet werden.
Fazit
Wir müssen für unsere Plugins das Build-System Maven an das Mojang-Mapping anpassen, wir müssen zusätzlich das Build-System Gradle einsetzen, um die Serversoftware zusammenzubauen und wir müssen alle Probleme beseitigen, die die Umstellung auf Java 16 mit sich bringen. Daher dauert der Umstieg auf 1.17 etwa zwei Wochen länger, als ursprünglich gedacht. Immerhin sind erste Zwischenergebnisse erfolgreich, wir halten euch weiterhin auf dem Laufenden.
Vielen Dank an unseren Dev @BlackHole, der mir den Input zu diesem Text gegeben hat.
Servermods und Plugins
Spigot und das davon abgeleitete Paper, auf dem unsere Serversoftware basiert, sind Servermods, d. h. modifizierte Minecraft-Serverprogramme. Das Original-Minecraft-Serverprogramm ist nicht wirklich benutzbar. Für einen richtigen Serverbetrieb fehlen wichtige Funktionen. Die Servermods ermöglichen das Hinzufügen eigener Funktionen als sogenannte Plugins.
Wir haben ziemlich viele Plugins, eigene und fremde. Alle Befehle, die ihr auf dem Server nutzt, von /achievements bis /zone, sind als Plugin realisiert. Dazu kommen zahlreiche Serverteambefehle, WorldEdit, Dynmap, Minigames sowie weitere Funktionen im Hintergrund.
Quellcode, Zwischencode, Maschinencode
Ein Plugin muss erstmal programmiert werden. Das ist der Quellcode, den jeder Java-Programmierer lesen, verstehen, schreiben und ändern kann. Wir spielen mit der Java-Edition von Minecraft, unsere Plugins sind in der Programmiersprache Java geschrieben. Um ein fertiges Plugin benutzen zu können, muss es in maschinenlesbaren Code umgewandelt werden. Das passiert bei Java in zwei Schritten:
- Der Herausgeber wandelt den Quellcode in einen Zwischencode um. Das wird Kompilieren genannt. Ausgeliefert wird der Zwischencode.
- Der Anwender bekommt den Zwischencode und startet eine Java-Laufzeitumgebung (Java Runtime Environement JRE), die den Zwischencode in einen optimierten Maschinencode für die jeweilige Plattform übersetzt und ausführt. Früher musste man Java selbst auf seinem Computer installieren, um Minecraft spielen zu können. Weil das aber viele Spieler überfordert hat und immer wieder zu Fehlern führte, wird die JRE mittlerweile von Minecraft mitgeliefert und beim Start des Spiels vom Launcher automatisch mitgestartet (Prozess OpenJDK Platform binary).
Die Bedrock-Edition hat keinen Zwischencode. Sie ist in C++ programmiert und wird für jede Plattform direkt in hochoptimierten Maschinencode kompiliert. Dies muss der Herausgeber tun. Er muss eine Vielzahl von Versionen für unterschiedliche Betriebssysteme vorhalten und beim Download die richtige ausliefern. So macht es Microsoft mit der Bedrock-Edition. Das ist für den Herausgeber wesentlich aufwendiger, aber weil der Zwischencode eingespart wird, ist das Spiel schneller.
Verschleierung und Mapping
Die Java-Edition hat für die Anwender außerdem den Riesenvorteil, dass sie relativ leicht modifizierbar ist. Dazu muss man "nur" den kompilierten Zwischencode dekompilieren. Damit das Spiel aber nicht kinderleicht kopiert und unter anderem Namen verkauft werden kann, hat Mojang den Zwischencode verschleiert (obfuscated).
Fun Fact: Der Minecraft-Vorgänger "Infiniminer" war ebenfalls ein Java-Programm und hatte diese Maßnahme 2009 einmal vergessen. Sofort wurde das Spiel vielfach kopiert und verändert. Daraufhin hatte der Entwickler das Spiel aufgegeben, sein Original war nur noch eine von vielen Alternativen. Einer dieser Kopisten hieß Notch und aus seiner Alternative entstand Minecraft.
Die Verschleierung ändert alle Namen (Klassen, Methoden und Felder) in nichtssagende, durchnummerierte Texte wie a1, a2, ab1, ab2. Ein verschleierter Zwischencode lässt sich auch mit bedeutungslosen Namen einwandfrei von der JRE ausführen. Wird der Zwischencode aber dekompiliert, bleibt das Ergebnis dem Leser inhaltlich unverständlich. Daher sind mit einem verschleierten Code nicht nur dreiste Kopien, sondern auch gut gemeinte Modifikationen (Mods) nicht möglich. Aber Mods waren in der Minecraft-Szene dringend erwünscht, nicht zuletzt, weil man mit dem Original-Serverprogramm keinen Server betreiben konnte, es fehlte einfach zu viel. Daher haben schon in der Anfangszeit, als das Spiel noch im Vergleich zu heute winzig klein war, einige Spieler in mühsehliger Kleinarbeit den verschleierten Quellcode analysiert und den Funktionen eigene Namen gegeben. Die Zuordnung von verschleierten Namen zu verständlichen Namen wird Mapping genannt. Nur mit einem Mapping konnten die ersten Mods entstehen, darunter auch die Servermod hMod mit den Nachfolgern Bukkit, Spigot und Paper.
Bei der Bedrock-Edition sind Mods, wie man sie von der Java-Edition kennt, nicht möglich, weil man aus dem Maschinencode nicht schließen kann, wie der Quellcode ursprünglich ausgesehen hat.
Modding
Bereits 2010 zu Zeiten der Version Alpha 0.2.1 entwickelten zwei Spieler das "Mod Coder Pack" (MCP, anfangs "Minecraft Coder Pack"), mit dem jeder Mod-Entwickler das Original-Minecraft-Programm dekompilieren und durch ein Mapping verständlich machen konnte, um es erweitern zu können. Fun Fact: Die beiden Spieler wurden später von Mojang eingestellt und sind als Entwickler Searge und ProfMobius bekannt.
Für Clients gibt es noch viel mehr Mods als für Server. Das bekannte OptiFine ist so eine Clientmod. Früher musste man das Originalspiel für jede Mod entschleieren, dekompilieren, verändern und neu kompilieren. Später haben einige Spieler Modloader wie Forge entwickelt, die Mods in das Spiel laden können, ohne das Originalspiel selbst neu kompilieren zu müssen. Auch diese Modloader arbeiten mit einem Mapping, um auf die Originalfunktionen zugreifen zu können.
2014 gab es eine entscheidende Änderung in der Modding-Community. Die monetäre Ausnutzung von Minecraft hatte mittlerweile unschöne Ausmaße angenommen. Immer mehr Eltern wollten Hunderte Dollars von Mojang zurück haben, die ihre Kinder auf Abzockservern verloren hatten. Mojang verwies auf die Lizenzbedingungen, die das Abzocken verbieten, formulierte diese nochmal deutlicher und setzte eine neue Abteilung zur Überwachung derselben ein, was es bis dahin nicht gegeben hatte. Daraufhin gab es einen Riesenaufschrei in der Modding-Community, denn Modden war nur mit dem Dekompilieren und Entschleiern des Originalspiels möglich, was streng genommen illegal war, auch wenn es von Mojang toleriert wurde.
Zum Umstieg auf 1.8 eskalierte das Thema beim Bukkit-Team. Bukkit war zu der Zeit die wichtigste Servermod, weil sie das Pluginsystem eingeführt hatte und damit sehr leicht erweiterbar war. Das Bukkit-Team wollte von Mojang eine offizielle Erlaubnis für ihre Servermod haben in Form einer Änderung der Lizenzbedingung. Das war so nicht möglich, woraufhin Bukkit die Weiterentwicklung beendete. Dadurch konnte vorerst weltweit kein Server auf 1.8 umsteigen, auch wir nicht. Nur Spigot (ein Bukkit-Klon) machte weiter und setzte auf die weiterhin inoffizielle Toleranz von Mojang.
Fun Fact: Vier Spieler, die die Servermod Bukkit entwickelt hatten, waren schon vor 2014 von Mojang eingestellt worden, zwei sind immer noch da (Dinnerbone und Grum).
Auch Searge machte mit dem MCP weiter und brachte mit jeder neuen Minecraft-Version eine aktualisierte MCP-Version heraus, weil ohne MCP kaum eine Mod-Entwicklung möglich war. Pikant daran ist die Tatsache, dass er für sein Mapping den Code entschleiern musste, was eigentlich illegal war, aber als Mitarbeiter von Mojang durfte er es, wobei das MCP jedoch nicht von Mojang kam, sondern weiterhin von ihm privat. Die meisten Modder interessierten sich jedoch nicht für solche juristischen Feinheiten.
Offizielles Mojang-Mapping
Das Ende des MCP kam mit Version 1.13. Mit dieser Version machte Minecraft erstmalig mehr als 256 Blöcke möglich, was die interne Programmierung so grundlegend geändert hat, dass die Aktualisierung des MCP zu aufwendig gewesen wäre. Ohne MCP konnten viele Mod-Entwickler und Server ihre Programme nicht auf 1.13 anpassen, sie blieben bei 1.12. Mojang konnte deutlich erkennen, dass auch nach längerer Zeit und nach Veröffentlichung der 1.14 viele Spieler bei 1.12 blieben. Die Modding-Community ist lebenswichtig für die Java Edition, das weiß Mojang. Daher veröffentlichte Mojang mit Version 1.15 erstmalig ein offizielles Mapping (rückwirkend auch für 1.14). In der Ankündigung hieß es:
"Um das Modden des Spiels zu erleichtern, haben wir uns entschieden, ab sofort und für alle zukünftigen Versionen unser Verschleierungs-Mapping zu veröffentlichen. Jeder, der daran interessiert ist, kann den verschleierten Quellcode nun entschleiern ohne monatelang selbst die Bedeutung des Codes herausfinden zu müssen. Wir hoffen, dass Entwickler von Mods, Servermods und Modloadern dieses Mapping zukünftig benutzen. Unser Mapping wird stets und sofort als Teil jeder neuen Version verfügbar sein. Das ändert aber nichts an den Einschränkungen, was man mit unserem Code machen oder nicht machen darf."
Lizenzbedingungen
Diese Einschränkungen sind in den Lizenzbedingungen formuliert. Die Formulierungen müssen rechtlich exakt sein, damit Nachahmer nicht einfach Minecraft kopieren und unter neuem Namen herausbringen können.
Die Verwendung des offiziellen Mappings verlief schleppend. Einige Modder benutzten es, aber langjährige Projekte wie der Modloader Forge oder die Servermod Spigot hatten längst ihr eigenes Mapping entwickelt und an jede neue Version angepasst. Auch die Programmierer von Forge-Mods oder Spigot-Plugins benutzten natürlich weiterhin die Forge- und Spigot-Mappings.
Zu der Zeit schlug die Ankündigung eines neuen Konkurrenten namens Hytale wie eine Bombe in die Minecraft-Community ein. Hytale hatte das Modding ganz oben auf seine Fahnen geschrieben. Im Gegensatz zu Minecraft, bei dem Modding immer noch umständlich und nur für Eingeweihte möglich ist, soll es bei Hytale offiziell und mit kostenlosen Tools unterstützt werden und kinderleicht sein.
Vielleicht war diese Ankündigung mit ein Grund, warum Mojang endlich seine Lizenzbedingungen änderte. Seither wird die Anwendung des offiziellen Mojang-Mappings nicht nur geduldet, sondern explizit gewünscht. Im Sommer 2020 twitterte der Mojang-Chefentwickler Dinnerbone: "Wir würden uns freuen, wenn Projekte das offizielle Mojang-Mapping benutzen würden, um die gesamte Modding-Community zusammenzubringen und den Austausch zu vereinfachen. Dazu gibt es eine Änderung der Lizenzbedingungen."
Vorher hieß es in den Mapping-Lizenzbedingungen: "Du darfst das Mapping für interne Zwecke kopieren und benutzen. Du erwirbst damit keinerlei Rechte." Der neue Text lautete: "Du darfst das Mapping für Entwicklungszwecke kopieren und benutzen, aber du darfst es nicht komplett und unverändert weitergeben. Die Bedingungen für das Modifizieren der Minecraft Java Edition wird von der Endbenutzer-Lizenzvereinbarung (EULA) abgedeckt."
In besagter EULA steht zum Modding: "Wenn Sie das Spiel erworben haben, dürfen Sie damit herumspielen und es ändern, indem Sie Modifikationen, Tools oder Plug-Ins hinzufügen, die wir zusammen als "Mods" bezeichnen. Der Begriff "Mod" bezeichnet ein Originalwerk von Ihnen oder jemand anderem, das keinen wesentlichen Teil unseres urheberrechtlich geschützten Codes oder Inhalts enthält. Wenn Sie Ihre Mod mit der Minecraft-Software kombinieren, nennen wir diese Kombination eine "modifizierte Version" des Spiels. Was eine Mod ist und was nicht, bestimmen letzten Endes wir. Sie sind nicht berechtigt, modifizierte Versionen unseres Spiels oder unserer Software zu verteilen, und wir wären Ihnen dankbar, wenn Sie Mods nicht zum Griefing verwenden würden. Grundsätzlich gilt, dass Mods verteilt werden dürfen, jedoch gehackte Versionen oder modifizierte Versionen der Client- oder Serversoftware des Spiels nicht verteilt werden dürfen."
Modifizierte Versionen des Spiels
Vereinfacht gesagt bedeutet das, Mod-Anbieter dürfen keine modifizierten Minecraft-Versionen anbieten, sondern nur Zusätze, mit denen die Nutzer ihre legal erworbene Minecraft-Version selbst verändern. Technisch gibt es dazu unterschiedliche Ansätze:
- Forge-Mods kann man einfach in einen bestimmten Ordner kopieren und Forge starten. Forge lädt das vom Anwender gekaufte Originalspiel in den Arbeitsspeicher, verändert es dort und lädt alle Forge-Mods aus dem Ordner dazu.
- OptiFine verändert das Originalspiel einmalig während der Installation und erzeugt eine modifizierte Version. Damit hat nicht der Mod-Anbieter, sondern der Spieler selbst sein gekauftes Spiel verändert.
- Spigot und Paper stellen Werkzeuge zur Verfügung, um einen Server selbst zusammenzustellen. Bei Spigot muss man alles selbst kompilieren, Paper liefert eine Datei mit den Änderungen zum originalen Server mit. Spigot und Paper erzeugen mit dem gekauften Spiel eine modifizierte Serverversion, die Plugins laden und ausführen kann. Spigot- und Paper-Plugins kopiert man als Serverbetreiber ebenfalls in bestimmte Ordner.
Die Änderung der Lizenzbedingung war eine erfreuliche Entwicklung für die Modding-Community und der Wunsch wuchs, dass auch große Projekte wie Forge und Spigot auf das Mojang-Mapping umsteigen. Dies wird nun bei Spigot mit 1.17 geschehen.
Der Spigot Chefentwickler md_5 schreibt dazu, dass die Namen der Minecraft-Originalfunktionen in der neuesten Spigot-Version nicht mehr wie früher durch das Spigot-Mapping lesbar enthalten sein werden, sondern in der originalen verschleierten Form. "Das ist ein entscheidender Schritt in dem lange gewünschten Umstieg zum sogenannten Mojang-Mapping für die Weiterentwicklung von Spigot."
Damit Unlimitedworld auf 1.17 umsteigen kann, benötigen wir die 1.17-Version der Servermod Paper, die auf der 1.17-Version von Spigot beruht. Und um diese benutzen zu können, müssen wir unser Build-System umstellen.
Build-System
Ein Build-System baut Quellcode-Dateien, verschiedene Funktionsbibliotheken und weitere Dateien nach vorgegebenen Regeln zu einem ausführbaren Programm zusammen. Dabei werden JAVA-Dateien (Quellcode) kompiliert und in einer JAR-Datei (Java Archive) gespeichert. Andere Dateien, wie z. B. Bilder oder Texte, werden direkt in der JAR-Datei gespeichert. So entsteht aus vielen Einzeldateien im Ergebnis eine JAR-Datei, die mit der Java-Laufzeitumgebung (JRE) ausgeführt werden kann.
Wir haben zwei Arten von ausführbaren Programmen, die unterschiedlich zusammengebaut werden: Serversoftware und Plugins.
- Unsere Serversoftware basiert auf der Servermod Paper mit vielen eigenen Anpassungen. Paper verwendet als Build-System neuerdings Gradle mit einem speziellen Plugin, das das Original-Minecraft-Serverprogramm dekompiliert, verändert und als modifizierte Serverversion neu kompiliert. Dabei werden die notwendigen Mappings in beide Richtungen angewendet und viele andere Dinge erledigt. Für unsere Serversoftware müssen wir also ab jetzt auch Gradle verwenden.
- Unsere Plugins bauen wir wie bisher mit dem Build-System Maven zusammen. Das Original-Minecraft-Serverprogramm wird dabei nicht integriert, die Plugins greifen zur Laufzeit über eine Schnittstelle (Application Programming Interface API) der Serversoftware auf die benötigten Funktionen zu. Das bedeutet eine wesentliche Vereinfachung im Build-Prozess von Plugins und macht auch die Anwendung ganz leicht: Einfach Plug and Play (= in einen bestimmten Ordner kopieren und die Serversoftware starten ohne diese neu zusammenbauen zu müssen).
Die API, die die Serversoftware für die Plugins zur Verfügung stellt, enthält absichtlich keine Bestandteile von Mojang, damit die Quellcodes der Servermods von jedem legal benutzt werden können. Einige Plugins greifen ohne API direkt auf interne Minecraft-Funktionen zu, was auch möglich ist. Dazu muss jetzt aber das Mojang-Mapping verwendet werden.
Auch Java selbst wird ständig weiterentwickelt. Minecraft wurde bisher mit der Java-Version 8 programmiert, ab Version 1.17 wird die Java-Version 16 verwendet. Mit diesem Umstieg ist einiges neu und einiges anders. Auch dies muss in unserem Build-System beachtet werden.
Fazit
Wir müssen für unsere Plugins das Build-System Maven an das Mojang-Mapping anpassen, wir müssen zusätzlich das Build-System Gradle einsetzen, um die Serversoftware zusammenzubauen und wir müssen alle Probleme beseitigen, die die Umstellung auf Java 16 mit sich bringen. Daher dauert der Umstieg auf 1.17 etwa zwei Wochen länger, als ursprünglich gedacht. Immerhin sind erste Zwischenergebnisse erfolgreich, wir halten euch weiterhin auf dem Laufenden.
Vielen Dank an unseren Dev @BlackHole, der mir den Input zu diesem Text gegeben hat.
NACHTRAG: Die Umstellung des Build-Systems war erfolgreich, der nachfolgende Umstieg auf 1.17 auch.
Zuletzt bearbeitet:
