Start › Wiki › Eigene Items und das Resource Pack

Eigene Items und das Resource Pack

Die 209 registrierten Custom-Items, die Oberflächen, die ihnen standardmäßig verschlossen sind, die Custom-Blöcke, die der Garten mitgebracht hat, und das Resource Pack, das allem davon Modelle gibt.

Was die Registry enthält

Jedes Item auf dem Server, das nicht rein vanilla ist, ist eine Zeile in einer einzigen Registry. Sie enthält 209 Einträge. Davon sind 129 baubar: das Plugin kann jederzeit ein frisches Exemplar aus einer Factory erzeugen, worauf der Admin-Shop-Katalog, die Starterkits und die Essenslinie alle aufbauen. Die restlichen 80 sind reine Metadaten-Einträge. Sie haben keine Factory, und eine Bauanfrage an die Registry liefert nichts zurück.

Diese Aufteilung ist eine Entwurfsentscheidung, kein Versäumnis. Ein geschmiedetes Langschwert ist ein Objekt pro Exemplar: es trägt eigene Werte, eigene Sockel, eigene Runen und eine eigene eindeutige Id, es gibt also kein einziges kanonisches Exemplar zum Ausgeben. Edelsteine, Runensteine, Geldscheine und Barren sind aus einem noch schärferen Grund reine Metadaten-Einträge: eine Factory würde es der kanonischen Namens- und Lore-Auffrischung erlauben, den aufgedruckten Wert eines echten Scheins durch einen Beispielwert zu ersetzen. Der Schein würde weiterhin korrekt eingelöst, aber er würde im Inventar über sich selbst lügen. Die Registrierung als reiner Metadaten-Eintrag beseitigt das Problem vollständig und schließt zugleich einen Weg zu Gratis-Items.

Identität

Die Identität eines Items ist ein persistentes Datenfeld, custom_item_id, das in den Stapel geschrieben wird. Der ältere Custom-Model-Data-String bleibt als dauerhafter, nur lesbarer Rückfallweg erhalten, und Items wandern träge auf das Feld um, sobald sie eine Lesestelle passieren. Zwei Dinge werden nie überschrieben:

• Alles, was das Feld bereits trägt. Die Id eines geschmiedeten Items ist pro Exemplar eindeutig, etwa bl_longsword_emma_a1b2c3d4, und der Runengravierer, der Sockelhandler und die Verzauberungsstation lesen sie direkt. Sie mit einer Typ-Id zu überschreiben würde das Item für jedes dieser Systeme unkenntlich machen.
• Eine Registry-Id, die vom deklarierten Feldwert abweicht. Das Riss-Erzfragment trägt bl_rift_ore_fragment, registriert sich aber unter blacklight:bl_rift_ore_fragment; die Id zu schreiben würde ein korrektes Feld durch eine andere Zeichenkette ersetzen.

Rezepte, die ein Custom-Item als Zutat nehmen, deklarieren beide Formen, das alte Muster und das getaggte, damit während der Umstellung nichts aufhört zu passen. Der Preis der trägen Umstellung wird offen genannt: Items in nicht geladenen Chunks, in Inventaren offline gegangener Spieler, in Endertruhen, Shulkerkisten, Rahmen, Gräbern, Markt- und Shop-Angeboten, Firmenregalen und im NPC-Transport werden nur dann umgestellt, wenn sie angefasst werden. Der alte Lesepfad ist deshalb dauerhaft. Er ist nicht zur Abschaltung vorgesehen.

Der Archetyp wird deklariert, nie geraten

Jedes Custom-Item basiert auf einem Vanilla-Grundmaterial, denn das ist es, was es überhaupt darstellbar macht. Das Grundmaterial ist eine Darstellungsentscheidung. Wofür das Item gedacht ist, ist eine getrennte, verpflichtende, von Hand geschriebene Deklaration namens Archetyp, und sie wird nie aus dem Grundmaterial abgeleitet.

Der Grund ist eine Fehlerklasse, die dreimal ausgeliefert wurde. Getrockneter Cannabis war essbar, weil DRIED_KELP essbar ist. Der Schmiedehammer ließ sich zu Klumpen einschmelzen, weil IRON_AXE das tut. Das Hanfblatt wurde zu getrocknetem Seetang gekocht, weil KELP das tut. In jedem Fall erbte das Item ein Verhalten, das niemand wollte, von einem Material, das wegen seiner Textur gewählt worden war.

Alle 209 Registrierungen deklarieren einen von achtzehn Archetypen.

Der Archetyp ist eine andere Achse als die Katalogkategorie. Die Kategorie hat elf Werte und beantwortet die Frage "aus welchem Teilsystem stammt das"; sie steuert den Shop-Katalog und den Pack-Generator. Der Archetyp beantwortet die Frage "was tut das". Eine Riss-Scherbe ist Kategorie Riss und Archetyp Material; ein Ruinenschlüssel ist Kategorie Ruine und Archetyp Schlüssel, und beides behält er auch jetzt, da er stillgelegt ist. Eine der beiden aus der anderen abzuleiten würde Items in beiden stillschweigend umsortieren, also bleiben sie unabhängig, und eine Startprüfung stellt sicher, dass die Paarung sich nicht widerspricht.

Zwei dieser elf Werte sind Überbleibsel, die eine Erwähnung verdienen, denn sie sind der Grund, warum die Zahl weiterhin elf lautet. Die Kategorie, die einst die Dungeon-Linie beschriftete, hat deren Entfernung überlebt, weil vier darunter abgelegte Items stattdessen zur Sternnavigation und zur Kartografie gehören: die Sternkarte, das Astrolabium, die Kartografenfeder und die Wegmarke. Die Konstante zu löschen hätte vier lebende Items zugleich im Shop-Katalog und im Pack stillschweigend umsortiert. Die Regel, die das entschieden hat, lautet: zähle die Registrierungen, die übrig bleiben, und behalte die Konstante, wenn auch nur eine davon übrig ist. Über die Kategorie Ruine wurde genauso entschieden: Update 2.0.1 hat die Alten Ruinen entfernt, sechs darunter abgelegte Registrierungen haben sie überdauert, also blieb die Konstante.

Die Ruinen-Registrierungen, und was jede davon heute ist

Das Teilsystem, aus dem diese Items stammen, ist weg. Die Registrierungen sind es nicht, und diese Hälfte ist Absicht: eine Id, die die Registry vergessen hat, macht aus einem gehaltenen Item einen namenlosen Klumpen mit fremdem Namen. Wenn eines davon in deiner Truhe liegt, ist es heute das hier.

Die letzten vier sind Andenken und werden nicht zurückgekauft, denn keines davon wurde je gekauft, es gibt also nichts zurückzugeben. Ein Rechtsklick im Schleichen in die Luft sagt genau das und nennt den Schlüssel als das Stück, das sich verkaufen lässt.

Die 21 Oberflächen, an denen ein Item verbraucht wird

Es gibt in Minecraft 21 Stellen, an denen ein Item verbraucht, umgewandelt oder weggegeben wird. Alle 21 sind für ein Custom-Item standardmäßig gesperrt. Ein Archetyp muss sich einzeln dafür anmelden. Die Begründung ist asymmetrisch, und genau darin liegt das Argument: eine Oberfläche zu verweigern kostet nichts, eine versehentlich erlaubte zerstört das Item entweder oder wandelt es in etwas um, das die Wirtschaft nie bepreist hat.

Eine zweiundzwanzigste standardmäßig gesperrte Oberfläche kam später dazu: BLOCK_TRANSFORM, der blockverändernde Rechtsklick, den ein Grundmaterial mitbringt. Umgraben, Weg anlegen, Feuer löschen, entrinden, abkratzen, entwachsen, scheren und entzünden sind acht verschiedene Aktionen, und sechs davon lösen kein eigenes Ereignis aus, also teilen sie sich einen Angelpunkt und werden einmal statt achtmal benannt. Nur der Werkzeug-Archetyp öffnet sie, weshalb eine Anbauhacke umgraben kann, ein auf einem Goldblock gebauter Geldschein aber nicht.

Die sechs Oberflächen, die umgekehrt funktionieren

Sechs Oberflächen sind großzügig voreingestellt und müssen einzeln abgewählt werden: mit einem Block interagieren, mit einem Wesen interagieren, Nahkampf, Geschosse, Haltbarkeitsverlust und das Tragen als Rüstung. Diese zu verweigern schützt das Item nicht, es macht es kaputt. Ein pauschales Blockverbot hieße, dass du keine Truhe öffnen kannst, während du eine Heimatrolle hältst. Ein pauschales Kampfverbot hieße, dass du keinen Zombie schlagen kannst, während du Hanffasern trägst. Die Ausnahme, die die Unterscheidung rechtfertigt, ist die Rüstung: nur der Rüstungs-Archetyp öffnet sie, was aus "ein Geldschein ist kein Helm" etwas macht, das der Server durchsetzt, statt etwas, das ein Kommentar behauptet.

Der Nahkampf wird für Währung bewusst nicht verweigert, und die Begründung steht geschrieben, statt bloß vorausgesetzt zu werden: ein Goldblock-Schein, den du einem Zombie überziehst, macht Faustschaden und wandelt nichts um, während ein Kampfverbot dich daran hindern würde, dich zu verteidigen, nur weil du Geld dabeihast.

Die Handwerksregel

Zwei Bedingungen müssen zugleich erfüllt sein, bevor ein Custom-Item in ein Rezept darf: das Item deklariert die Handwerksoberfläche, und das Rezept nennt genau diese Id. Die Erlaubnisliste wird zum Zeitpunkt des Abgleichs aus dem lebenden Rezept abgeleitet, nie von Hand gepflegt. Die zweite Bedingung verhindert, dass Hanfstoff stillschweigend ein Rezept erfüllt, das nach Hanfseil verlangt hat, denn beide teilen sich eine Papierbasis. Derzeit deklarieren sechs Ids das Handwerk: das Spawner-Fragment, das Riss-Erzfragment, Glutessenz, Hanffaser, Hanfstoff und getrockneter Cannabis. Zwei alte Schmiedevorlagen deklarieren den Schmiedetisch, und die beiden Effizienzbücher deklarieren den Amboss.

Wie eine Verweigerung im Spiel aussieht

Eine gesperrte Oberfläche scheitert nicht stumm. Sie erklärt. Die Zeile nennt, was das Item ist, was du damit versucht hast und wofür es tatsächlich gedacht ist:

Das ist eine Währung, sie kann nicht kompostiert werden. Das ist Geld. Rechtsklick zum Einlösen, oder gib es aus.

Jeder Archetyp hat seinen eigenen Schlusssatz. Ein Schlüssel bekommt "er wird an der einen Station verbraucht, zu der er gehört". Ein Relikt bekommt "sein Wert liegt im Besitz oder in der Abgabe". Ein Bauplan bekommt "gib ihn einem Baumeister-NPC". Die Verweigerung endet in einem Hinweis statt in einer Wand.

Die Bremse, und warum sie so geschlüsselt ist

Der Hinweis ist auf eine Zeile pro Spieler, pro Oberfläche, pro 10 Sekunden begrenzt. Der Teil "pro Oberfläche" ist wichtig. Eine frühere Fassung teilte ein einziges Fenster über alle Oberflächen, sodass ein Spieler, der am Zaubertisch abprallte und zum Schleifstein weiterging, dort völlig stumm abgewiesen wurde, also genau in dem Moment, in dem jemand herausfindet, was ein Item tut. Die Schlüsselung pro Oberfläche behält die Eigenschaft, um die es eigentlich ging: ein Trichter, der einen Ofen füttert, erzeugt weiterhin höchstens eine Zeile alle zehn Sekunden, weil er jedes Mal dieselbe Oberfläche verweigert.

Verweigerungen ohne Spieler in der Hand

Ein trichtergefütterter Ofen, Komposter oder Braustand hat niemanden, der es getan hat. Der Wächter sucht, wer das Inventar dieses Blocks offen hat, weicht auf jeden Spieler im Umkreis von 6 Blöcken aus und bleibt still, wenn niemand zuschaut. Eine Verweigerung in einen leeren Raum gerufen ist nur Lärm.

Die Prüfungen beim Serverstart

Eine Regel, die nur aufgeschrieben ist, driftet ab. Sechs Selbstprüfungen laufen bei jedem Serverstart, gehen alle 209 Registrierungen durch und melden, was sie finden. Sie protokollieren; sie brechen den Start nie ab, denn einen sonst gesunden Server wegen einer Diagnose zu töten ist der schlimmere Fehler.

Prüfung 5 lohnt eine Erklärung, denn "in beide Richtungen" leistet hier echte Arbeit. Sie liest die lebende Rezeptliste und vergleicht sie zweimal mit den Deklarationen. Ein Item, das Handwerk deklariert, aber von keinem registrierten Rezept genannt wird, wird gemeldet: die Deklaration ist veraltet, oder das Rezept konnte sich nicht registrieren. Ein Item, das von einem registrierten Rezept genannt wird, aber kein Handwerk deklariert, wird ebenfalls gemeldet, und das ist die gefährliche Richtung: der Wächter würde ein Rezept verweigern, das heute funktioniert, und das erste Symptom wäre ein Rezept, das einem Spieler stillschweigend nichts zurückgibt.

Seit damals sind drei weitere Arme dazugekommen. Prüfung 7 jagt den umgekehrten Fehler zu allen anderen: sie sucht nach Übersperrung und meldet jedes Item, dessen Grundmaterial eine Vanilla-Blockumwandlung beherrscht, die das Item aber nicht erlaubt, denn das ist ein Werkzeug, das stillschweigend genau das verloren hat, wofür seine Basis da ist. Prüfung 8 existiert, weil die Prüfungen 7 und 7f die deklarierte Basis lesen, während zur Laufzeit die umgestufte gilt, und eine Prüfung, die über die gelesene Tabelle ehrlich und über die entscheidende Tabelle still ist, kostet hier Releases. Prüfung 9 stellt sicher, dass jedes geschmiedete Rüstungsteil auf jeder Stufe verzierbar bleibt, denn die Verzierungserlaubnis wird unerreichbar, sobald ein Teil auf einem Material gebaut wird, das Vanilla nicht verziert, ohne Fehlermeldung und ohne anderes Symptom.

Die Baubarkeitsprüfung, und wo sie läuft

Eine weitere Prüfung steht neben den neun, weil sie etwas tut, was die anderen nicht tun: sie baut tatsächlich. Die Baubarkeitsprüfung verlangt von jeder Registrierung, die eine Factory deklariert, einen echten Stapel, und die aktuelle Startzeile meldet 129 von 129 in Ordnung. Vor einer Versionsfamilie waren es 71 von 71, und das ist die schlichteste einzelne Zahl dafür, wie stark die Registry gewachsen ist.

Interessant ist, wo sie läuft. Früher saß sie mitten im Aktivierungsdurchlauf, und ein Startprotokoll zeigte dieselbe Factory einmal scheitern und Sekunden später im selben Start gelingen, weil das Teilsystem, nach dem sie griff, noch nicht verdrahtet war. Alles, was ein Objekt erzeugt, läuft nun stattdessen am Ende der Aktivierung. Dasselbe Protokoll brachte nebenbei einen schlimmeren Fall ans Licht: ein Bauteil einer Schmiedestufe 5 war als reiner Metadaten-Eintrag registriert, unter einem Kommentar, der die Regel genau verkehrt herum wiedergab, das Item war also nie konstruierbar und sein Rezept wurde bei jedem einzelnen Neustart verweigert. Die Startzeile hatte das die ganze Zeit gesagt.

Das Resource Pack

Die Modelle liegen in einem eigenen Pack namens blacklight_items. Es wird gehostet statt ins Plugin eingebaut, und der Server schickt es deinem Client beim Betreten zu. Das veröffentlichte Pack umfasst 797 Dateien und 280 Texturen und wird aus einer sortierten Dateiliste mit festem Zeitstempel gebaut, sodass zwei Auslieferungen gleichen Inhalts byteidentische Zip-Dateien und dieselbe Prüfsumme ergeben.

Zwei Register, und eine nackte Zahl, die von keinem der beiden erzählt

Das Pack deklariert für Minecraft 26.2 das RESOURCE-Format 88, und zwar als Bereich statt als Punktwert: min_format 84 bis max_format 88. Ein Datenpaket deklariert bei derselben Version 107.1. Das sind zwei völlig verschiedene Register, und dieser Teil lohnt zweimal gelesen zu werden: beide sind nackte Ganzzahlen im JSON, und nichts in der Datei sagt, welche der beiden Fragen sie überhaupt beantwortet.

Das hat ein Release gekostet. Das Pack hatte 101 deklariert, Minimum wie Maximum, und 101 ist die Daten-Hauptnummer für 26.1, nicht die des Resource-Registers. Die Resource-Nummer jener Version war 84. Völlig falsche Achse, und wer 101 gegen ein Änderungsprotokoll prüfte, fand sie dort und bestätigte damit den Fehler, denn 101 ist eine echte Zahl, die im anderen Register etwas Echtes bedeutet. Die Lösung bestand nicht darin, 101 von Hand in 84 zu ändern, denn eine von Hand gesetzte 84 ist dasselbe Artefakt, nur um eine Ziffer glücklicher. Die Datei wird nun vom Pack-Generator aus einer einzigen benannten Konstante geschrieben, die ihr eigenes Register mitführt, und eine Prüfung stellt sicher, dass sich die Hauptnummern der beiden Register nie überschneiden: sobald eine Zahl beides sein könnte, lässt sich die Frage "ist das eine Resource-Nummer?" aus der Zahl heraus gar nicht mehr beantworten.

Dieselbe Feinheit beißt auch in die andere Richtung. Ein nacktes Maximum ist kein Punktwert, weshalb ein Pack mit max_format 107 auch bei 107.1 lädt. Hätte es 107.0 bedeutet, würde eines der unten genannten Datenpakete ausgerechnet auf der Version verweigern, nach der es benannt ist.

Die vier Datenpakete

Vier Datenpakete werden mit dem Server ausgeliefert und sind auf genaue Versionen festgenagelt. Alle vier laden beim Datenformat 107.1 von 26.2.

Zwei Dinge über diesen Satz sollte man wissen, statt sie zu entdecken. Endercon löscht die Platzierung der Endsiedlungen aus Vanilla und setzt eigene etwa dreimal so dicht auf derselben Zufallsbasis wieder ein, also eine echte Balance-Änderung, die in einem Datenpaket ankommt statt hinter einer Einstellung. Teile davon sind außerdem für einen Mod-Loader gebaut, für den ein Paper-Server keinen Leser hat, diese Dateien werden also ohne jede Fehlermeldung ignoriert, und man sollte nicht annehmen, dass seine Ende-Inhalte funktionieren. Epic Dungeons liefert seinen gesamten Bauwerkssatz zweimal aus, einmal unter den alten und einmal unter den aktuellen Verzeichnisnamen, was seine Größe etwa verdoppelt, und ein Raum existiert nur unter der toten Schreibweise.

Die Auswahl läuft über eine Zeichenketten-Eigenschaft

Jedes überschriebene Basis-Item trägt ein minecraft:select-Modell, geschlüsselt auf minecraft:custom_model_data, mit benannten Fällen, die jede Custom-Id auf ein Blacklight-Modell abbilden, und mit dem Vanilla-Modell als Rückfall. Trägt ein Stapel keine Custom-Id oder eine, die diese Basis nicht auflistet, sieht er exakt wie Vanilla aus.

Eine Basis hat ihren Eintrag bei der letzten Neuerzeugung ganz verloren. compass.json trug genau einen Fall, für ein Item, das nirgends mehr registriert ist, und der Generator hat die veraltete Route von selbst fallen gelassen. Das ist von den Verweigerungen weiter unten zu unterscheiden: hier war eine Entfernung zu Recht eine Entfernung.

Das Pack entsteht aus der Registry, und die gelesene Liste war um zwei Drittel zu kurz

Das Pack wird erzeugt, nicht von Hand gepflegt. Lange Zeit war das weniger wahr, als es klang. Die Manifestdatei der lebenden Items hatte genau einen Erzeuger, einen Befehl, der einen laufenden Server braucht, und ohne einen solchen fiel der Generator auf eine eingebaute Liste zurück, die seine eigene Quelle als veraltet bezeichnete. Niemand hatte gemessen, wie veraltet. Gemessen: die Registry enthält 209 Items, die Rückfallliste nannte 75. Rund zwei Drittel des Bestands waren für jeden Pack-Lauf ohne Server unsichtbar, und zwei Einträge der Rückfallliste nannten Items, die überhaupt nicht mehr registriert sind.

Die Lösung ist möglich, weil eine Registrierung deklariert statt zu erzeugen: die Registry lässt sich ganz ohne Server hochfahren, und ein Exportwerkzeug schreibt in etwa einer Sekunde ein echtes Manifest. Es verweigert lieber, als eine plausible Datei zu schreiben, denn eine gescheiterte Selbstprüfung, eine nicht hochfahrbare Registry oder ein Bestand von null würden jeweils ein Pack ohne ein einziges Custom-Item und einen erfolgreichen Rückgabewert liefern. Das erste echte Manifest fand sofort sechs Barrenitems, die Texturen nennen, die es nicht gibt, was auf beiden Plattformen als violettschwarzer Fehlwürfel erscheint, und eine Rückfallform, mit der sechs von zehn Items gezeichnet wurden, weil keine Regel auf sie passte.

Die Blockhälfte, und der Garten

Die Registry enthielt früher nur Items. Der Garten hat Blöcke mitgebracht, und sie werden nach derselben Regel deklariert: ein Blacklight-Block ist eine Position mit einer Textur und einem Namen, und er hat genau die Verhaltensweisen, die er deklariert. Die Block-Archetypen sind PLANTER, STATION, DECOR, TRELLIS, HIVE, SOIL und SERVERY, deklariert und nie aus dem abgeleitet, worauf der Block sitzt, aus demselben Grund wie bei einem Item.

Heute sind zwei Custom-Blöcke registriert: der Pflanzkasten und das Gartenspalier. Beide sitzen auf einem Notenblock und beanspruchen je einen bestimmten Notenblockzustand.

Die Identität ist positionsgebunden, und das Verzeichnis wächst nur hinten

Ein Notenblock kann keine Itemdaten tragen, es gibt am Block also keine Stelle, an die sich "das ist ein Pflanzkasten" schreiben ließe. Der Eintrag liegt stattdessen im Chunk. Er wandert mit dem Chunk mit, übersteht Neustarts ohne eigenen Schreibvorgang und schafft keinen neuen Speicherpfad, und genau diese Eigenschaft hat die Entscheidung gewonnen. Die Frage "gehört der uns?" beim Blockabbau ist zuerst ein Nachschlagen im Arbeitsspeicher, und der Chunk-Eintrag wird nur bei einem Treffer gelesen.

Die Zuordnung von Custom-Block-Id zu Hostzustand wächst nur hinten und wird nie umsortiert, und das ist die Invariante, zu deren Schutz der ganze Entwurf existiert. Sie umzusortieren zerstört keinen Build und protokolliert überhaupt nichts. Sie tauscht stillschweigend das Aussehen jedes einzelnen dieser Blöcke aus, der bereits in der Welt steht: dein Pflanzkasten ist nach dem nächsten Neustart etwas anderes. Eine eingecheckte Verzeichnisdatei und ein Build-Wächter stellen sicher, dass sich nie ein bestehender Eintrag ändert.

Was ein Bedrock-Spieler sieht, wird deklariert, nicht abgeleitet. Custom-Blockmodelle gibt es nur auf Java, also muss jemand entscheiden, welcher Vanilla-Block einspringt, und ein Standardwert wäre eine Vermutung über genau den Client, den ein Resource Pack nicht korrigieren kann. Der Pflanzkasten deklariert einen Komposter, das Gartenspalier einen Eichenzaun. Jeder Registrierungsaufruf nimmt diesen Rückfall entgegen, ihn zu vergessen ist also ein Übersetzungsfehler und keine Startmeldung.

Die Blockhälfte des Generators

Der Generator schreibt blockstates/note_block.json, und die Form dieser Datei ist das Argument. Ein Notenblock hat 1.350 Zustände. Zwei davon sind beansprucht. Nur diese zwei zu schreiben würde die anderen 1.348 für jeden Spieler auf dem Server unsichtbar machen, auch für alle, die überhaupt keinen Custom-Block besitzen, also wird die Datei vollständig geschrieben: zwei beansprucht, 1.348 erhalten und auf das Vanilla-Modell zeigend. Ein Release lang wurde sie standardmäßig rundheraus verweigert, weil sich auf der Baumaschine keine Kopie der Vanilla-Datei beschaffen ließ und eine Vermutung keine Kopie ist. Die Annahme ist nun prüfbar statt still: wo eine echte Vanilla-Datei vorliegt, gewinnt sie, und der Lauf gibt sowohl den angenommenen als auch den echten Wert aus, sodass eine Abweichung sichtbar wird.

Lange Zeit schrieb die Blockhälfte gar nichts, und der Grund war nicht, dass sie ungebaut gewesen wäre. Einen Block hinzuzufügen erfordert drei Änderungen in einem Zug: die Tabelle im Code, die Verzeichnisdatei und die Registrierung. Nur zwei davon wurden je gemacht. Ohne die Verzeichnisdatei blieb die Blockhälfte des Generators bei "Verzeichnis fehlt" stehen und gab keine Notenblockdatei aus, und der Wächter, der das Verzeichnis prüft, scheiterte an seiner eigenen fehlenden Eingabe. Die Blockhälfte verweigerte, weil sie nichts zu lesen hatte, und das ist etwas anderes als eine Funktion, die es nicht gibt. Diese eine Datei anzulegen hat sie eingeschaltet.

Wie Pflanzen aussehen

Pflanzen bekommen eine eigene Hälfte. Das Pflanzenverzeichnis enthält 64 Erscheinungsbilder über 19 Arten: 60 für Feldfrüchte, dazu die vier Reifemarken des Hains, die zuletzt in die übrig gebliebenen Zustände eingetragen wurden. Der Generator zeichnet für jedes davon ein Modell und eine Textur und überzieht dann den Host neu, indem er blockstates/tripwire.json mit 128 Varianten schreibt. Eine wachsende Pflanze ist ein Stolperdraht, der einen reservierten Zustand trägt, den das Pack als Pflanze malt, und die reservierten Zustände lassen die Stromflagge und die vier Richtungsflaggen bewusst frei.

Zwei Erscheinungsbilder auf einer Textur wären zwei Dinge, die ein Spieler nicht auseinanderhalten kann, und eine Streuung in Behälter garantiert nicht, dass sie sich unterscheiden, also wird die eindeutige Verzeichnisposition jedes Bildes in vier Eckpixel gestempelt. Zwei beliebige Erscheinungsbilder unterscheiden sich damit konstruktionsbedingt in mindestens einem Pixel, und nicht aus Glück.

Ein Java-Client mit dem Pack sieht die Pflanze. Einem Java-Client ohne Pack und jedem Bedrock-Client wird stattdessen pro Betrachter die Vanilla-Feldfrucht geschickt, also eine Täuschung, die am Weltzustand nichts ändert. Was die Pflanze wert ist, wie schnell sie wächst, was sie einbringt und wie ihre Genetik aussieht, stammt aus dem Beeteintrag und ist in beiden Fällen identisch. Nur das Bild unterscheidet sich. Die Anbauseite behandelt der Artikel zu den Gartenpflanzen.

Platzhalter statt Grafik

Der Generator zeichnet keine Behelfsbilder mehr. Wo eine Textur nicht gezeichnet wurde, schreibt er einen 1 mal 1 Pixel großen, völlig durchsichtigen Platzhalter und überlässt das Zeichnen einem Menschen. Früher schrieb er ein 1 mal 1 Pixel großes magentafarbenes Quadrat, und Magenta ist genau die Farbe, die ein Client bei einer fehlenden Textur malt, eine strukturell perfekte Kette, die darin endete, war also von einem kaputten Würfel nicht zu unterscheiden. Jedes 1 mal 1 Pixel große Bild gilt in jeder Kodierung als Platzhalter, und genau so werden die älteren magentafarbenen erkannt und ersetzt statt als Grafik bewahrt.

Das Pack behält jeden Auswahlfall, unabhängig davon, was gezeichnet ist. Ein früherer Versuch ließ den Fall für ein Item ohne Grafik weg, damit es auf seine Vanilla-Basis zurückfällt, und diese Sperre las die Textur auf derjenigen Maschine, auf der der Generator gerade lief. Der Generator läuft in einer Sandbox ohne die Texturen, er ließ also jeden Fall weg, und jedes Custom-Item verlor in einem einzigen Lauf seine Grafik. Ob ein Item sein eigenes Modell oder seine Vanilla-Basis zeigt, entscheidet der Server beim Stempeln, nicht das Pack anhand dessen, welche Dateien zufällig auf der Platte lagen.

Fünf Basis-Items bleiben absichtlich vanilla

Fünf Vanilla-Itemdateien werden nie überschrieben: bow, crossbow, trident, shield und fishing_rod. Ihre Vanilla-Definitionen sind keine flachen Modelle, sondern Bedingungsbäume. Die Bogendatei verzweigt über Spannen und Spannfortschritt; die Armbrust über geladen und Feuerwerk; der Dreizack über die Wurfhaltung; der Schild über das Blocken; die Angel über den Wurfzustand. Eine flache Überschreibung darüber zu schreiben ersetzt den ganzen Baum, und zwar für jeden Träger dieses Basis-Items auf dem Server, ob custom oder nicht.

Das ist kein Gedankenspiel, und es ist der Fehler, der immer wiederkommt. Eine ausgelieferte shield.json hatte jedem Schild auf dem Server die Blockhaltung gekostet. Eine ausgelieferte trident.json hatte jedem Vanilla-Dreizack die Wurfhaltung gekostet, und ihr einziger Custom-Fall hätte ohnehin nie greifen können, weil der geschmiedete Speer längst auf ein Speermaterial umgezogen war.

Bei der Dreizackdatei lohnt es sich zu verweilen, denn sie hat das Release überlebt, das sie gefunden hat, und fünf weitere Releases lang jedem Dreizack auf dem Server geschadet. Der Code, der die veraltete Datei einer verweigerten Basis löscht, lag innerhalb der Schleife über die Grundmaterialien, und diese Schleife besucht nur eine Basis, auf der der Bestand noch Items hat. In dem Moment, in dem der geschmiedete Speer die Dreizackbasis verließ, wurde die Löschung unerreichbar und die schlechte Datei dauerhaft. Eine Verweigerung, die nur wirkt, solange die Basis belegt ist, hört genau dann auf zu wirken, wenn die veraltete Datei am meisten zählt. Die Selbstprüfung des Generators hatte die Datei die ganze Zeit korrekt und ungehört gemeldet. Beide Dateien sind nun weg, und der Durchlauf geht bei jedem Lauf alle fünf Basen durch, belegt oder nicht.

Der Kompromiss wird offen genannt statt versteckt. Custom-Items auf diesen fünf Basen sehen aus wie gewöhnliche Vanilla-Items: die geschmiedeten Bögen liegen auf der Bogenbasis, also sehen sie wie Bögen aus. Ihre Identität sind Name und Lore, also genau das, was ein Bedrock-Spieler ohnehin schon immer sieht. Dagegen abgewogen ist es das schlechtere Ergebnis, jedem Bogenschützen auf dem Server die Spannanimation zu zerstören.

Der Generator entscheidet das nicht anhand einer fest verdrahteten Namensliste. Wo eine Kopie der Vanilla-Datei vorliegt, liest er deren Form: ein flaches Modell darf flach umschlossen werden, alles andere ist ein Baum und behält das gesamte Vanilla-Modell als Rückfall, mit den Custom-Fällen daneben. Mojang kann in jeder Version an jeder Basis eine Bedingung ergänzen, und nur die Datei weiß davon. Die Namensliste bleibt allein als Notlösung für den Fall, dass keine Vanilla-Datei zur Hand ist.

Ein Modell erscheint nur hinter echter Grafik

Es gibt zwei Wege, ein Item auf ein eigenes Modell zu zeigen. Der ältere ist der Auswahlfall von oben, der vom Basis-Item abhängt. Der neuere stempelt eine Item-Modell-Komponente direkt auf den Stapel, die die gesamte Modelldefinition ersetzt und deshalb von der Basis unabhängig ist: eine Netheritstufen-Spitzhacke kann ihr geschmiedetes Modell zeigen statt einer Vanilla-Netheritspitzhacke. Beide Wege werden bewusst genutzt, damit ein Client, der die Komponente ignoriert, weiterhin den Auswahlpfad als Rückfall hat.

Der Stempel hängt an einer einzigen Frage: steht hinter dieser Id echte Grafik? Der Grund ist ein Fehler, der aus jedem Blickwinkel grün aussah. Jedes Glied der Kette wurde geprüft, und jedes Glied löste auf: die Komponente zeigte auf eine Definition, die Definition auf ein Modell, das Modell auf eine Textur, und die Textur existierte. Niemand fragte, was in der Textur steht. Jedes Bild im Pack war ein 1 mal 1 Pixel großer magentafarbener Platzhalter von 69 Byte, und Magenta ist genau die Farbe, die ein Client bei einer fehlenden Textur malt. Eine strukturell perfekte Kette, die in einem Magenta-Pixel endet, ist von genau dem kaputten Würfel nicht zu unterscheiden, den die Kettenprüfung verhindern sollte.

Die Regel, die daraus folgte, ist kurz: ein Stempel ohne Grafik dahinter sieht schlechter aus als gar kein Stempel. Ungestempelt fällt ein geschmiedetes Schwert auf ein lesbares Eisenschwert zurück, das seinen eigenen Namen, seine Lore, seine Seltenheit, seine Werte, seine Sockel und seine Runen trägt. Mit nichts dahinter gestempelt ist es ein Würfel.

Die Größenprüfung war falsch, und die Lösung ist eine Identitätsprüfung

Die erste Fassung der Sperre fragte, ob die Texturdatei größer als 200 Byte ist, mit der Begründung, ein Platzhalter sei das nie und echte Grafik immer. Am tatsächlichen Pack gemessen stimmt das in beide Richtungen nicht. Zwei echte 16 mal 16 Pixel große Texturen kamen auf 185 und 194 Byte und wurden ausgeschlossen, weil sie fünfzehn Byte zu klein waren, das Plugin hatte sich also geweigert, vorhandene Grafik zu stempeln. Ein bewusst angelegtes 8 mal 8 Pixel großes durchsichtiges Abstandszeichen von 73 Byte wäre von jeder Regel, die kleine Dateien als Platzhalter übernimmt, rundheraus gelöscht worden, und das ist die Katastrophe der zerstörten Grafik, nachgebaut aus einer Faustregel, genau in dem Code, der sie verhindern sollte.

Die Frage richtet sich nun an die Identität statt an die Größe. Der Platzhalter ist deterministisch, der Schreiber vergleicht also die Bytes auf der Platte mit ihm: nichts vorhanden heißt schreiben, genau unser Platzhalter heißt überschreiben, und alles andere, wie klein auch immer, heißt bewahren. Die Zahl 200 überlebt nur noch als ausgegebenes Signal, denn "diese Textur ist verdächtig klein" verdient weiterhin die Aufmerksamkeit eines Betreibers, aber sie ist nicht mehr die Sperre.

Ohne Pack, und auf Bedrock

Nichts an der Mechanik hängt am Resource Pack. Wenn du es ablehnst, wenn es nicht geladen wird oder wenn du auf Bedrock spielst, verhält sich jedes Custom-Item exakt gleich. Sein Name, seine Lore, seine Seltenheitsfarbe, seine Werte, seine Sockel und seine Runen sind weiterhin da, denn all das sind serverseitige Daten im Item selbst und nicht im Pack. Für die Blöcke und die Pflanzen gilt dasselbe: was ein Beet einbringt und was ein Pflanzkasten tut, gehört dem Eintrag, und nur das Bild gehört dem Pack.

Bedrock ist die ehrliche Probe darauf, und es war von Anfang an die Entwurfsvorgabe und kein Nachgedanke. Custom-Model-Data-Zeichenketten sind eine Mechanik des Java-Clients; ein Bedrock-Client sieht das Vanilla-Modell, ganz gleich was er annimmt. Die Regel, gegen die das gesamte Itemsystem geschrieben ist, lautet deshalb: die Identität eines Items muss allein in Name und Lore überleben. Die Lore einer Ruinenkarte unterscheidet sich von Exemplar zu Exemplar, und genau deshalb ist sie ein reiner Metadaten-Eintrag: die Lore ist das Item. Erz-Identität steht im Namen. Nichts Wichtiges ist je nur in einer Textur kodiert.

Eigene Namen werden über einen einzigen Baustein erzeugt, weshalb sie einheitlich aussehen. Namen sind weiß und nicht kursiv, sofern sie keine andere Farbe verlangen, Lore-Zeilen sind grau und nicht kursiv, und die Seltenheit wird ausdrücklich gesetzt. Letzteres ist keine kosmetische Buchhaltung: ein Item auf einem verzauberten Buch oder einem Netherstern erbt die Seltenheitsfärbung von Vanilla, und sein Name kommt gelb oder türkis heraus, ganz gleich welche Farbe er verlangt hat. Die Seltenheit wird deshalb festgelegt statt dem Grundmaterial überlassen. Kursivschrift wird rekursiv entfernt, denn das Abschalten von Kursiv auf einer Zeile betrifft nur diesen Knoten, und eine aus Teilen zusammengesetzte Lore-Zeile wird ab der Fuge kursiv.