Создавайте готовые команды /give для RP-предметов, квестовых наград и пропусков. Этот конструктор учитывает разницу версий: вы можете использовать компактный старый синтаксис или новые слоты item_model, custom_data и custom_model_data для 1.21.4+.
Версия: 1.21.4+. Длина: 0 символов.
Конструктор специально оставляет старый синтаксис компактным. При переключении на 1.21.4+ команда расширяется в новый компонентный формат.
Кастомный предмет почти всегда делает три работы сразу. Он должен правильно выглядеть в инвентаре, нести скрытую идентичность, которой сервер может доверять, и переживать копирование команды между разными поколениями Minecraft. Именно поэтому этот билдер отделяет видимое имя, скрытый ID и визуальный хук, а не притворяется, будто одно поле должно делать всё.
Пропуск из бумаги ощущается не так, как книга, часы или морковь на палке. База всё ещё определяет анимацию, стакуемость и ожидания игрока, поэтому её лучше решить сначала, а не относиться к ней как к случайной заглушке.
Именно здесь можно позволить себе драму, поэзию, фракционный оттенок или квестовую интонацию. Это слой, который игрок реально читает, и он должен быстро сообщать настроение и смысл.
Скрытый ID — это часть, которой смогут доверять ваши квесты, скрипты, админские проверки и цепочки наград. Пусть он будет скучным и стабильным. Заголовок для игрока может меняться. Логический ID — лучше нет.
Билдер держит старый синтаксис компактным и раскрывает богатые компонентные поля только там, где версия их действительно понимает. Это спасает от ситуации, когда вы собрали гигантскую команду, а потом оказалось, что половина её принадлежит другой эпохе Minecraft.
Большинство RP- и серверных предметов сводятся к нескольким повторяемым семействам. Как только вы понимаете, к какому семейству относится текущая вещь, поля перестают казаться произвольными.
Здесь полезны читаемый скрытый ID, короткое видимое имя и отказ от валидации только по lore. Красивый заголовок легко подделать. Скрытый логический маркер — нет. Если у предмета ещё и отдельная модель, арт лучше держать в item_model или соответствующем хуке CustomModelData.
Такие предметы обычно хотят чистого названия, одной-двух строк lore и скрытого ID, который говорит, к чему именно этот предмет открывает доступ. Если доступ завязан на главу сюжета или фракцию, это полезно хранить и во внутренних данных, а не только в тексте.
Здесь уже видимое имя и lore могут нести больше атмосферы. Предмет всё ещё должен оставаться машиночитаемым, но реликвии — редкий случай, где стиль текста действительно равен по важности самой команде.
Если предмет идёт в торговлю, важнее всего повторяемость. Команда должна быть стабильной, скрытый ID — предсказуемым, а визуальный хук не должен зависеть от того, вспомнит ли кто-нибудь через шесть недель, что означало случайное число.
Это сразу говорит, строите ли вы предмет вокруг старого числового CustomModelData или вокруг современных компонентов вроде item_model, строк, флагов и цветовых слотов. Намного проще оставаться чистой, когда эпоха команды решена заранее.
Звучит наоборот, но это удерживает логику стабильной. Когда уже ясно, что предмет на самом деле rp.guild.pass или quest.chapter2.sealed_note, можно позволить себе выразительное название для игрока, не теряя структуры.
Слой рендера должен поддерживать идею предмета, а не определять её. Если модельный путь добавляется после того, как идентичность уже зафиксирована, команду проще отлаживать и повторно использовать в торговле, луте или наградах.
Один раз выдать предмет, проверить видимый текст, потом проверить модель из пака — и только после этого отдавать его квесту, жителю или сундуку с наградами. Такой порядок экономит неожиданно много времени.
Старые workflow часто заставляли одно значение CustomModelData быть и визуальным хуком, и скрытой логикой, и системой документации. Это работает до тех пор, пока список предметов не становится большим, а потом никто уже не помнит, что означало 2047.
Если предмет валидируется только по названию или lore, игроки чаще могут его имитировать. Читаемый скрытый ID даёт гораздо более чистое и надёжное место для логической идентичности.
Предмет может быть концептуально правильным и всё равно ломаться просто потому, что legacy-форма вставлена в компонентную среду или наоборот. Переключатель версии здесь как раз для того, чтобы эту ошибку делать видимой.
Так обычно рождается больше переделок, чем нужно. Гораздо легче сначала стабилизировать сам предмет, а уже потом указывать на него торговлей, квестами и лут-системами.
Когда сложнее всего именно сам предмет. Страница жителей сильнее там, где трудна структура торговца. На практике многие сначала собирают предмет здесь, а потом переносят финальные значения в торговлю.
Нет. Он нужен только тогда, когда предмет должен рендериться по конкретному маршруту модели. Некоторым серверным предметам достаточно скрытого ID и видимого текста, особенно если визуальный слой пока временный.
Почти всегда лучше читаемый. Строка вроде rp.guild.pass проще документируется, ищется и отлаживается, чем число, понятное только тому, кто его придумал.
Обычно один из трёх шагов: подвязать PNG и модель в генераторе ресурспаков, перенести предмет в торговлю жителя или использовать ту же схему скрытых ID в квестах и наградах, чтобы системы оставались согласованными.
