Сначала определите само решение, а уже потом файл
В 1.21.4+ item definition — это не про длинный JSON ради самого JSON. Это про вопрос: предмет всегда выглядит одинаково, переключается по одному свойству, меняется по числовым порогам или реагирует на простое true/false? Когда этот вопрос ясен, сама структура файла внезапно становится спокойнее.
Именно здесь конструктор и помогает. Он не придумывает логику за вас, а держит каркас коротким, заранее показывает будущий путь файла и подталкивает к тому типу ветвления, который действительно подходит задаче.
Быстрая карта выбора перед первым кликом
| Ветка | Когда подходит | Главный сигнал |
|---|---|---|
minecraft:model | Нужен один фиксированный внешний вид. | На деле никакого дерева решений нет. |
minecraft:select | Одно именованное свойство выбирает между ветками. | Состояния можно назвать словами вроде pass, relic, broken, ritual. |
minecraft:range_dispatch | Число проходит через пороги. | Есть стадии, заряд, износ или прогресс. |
minecraft:condition | Результат зависит от true/false. | Предмет выбран, используется, повреждён или иным образом бинарен. |
Практический пример: один реликт, три состояния
Представьте сюжетный предмет, который большую часть времени должен выглядеть запечатанным, во время ритуала светиться, а после события треснуть. Это не три случайных файла, а одно дерево решений. Если состояние идёт из строкового custom-значения, вы уже почти наверняка смотрите в сторону
select.Конструктор здесь полезен тем, что держит дерево читаемым: сначала выбираете тип ветвления, фиксируете fallback, а потом добавляете именованные состояния. Сложность не в печати. Сложность в том, чтобы команда через неделю всё ещё понимала, что делает этот definition-файл.
Безопасный workflow внутри конструктора
- Сначала задайте путь файла внутри
assets/<namespace>/items/. - Выберите самый маленький тип ветвления, который реально описывает предмет.
- Настройте fallback до всех красивых ответвлений.
- Используйте quick starts, если уже ясно, что у вас прямой model, переключение по состояниям или лестница порогов.
- Скопируйте JSON, проверьте один предмет в игре и только потом размножайте паттерн по паку.
Когда пора переключаться на другой инструмент
Item model builder отвечает за визуальный definition-слой. Если вам ещё нужна /give-команда для самого предмета, переходите в custom item builder. Если текстуры и модели ещё надо собрать в браузерный ресурс-пак, закрывайте этот шаг в генераторе паков.
Такой разделённый workflow полезен: визуальный definition проще отлаживать, когда pack-side и командная логика не свалены в один клубок.
Типичные ошибки
- Брать
selectпросто потому, что он кажется “правильнее”, хотя хватило бы обычногоmodel. - Пропускать fallback и ломать читаемость файла с первой же строки.
- Смешивать числовые и именованные ожидания в одном definition, не решив, какое свойство вообще главное.
- Называть JSON-файл, model path и внутренний ярлык команды так по-разному, что связь между ними исчезает.
- Копировать ветки сразу на много предметов, не проверив один живой пример в игре.
FAQ
Нужен ли select всегда, если речь про CustomModelData?
Нет. Если у предмета только один внешний вид, прямой model-файл чище. select нужен тогда, когда один definition действительно должен ветвиться на несколько обликов.
Когда range_dispatch лучше?
Когда изменение упорядочено и числовое: стадии урона, заряд, шкала прогресса или любое состояние с порогами.
Почему так важно начать с fallback?
Потому что fallback — это спокойное базовое чтение предмета. Когда опора выставлена правильно, все остальные ветки проще оценивать.
Можно ли держать item-команду отдельно от definition-файла?
Да, и это одно из лучших качеств новой системы. Визуальный файл не обязан тащить на себе ещё и командную сторону.
А если мне нужен просто красивый пропуск на базе paper?
Тогда почти наверняка достаточно прямого minecraft:model-файла. Не раздувайте дерево решений там, где сама задача маленькая.