Start › Wiki › Eigene Items und das Resource Pack

Eigene Items und das Resource Pack

Die 122 registrierten Custom-Items, die Oberflächen, die ihnen standardmäßig verschlossen sind, und das Resource Pack, das ihnen 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 122 Einträge. Davon sind 58 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 64 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, Expeditionsabzeichen, 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 122 Registrierungen deklarieren nun einen von achtzehn Archetypen.

Der Archetyp ist eine andere Achse als die Katalogkategorie. Die Kategorie hat elf Werte (Schmiede, Riss, Ruine, Hain, Expedition, Essen, Werkzeug, Hilfsmittel, Edelstein, Rune, Shop) 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. 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.

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 bloss 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 122 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.

Das Resource Pack

Die Modelle liegen in einem eigenen Pack namens blacklight_items. Es deklariert Pack-Format 101, Minimum wie Maximum, also das Item-Modellformat von Minecraft 26.1. Es wird gehostet statt ins Plugin eingebaut, und der Server schickt es deinem Client beim Betreten zu.

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.

Das Pack wird aus der Registry erzeugt, nicht von Hand gepflegt. Das Plugin exportiert den lebenden Itembestand in eine Manifestdatei, die der Generator liest, sodass das Pack weder Items auflisten kann, die es auf dem Server nicht gibt, noch welche vergessen, die es gibt.

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. Eine ausgelieferte trident.json hatte bereits jedem Vanilla-Dreizack auf dem Server die Wurfhaltung gekostet, und ihr einziger Custom-Fall hätte ohnehin nie greifen können, weil der geschmiedete Speer auf einem Speermaterial gebaut ist und nie auf einem Dreizack. Eine ausgelieferte shield.json hatte jedem Schild die Blockhaltung gekostet. Beide Dateien wurden gelöscht statt liegen gelassen, denn eine Verweigerung, die die schlechte Datei auf der Platte lässt, ändert nichts.

Der Kompromiss wird offen genannt statt versteckt. Custom-Items auf diesen fünf Basen sehen aus wie gewöhnliche Vanilla-Items: die fünf Expeditionsabzeichen liegen auf der Schildbasis, also sehen sie wie Schilde 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.

Der Generator geht deshalb ein viertes Glied weiter. Er prüft, ob die Texturdatei größer als 200 Byte ist, was ein Platzhalter nie und echte Grafik immer ist, und schreibt die Antwort in eine Manifestdatei, die das Plugin liest. Das Plugin hat keine Kopie des Packs, das Manifest ist also das Einzige, was es fragen kann. Ein fehlendes oder unlesbares Manifest gilt als leere Menge, nie als Fehler, denn das Verhalten bei "wir konnten es nicht lesen" muss ein lesbares Vanilla-Item sein und kein verweigertes.

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.

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 eines Siegelfragments nennt, wo das nächste liegt. 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.