Custom-Items ohne das Plugin dahinter

Man kann Pakete mit fertigen Gegenständen kaufen — Waffen, Möbel, Dekoration, mit Modellen und Texturen. Sie werden fast immer als Konfiguration für ein bestimmtes Plugin geliefert, das eigene Gegenstände verwaltet.

Der Punkt, den ich beim Durcharbeiten mehrerer solcher Pakete gelernt habe: Das Plugin-Format ist egal. Was zählt, sind die Modelle.

Warum das so ist

Ein eigener Gegenstand in Minecraft ist auf Java-Seite meistens kein neuer Gegenstand, sondern ein vorhandener mit einer Zusatzkennung. Ein Stock mit der Kennung 311 sieht anders aus, weil das Texturenpaket für genau diese Kombination ein anderes Modell hinterlegt.

Die verschiedenen Plugins unterscheiden sich darin, wie sie diese Zuordnung verwalten und welche Zusatzfunktionen sie mitbringen. Die Modelle und Texturen selbst sind bei allen dieselben Dateien.

Wer also ein eigenes System für solche Zuordnungen hat, kann die Inhalte direkt übernehmen — ohne das Plugin zu installieren, für das sie geliefert wurden.

Zuerst prüfen, was schon da ist

Der wichtigste Schritt, und der, den ich fast übersprungen hätte.

Das Paket, mit dem mein Server ausgeliefert wurde, enthielt bereits mehrere Sätze fertig zugeordneter Gegenstände. Hätte ich die gekauften Pakete blind eingespielt, wären Dubletten entstanden — dieselben Modelle unter verschiedenen Kennungen, und dieselben Kennungen für verschiedene Modelle.

Der Prüfweg: alle vorhandenen Zuordnungsdateien einlesen, die verwendeten Modellnamen sammeln, und das Neue dagegen abgleichen. Das Ergebnis war eindeutig — von den geplanten Ergänzungen war ein Teil bereits vorhanden, ein weiterer lag zwar im Paket, hatte aber keine Zuordnung und war damit unbenutzbar.

Am Ende kamen deutlich weniger neue Gegenstände dazu als geplant, und die bestehenden blieben unangetastet.

Die Fallen beim Übernehmen

Modellpfade nicht raten. Jede Plugin-Konfiguration gibt Pfade in ihrer eigenen Schreibweise an — mal mit Namensraum, mal mit Dateiendung, mal als blanker Name. Robust ist, einen Index aller Dateien im Paket zu bauen und darin zu suchen.

Schreibfehler in fremden Paketen. In einem Paket verwies die Konfiguration auf einen Dateinamen, der so nicht existierte — im Dateinamen selbst waren zwei Buchstaben vertauscht. Auffangen lässt sich das über eine Ähnlichkeitssuche mit hoher Schwelle. Blind übernehmen führt zu einem Gegenstand ohne Modell.

Fehlalarme beim Prüfen. Ein Texturverweis, der wie ein fehlender Dateipfad aussieht, kann ein Verweis auf einen anderen Eintrag in derselben Datei sein. Und Verweise auf Standardinhalte des Spiels müssen im Paket gar nicht liegen. Wer eine strenge Prüfung baut, bekommt zuerst eine Liste voller Fehlalarme.

Belegte Basisgegenstände. Die Zuordnung hängt an einem Grundgegenstand plus Kennung. Wenn ein Paket dieselben Kennungen auf demselben Grundgegenstand benutzt wie ein anderes, kollidieren sie. Es lohnt sich, vorher zu zählen, welche Grundgegenstände wie stark belegt sind — bei mir waren mehrere noch völlig frei, sodass fast alle Pakete ihre ursprünglichen Kennungen behalten konnten.

Und Bedrock

Die zweite Hälfte der Arbeit, und die, die man beim Kauf nicht mitkauft. Bedrock-Clients sehen das Java-Paket nie. Damit sie etwas sehen, braucht es pro Gegenstand drei Dinge:

1. Die Textur als Bilddatei im Bedrock-Paket.
2. Einen Eintrag, der dieser Textur einen Schlüssel gibt.
3. Einen Eintrag in der Zuordnungsdatei der Übersetzungsschicht, der sagt: Dieser Grundgegenstand mit dieser Kennung sieht bei dir so aus.

Wichtig dabei: Der Verweis in Schritt 3 zeigt auf den Schlüssel aus Schritt 2, nicht auf einen Dateipfad. Das habe ich zweimal falsch gemacht, bevor es saß.

Der Nachweis, dass es gegriffen hat, steht im Protokoll der Übersetzungsschicht beim Start: Sie meldet, wie viele eigene Gegenstände sie registriert hat. Die Zahl vorher und nachher zu vergleichen ist der schnellste Weg zu wissen, ob eine Änderung angekommen ist.

Das Prüfskript, das ich dafür gebaut habe

Bei mehreren hundert Zuordnungen ist eine Kontrolle von Hand nicht mehr möglich. Deshalb gibt es ein Skript, und was es prüft, ist die eigentliche Erkenntnis aus dieser Arbeit.

Verweist jede Zuordnung auf ein Modell, das existiert? Der häufigste Fehler, und er fällt im Spiel als fehlende Textur auf.

Verweist jedes Modell auf Texturen, die existieren? Mit einer Ausnahmeliste für Standardinhalte des Spiels, die nicht im Paket liegen müssen.

Gibt es doppelte Zuordnungen? Derselbe Grundgegenstand mit derselben Kennung, zweimal vergeben — dann gewinnt eine, und welche ist Zufall.

Sind alle Bedrock-Einträge vollständig? Textur vorhanden, Schlüssel vergeben, Zuordnung eingetragen. Drei Stellen, und alle drei müssen zusammenpassen.

Ein gesundes Paket meldet null fehlende Modelle und null fehlende Texturen. Diese Zahl ist die Freigabe — vorher wird nichts ausgeliefert.

Warum das Prüfen wichtiger ist als das Bauen

Der Grund für den Aufwand ist die Art, wie solche Fehler auffallen: gar nicht, bis jemand den Gegenstand in die Hand nimmt.

Ein fehlendes Modell erzeugt keinen Fehler beim Start. Kein Protokolleintrag, keine Warnung. Der Gegenstand sieht einfach aus wie sein Grundgegenstand — und das kann Wochen dauern, bis es jemandem auffällt.

Bei einem Katalog mit mehreren hundert Einträgen ist es ausgeschlossen, jeden im Spiel zu prüfen. Also muss die Prüfung an den Dateien ansetzen.

Das ist derselbe Gedanke wie bei allem anderen, was ich mir in diesem Sommer gebaut habe: Wenn ein Fehler still ist, braucht es eine Messung, die ihn laut macht. Ohne die verlässt man sich darauf, dass irgendwann jemand etwas bemerkt — und das ist keine Qualitätssicherung, sondern Hoffnung.

Was ich mir gebaut habe

Für all das ein paar kleine Skripte: eines, das ein Paket zusammenbaut, eines, das es prüft, und eines, das die Bedrock-Seite ergänzt.

Das Prüfskript ist das wichtigste. Es meldet für ein gesundes Paket null fehlende Modelle und null fehlende Texturen. Damit ist die Frage „habe ich alles erwischt" eine Sache von Sekunden statt eines Rundgangs im Spiel.

Und es beantwortet die Frage, die man sonst erst im Spiel stellt — vor jeder Auslieferung, statt danach.