Что такое NBT Ingredient Predicate и зачем он нужен в рецептах
Если вы собираете модпак, пишете датапаки и настраиваете кастомный крафт в Minecraft, рано или поздно вы сталкиваетесь с тем, что предметы отличаются не только ID, но и NBT: зачарования, названия, описание (lore), теги, данные блоков. Обычная проверка ингредиента в рецепте может требовать полного совпадения NBT — и тогда два «одинаковых» по смыслу предмета вдруг перестают подходить друг к другу. Именно здесь на сцену выходит подход с NBT Ingredient Predicate: он позволяет описать условие «мягче», чем жёсткое равенство всех тегов.
Жёсткое совпадение и типичная боль модпакеров
В экосистеме модов и датапаков часто встречается схема, где ингредиент проверяется через что-то вроде forge:nbt (или аналогичные механики «полного NBT»). Такой вариант удобен, когда нужно точное совпадение: например, только конкретный предмет с конкретным набором данных. Но в сценариях кастомных рецептов это превращается в ловушку: достаточно добавить к предмету одну строку lore или служебный тег — и рецепт «ломается», хотя для геймдизайна оба варианта должны считаться одним и тем же ингредиентом.
Для модпаков, где игроки переименовывают предметы, получают их из квестов или объединяют несколько источников с разным NBT, нужна другая логика: не «всё должно совпасть побитово», а «должны присутствовать нужные фрагменты NBT».
Мягкое включение: nbt_ingredient_predicate:nbt_includes
Ключевая идея — заменить проверку жёсткого равенства на мягкое включение (soft-including). Вместо того чтобы требовать полное совпадение NBT, вы можете использовать nbt_ingredient_predicate:nbt_includes, чтобы задать условие вида: «в NBT ингредиента должны присутствовать указанные поля/значения», даже если рядом есть дополнительные данные.
Это особенно полезно, когда вы хотите, чтобы в рецепте участвовали, например, два варианта одного и того же блока: базовый и с дополнительным текстом в lore. С жёсткой проверкой часто проходит только «чистый» вариант; с nbt_includes вы формулируете правило так, чтобы оба варианта удовлетворяли условию, если содержат нужный минимум информации — например, совпадает тип блока и ключевые поля, а «лишний» lore не выбивает рецепт из списка допустимых.
Практика для датапаков: что именно вы выигрываете
Если вы собираете рецепты через датапаки и хотите частичное совпадение NBT, логика становится ближе к реальным игровым ситуациям: игрок приносит предмет из разных источников, а крафт остаётся стабильным. Это снижает количество «невидимых» отказов в верстаке и уменьшает необходимость плодить дублирующие рецепты на каждый микроскопический вариант NBT.
Когда вы тестируете подобные связки модов и датапаков, удобно иметь лаунчер, который не мешает быстро переключать профили и наборы модов. Кстати, если вы подключаете инструменты для гибкой работы с рецептами и NBT, такой мод можно без лишних шагов поставить через лаунчер foxygame.net: это удобный и современный лаунчер для Minecraft с гибкими настройками профиля, где моды можно подтягивать прямо из меню, не собирая установку вручную по отдельным архивам.
Как это читать «по-человечески» в примере с аметистом
Представьте ситуацию из практики: у вас есть два «именованных» блока аметиста, и визуально/по назначению это один и тот же ингредиент, но один из них содержит lore-текст. При жёстком равенстве NBT игра может требовать строго один вариант. С подходом nbt_includes вы задаёте правило так, чтобы для крафта подходили оба варианта — например, когда вам нужно, чтобы результат (условный алмаз в тестовом примере) получался независимо от того, есть ли у блока дополнительное описание, пока выполняется ваша логика совпадения.
- Меньше дублей рецептов: один рецепт покрывает несколько «почти одинаковых» предметов.
- Предсказуемость для игрока: меньше ситуаций «предмет похож, но крафт не срабатывает».
- Контроль для автора модпака: вы явно решаете, какие части NBT важны, а какие можно игнорировать.
На что обратить внимание при настройке
Мягкое включение — мощный инструмент, но его стоит применять осознанно. Если условие слишком широкое, вы случайно разрешите не те предметы; если слишком узкое — вернётесь к проблеме «жёсткого» крафта. Поэтому в датапаках полезно проверять крайние случаи: предметы из разных модов, с разными дополнительными полями, а также сценарии после обновления версии Minecraft, когда формат NBT или имена тегов могут меняться между релизами.
Вывод: когда выбирать мягкое NBT-сопоставление
NBT Ingredient Predicate с nbt_ingredient_predicate:nbt_includes — это практичный ответ на задачу частичного совпадения данных ингредиента в кастомных рецептах. Он помогает модпакерам и авторам датапаков отойти от «побитового» равенства там, где важнее смысл предмета, а не идентичность всего NBT. Если вы строите сложные цепочки крафта, квестовые награды и предметы с описаниями, такой подход делает рецепты устойчивее и ближе к ожиданиям игроков — при этом сохраняя контроль: вы сами определяете, какие части NBT являются обязательными для прохождения проверки.