Компоненты вместо NBT: всё, что нужно знать о создании предметов в новых версиях Minecraft

Почему этот переход ощущается не как мелкая правка синтаксиса

Много лет у предметов в Minecraft был один понятный позвоночник: NBT. Админы серверов, авторы датапаков, создатели карт и RP-проектов привыкли складывать туда имя, чары, лор, модельки и любые странные крайние случаи. Это было не особенно красиво, но это было знакомо. А потом в 1.20.5 Mojang заменили предметный NBT на компоненты данных, и даже простая команда /give стала выглядеть чужой.

Именно поэтому миграция воспринимается как нечто большее, чем замена фигурных скобок на квадратные. Изменилась сама структура. Раньше данные предмета были похожи на один мешок тегов. Теперь каждая часть живёт в своём именованном компоненте. Для игры это чище, но для человека ломает привычки, старые заметки, старые туториалы и целые архивы рабочих команд.

Что Mojang поменяли на самом деле

В старой системе данные предмета жили внутри одного NBT-блока. Можно было добавлять в него всё новые поля, и если синтаксис не разваливался, команда обычно работала. В новой системе имя предмета - это отдельный компонент. Лор - отдельный компонент. Данные зелья - отдельный компонент. Custom Model Data - тоже отдельный компонент. Именно это делает систему более прозрачной для движка и более предсказуемой в долгую, но в начале она пугает своей строгостью.

Старая команда и современная команда

Одна и та же идея, именованная бумажка с моделью, в двух разных эпохах выглядит так:

/give @p minecraft:paper{CustomModelData:2047,display:{Name:'{"text":"Guild Pass","italic":false}'}}

/give @p minecraft:paper[minecraft:custom_model_data=2047,minecraft:custom_name='{"text":"Guild Pass","italic":false}']

Новая строка сперва кажется более жёсткой, но по смыслу она даже понятнее:

• minecraft:paper по-прежнему задаёт базовый предмет.
• minecraft:custom_model_data=2047 отвечает за визуальный хук.
• minecraft:custom_name=... хранит видимое имя для игрока.
• Каждая роль предмета теперь лежит в своём слоте, а не тонет внутри одного большого NBT-мешка.

Что обычно ломается первым на живом сервере

Когда сервер обновляется, а привычки остаются прежними, ошибки почти всегда скучные, но дорогие по времени:

• в админских заметках по-прежнему лежит {CustomModelData:...}, и команда умирает при первом же вставлении в 1.21.4;
• командные блоки остались в старой эпохе синтаксиса, хотя сама версия сервера уже переехала;
• люди меняют обёртку, но забывают, что имя, лор, зелья и модельные хуки тоже переехали в отдельные компоненты;
• ресурспак уже нарисован, а сама команда на выдачу предмета больше не читается человеком;
• один случайно найденный фикс работает для меча, но снова ломается, когда у предмета появляются лор, эффекты или скрытая логика.

Именно поэтому переход больнее всего бьёт по живым серверам. Это не одна большая драматическая поломка. Это двадцать маленьких мест, где старые привычки перестают быть надёжными.

Где наши инструменты снимают самое неприятное трение

Если писать всё руками, тебе приходится думать о синтаксисе и о дизайне предмета одновременно. Мы как раз стараемся развести эти задачи. Custom Item Builder помогает, когда нужен предмет с видимым именем, скрытым идентификатором и привязкой к модели. Генератор зелий берёт на себя potion_contents. Торги жителей показывают разницу между версиями так, чтобы ты не тащил старую запись в современный командный блок.

Смысл не в том, чтобы никогда ничего не понимать. Смысл в том, чтобы не тратить часы на скобки и кавычки в тот момент, когда ты ещё только придумываешь сам предмет.

Практичный порядок миграции, который тратит меньше нервов

1. Начни с одного реального предмета, а не со всего архива. Лучше всего с токена, пропуска или книги.
2. Сначала добей базовый предмет, имя и лор в новом синтаксисе.
3. Потом верни визуальный хук, через minecraft:custom_model_data или уже через более современный item model workflow.
4. Только после этого переходи к зельям, торгам и более сложной логике.
5. Держи старую и новую версию рядом во время тестов. Когда сравниваешь один предмет, сразу видно, что именно переехало.

Типичные ошибки при переходе от NBT к компонентам

• Относиться к компонентам как к просто переименованному NBT: названия изменились, но важнее то, что изменилась сама форма хранения данных.
• Пытаться держать всё в голове: это самый быстрый путь к кривым командам.
• Смешивать туториалы разных эпох: старые гайды по-прежнему ранжируются, хотя больше не соответствуют новым версиям.
• Хранить логику только в видимом тексте: чем крупнее проект, тем важнее читаемые скрытые ID.
• Сначала мигрировать красивую картинку, а потом думать о команде: игроку не поможет прекрасная моделька, если предмет нельзя корректно выдать.

Практический вывод

Mojang не просто перекрасили синтаксис предметов. Они поменяли сам способ думать о предмете. Старый NBT позволял свалить всё в одну кучу тегов. Компоненты предлагают разложить ответственность по зонам: имя, лор, визуал, эффекты, характеристики и скрытая логика. Когда это понимаешь, новая система перестаёт казаться враждебной. Она становится строгой, а строгая система в долгую куда легче поддерживается на живом сервере.

Для no-mod RP-проекта это особенно полезно. Так предметы проще документировать, проще переиспользовать в наградах, торговцах и паке, и проще поддерживать спустя месяцы, когда уже никто не помнит, почему в старом блоке была именно такая мешанина тегов.

Часто задаваемые вопросы (FAQ)