Сначала думайте о сигнале, а не о синтаксисе
Прежде чем выбирать ветку, задайте простой вопрос: предмет всегда выглядит одинаково, переключается между именованными состояниями, проходит числовые пороги или реагирует на условие да/нет? Именно это, а не длина JSON, должно решать структуру.
Многие definition становятся тяжелее, чем нужно, потому что автор сразу тянется к самой гибкой ветке. Гибкость звучит безопасно, но чаще всего это просто лишнее дерево там, где предмету хватило бы куда более простой логики.
Быстрая таблица выбора
| Ветка | Когда подходит | Типичный случай |
|---|---|---|
minecraft:model | У предмета один постоянный вид. | Проп, пропуск, реликт без состояний. |
minecraft:select | Есть именованные состояния. | sealed, awakened, broken, cursed. |
minecraft:range_dispatch | Есть числовые пороги. | Заряд, прогресс, полосы прочности. |
minecraft:condition | Есть логика true/false. | Выбран предмет, используется, поврежден или нет. |
Три словесных теста
- Если вы описываете смену вида словами вроде ритуальный, сломанный, активный, это почти всегда
select. - Если вы мыслите порогами 0-25-50-75, это обычно
range_dispatch. - Если предмет либо в состоянии, либо нет — скорее всего хватит
condition.
Три примера, которые быстро расставляют всё по местам
1. Реликт с сюжетными состояниями
Если у реликта есть состояния sealed, glowing и cracked, это именованные ветки. Значит, логичнее всего идти в select.
2. Посох, который набирает заряд
Если внешний вид меняется по ступеням заряда, это уже история про числовые пороги и range_dispatch.
3. Карта, которая меняется только в руках
Если альтернативный вид нужен только когда предмет выбран или используется, чаще всего достаточно condition.
Где чаще всего переусложняют
- Берут
selectдля предмета, которому хватило бы одногоmodel. - Используют
range_dispatchтам, где состояние на самом деле именованное, а не числовое. - Раздувают бинарную логику на много ветвей и делают дебаг тяжелее, чем сам предмет.
- Забывают, что fallback — это не только защита, но и часть читаемости файла.
Чем тут помогает builder
Item model builder особенно полезен в момент, когда решение почти понятно, а вот обертку вручную собирать уже не хочется. Он позволяет выбрать ветку, сразу удержать fallback на виду, добавить кейсы в правильном порядке и быстро проверить, не стала ли структура слишком тяжелой.
Это особенно ценно при миграциях: можно спокойно собрать один definition, убедиться, что ветка подобрана правильно, и только потом переносить тот же паттерн на семейство предметов.
FAQ
В 1.21.4+ всегда нужен branching?
Нет. Очень многим предметам всё ещё хватает одного прямого model.
Можно ли сочетать именованные состояния и числовые стадии?
Да, но тогда особенно важно сначала выбрать самый простой внешний уровень логики, а не наслаивать всё подряд в первый черновик.
Стоит ли решать ветку до текстуры?
Обычно да. Визуал может прийти позже, а вот принцип смены вида лучше понять заранее.