Проблема систем, построенных только на числах
Числа хорошо подходят для рендеринга, но плохо — для памяти. Документация команды превращается в гигантские таблицы соответствий, старые ID случайно переиспользуются, а отладка сломанной квестовой награды занимает больше времени, чем должна.
Держите отдельный читаемый слой идентичности
Даже если визуальный конвейер модели всё ещё ссылается на число, ваш серверный workflow должен также хранить строковый ID вроде rp.guard.badge_bronze или quest.chapter3.letter_mayor. Эта строка может жить в minecraft:custom_data, пока видимый арт продолжает использовать custom_model_data.
Безопасный комбинированный паттерн
components:{
"minecraft:custom_model_data":2047,
"minecraft:custom_data":{
item_id:"rp.guard.badge_bronze",
issue:"capital_watch"
}
}Почему это лучше масштабируется
| Вопрос | Только число | Число + строковый ID |
|---|---|---|
| "Что такое предмет 2047?" | Искать в таблице, надеяться, что она актуальна. | Прочитать rp.guard.badge_bronze прямо из предмета. |
| Два сотрудника случайно переиспользовали значение | Тихая визуальная коллизия, обнаруженная в игре. | Дубликат строкового ID легко найти grep'ом до релиза. |
| Сделке или квесту нужно проверить предмет | Сверка по номеру модели, который меняется вместе с артом. | Сверка по стабильной строке, независимой от будущей перерисовки текстуры. |
- Арт-команда может искать читаемые ID в документации.
- Квестовую логику проще проверять.
- Старые предметы реже путают с тестовыми ассетами.
- Сделки и награды могут проверять скрытую строку, а не только видимую модель.
Рекомендуемая стратегия именования
- Используйте неймспейсы по системам:
rp.,quest.,shop.,faction. - Держите токены читаемыми и стабильными.
- Избегайте пробелов и переведённых названий в скрытом ID.
- Пусть видимый текст остаётся локальным и красивым, а скрытый ID — скучным.
Это тот же инстинкт, что стоит за полноценной системой именования кастомных предметов в целом — смотрите как называть кастомные предметы Minecraft без дубликатов про более общий паттерн (категория + семейство + вариант), в который и должен вписываться такой строковый ID.
Где число всё ещё нужно
Числовая ссылка на модель всё ещё важна для рендеринга и организации пака. Смысл не в том, чтобы отказаться от неё, а в том, чтобы перестать считать одно целое число единственной админ-дружелюбной идентичностью предмета.
Рекомендуемый серверный workflow
- Назначьте значение модели для арта.
- Назначьте строковый ID для логики.
- Используйте строковый ID в документации, магазинах и проверках.
- Держите число в основном как деталь рендеринга пака.
Часто задаваемые вопросы
Замедляет ли custom_data рендеринг?
Нет. custom_model_data всё так же управляет поиском модели, как и раньше; custom_data — это инертные дополнительные данные, которые клиенту не нужны для рендеринга чего-либо, поэтому визуально это ничего не стоит.
Можно ли добавить строковый ID к предметам, у которых уже есть только число?
Да, ретроактивно это нормально. Существующие предметы продолжают работать с одним числом; читаемый ID вы получаете только на предметах, которые обновите или переиздадите в будущем.
Стоит ли показывать строковый ID игрокам?
Как правило нет — держите его в custom_data, который по умолчанию не отображается во всплывающей подсказке. Видимое имя и лор остаются чисто косметическими и могут меняться свободно, не затрагивая скрытую идентичность.
Что если два разных предмета законно делят один номер модели?
Это именно тот случай, для которого нужен строковый ID. Номер модели можно переиспользовать для визуально идентичных предметов; строковый ID — это то, что сообщает вашим системам, что это не один и тот же объект.
Что дальше
Про сам принцип именования — категория, семейство, вариант — смотрите как называть кастомные предметы Minecraft без дубликатов. Чтобы собрать полную команду выдачи вокруг такого предмета, каталог кастомных предметов держит ID, видимые имена и слоты CustomModelData в одном месте.