Erstellen Sie fertige /give-Befehle für RP-Requisiten, Quest-Belohnungen und Gildenpässe. Dieser Builder trennt die Versionen, sodass Sie bei älterer Syntax kompakt bleiben oder item_model, custom_data und reichhaltige custom_model_data-Slots für 1.21.4+ nutzen können.
Version: 1.21.4+. Befehlslänge: 0 Zeichen.
Der Builder hält die ältere Syntax absichtlich kompakt. Beim Wechsel zu 1.21.4+ erweitert sie sich in das reichhaltigere Komponentenformat.
Ein Custom Item muss fast immer drei Aufgaben zugleich erfüllen. Es soll im Inventar richtig aussehen, eine versteckte Identität tragen, der der Server vertrauen kann, und es soll Copy-Paste zwischen verschiedenen Minecraft-Generationen überleben. Genau deshalb trennt dieser Builder sichtbaren Namen, versteckte ID und visuellen Hook, statt so zu tun, als müsste ein einziges Feld alles leisten.
Ein Pass aus Papier fühlt sich anders an als ein Buch, eine Uhr oder eine Karotte am Stock. Das Basis-Item steuert noch immer Animation, Stackbarkeit und Spielererwartung, deshalb lohnt es sich, diese Entscheidung zuerst zu treffen.
Hier darf der Text dramatisch, poetisch, fraktionsspezifisch oder questbezogen werden. Das ist die Ebene, die der Spieler wirklich liest, also sollte sie Ton und Sinn schnell transportieren.
Die versteckte ID ist der Teil, dem Quests, Skripte, Admin-Checks und Belohnungsketten vertrauen können. Sie darf langweilig und stabil sein. Ein sichtbarer Titel kann sich ändern; eine Logik-ID sollte das möglichst nicht müssen.
Der Builder hält alte Syntax kompakt und öffnet die reicheren Komponentenfelder nur dann, wenn die gewählte Version sie wirklich versteht. Das verhindert riesige Befehle, von denen sich später die Hälfte als Syntax aus einer anderen Minecraft-Ära entpuppt.
Die meisten RP- und Server-Items landen in einigen wiederkehrenden Familien. Sobald klar ist, zu welcher Familie das aktuelle Item gehört, wirken die Feldentscheidungen nicht mehr zufällig.
Hier sind eine lesbare versteckte ID, ein kurzer sichtbarer Name und keine reine Lore-Validierung wichtig. Ein hübscher Titel lässt sich fälschen; ein versteckter Logikmarker viel schlechter. Wenn das Item außerdem ein spezielles Modell hat, darf die Art sauber in item_model oder im passenden CustomModelData-Hook wohnen.
Solche Items brauchen meist einen klaren Titel, ein bis zwei Lore-Zeilen und eine versteckte ID, die sagt, wozu der Gegenstand Zugang gewährt. Wenn Kapitel oder Fraktion dazugehören, gehört diese Information am besten ebenfalls in die versteckten Daten.
Hier dürfen sichtbarer Name und Lore mehr Atmosphäre tragen. Das Item soll trotzdem maschinenlesbar bleiben, aber Relikte sind einer der seltenen Fälle, in denen der Schreibton genauso wichtig sein kann wie der rohe Befehl.
Wenn das Item in Trades wandert, wird Wiederholbarkeit entscheidend. Der Befehl soll stabil bleiben, die versteckte ID vorhersehbar und der visuelle Hook nicht an einer Zufallszahl hängen, die in sechs Wochen niemand mehr versteht.
So ist sofort klar, ob ihr um altes numerisches CustomModelData oder um moderne Komponenten wie item_model, Strings, Flags und Farbschlitze herum baut. Das hält die ganze Struktur deutlich sauberer.
Das klingt rückwärts, hält aber die Logik stabil. Wenn klar ist, dass das Item wirklich rp.guild.pass oder quest.chapter2.sealed_note ist, kann der sichtbare Titel expressiv werden, ohne die Struktur zu verlieren.
Die Rendering-Schicht soll die Idee des Items unterstützen, nicht allein definieren. Wenn der Modellpfad erst nach der Identität kommt, bleibt der Befehl leichter debuggbar und später einfacher in Trades, Loot oder Quests wiederverwendbar.
Einmal das Item spawnen, sichtbaren Text prüfen, dann das Pack-Modell prüfen und erst danach den Gegenstand in Händler, Quests oder Belohnungslogik hängen. Diese Reihenfolge spart erstaunlich viel Zeit.
Ältere Workflows ließen eine einzige CustomModelData-Zahl gleichzeitig Art-Hook, versteckte Logik, Dokumentation und Admin-Gedächtnisstütze sein. Das funktioniert nur so lange, bis die Item-Liste wächst und niemand mehr weiß, wofür 2047 stand.
Wenn ein Item nur über Namen oder Lore validiert, lässt es sich oft nachahmen. Eine lesbare versteckte ID bietet einen viel saubereren und vertrauenswürdigeren Ort für die systemseitige Identität.
Ein Item kann konzeptionell korrekt sein und trotzdem scheitern, weil eine Legacy-Form in einer Komponentenwelt landet oder umgekehrt. Der Versionsschalter ist da, um genau diese Art Fehler sichtbar zu halten.
Dadurch entstehen meist mehr Umschreibungen als nötig. Es ist einfacher, zuerst das Item zu stabilisieren und dann Händler, Quests und Loot-Systeme auf den finalen Befehl zeigen zu lassen.
Wenn das eigentliche Item der schwierige Teil ist. Die Villager-Seite wird stärker, wenn die Struktur des Händlers die eigentliche Hürde ist. In der Praxis bauen viele das Item zuerst hier und tragen die Werte danach in Trades ein.
Nein. Es ist nur nötig, wenn das Item über eine bestimmte Modellroute gerendert werden soll. Manche Server-Items brauchen nur versteckte ID und sichtbaren Text, gerade wenn die Art-Schicht noch provisorisch ist.
Lesbar gewinnt fast immer. Eine Zeichenkette wie rp.guild.pass lässt sich leichter dokumentieren, durchsuchen und debuggen als eine Zahl, die nur für ihre Erstellerin Sinn ergibt.
Meist eines von drei Dingen: PNG und Modell im Pack-Generator verdrahten, das Item in einen Villager-Trade setzen oder dasselbe Schema versteckter IDs in Quests und Belohnungen weiterverwenden, damit eure Systeme konsistent bleiben.
