- Для версий
- 1.20.+
- 1.21.+
TooManyRecipeViewers для Minecraft: совместимость JEI-плагинов с EMI без установки JEI
TooManyRecipeViewers, или TMRV, — это мод-слой совместимости для Minecraft, который позволяет запускать плагины JEI в EMI без обязательной установки самого JEI. Главная польза такого решения — более быстрый вход в мир, лучшая эффективность по сравнению с JEMI и более широкое покрытие JEI API в ряде сценариев.Если вам нужна совместимость JEI и EMI без лишней нагрузки, TMRV выглядит как точечный и технически продуманный инструмент. При этом важно понимать его границы: для работы нужен установленный EMI, некоторые возможности JEI остаются ограниченными, а сам проект использует иной подход, чем встроенный в EMI слой JEMI.
Суть и польза: что такое TooManyRecipeViewers и кому он подходит
TooManyRecipeViewers создан для одной конкретной задачи: запускать JEI-плагины в среде EMI, не устанавливая JEI как обязательную часть связки. По сути, это совместимый слой, который пытается заменить JEI API там, где это возможно, и напрямую сопоставляет вызовы JEI с API EMI. За счёт этого TMRV выступает не как обычная прокладка, которая сначала полностью разворачивает JEI, а затем импортирует данные, а как более прямой и лёгкий путь интеграции.Такой подход полезен прежде всего пользователям и сборкам, где важны скорость загрузки мира, экономия памяти и совместимость модов, ориентированных на JEI-плагины. Если вы используете EMI и хотите запускать плагины JEI без полной зависимости от JEI, TMRV закрывает именно этот сценарий. Это особенно актуально в тяжёлых модпаках, где каждая лишняя инициализация влияет на запуск мира и общее потребление ресурсов.
Главное отличие TMRV от JEMI заключается не только в самом факте совместимости, а в философии реализации. JEMI, встроенный в EMI, задуман как максимально простой слой, который опирается на внутренности JEI и сначала заставляет JEI обработать рецепты, а уже потом переносит их в EMI. TMRV старается идти другим путём: он не хочет полагаться на полную загрузку реестра JEI там, где можно обойтись прямым преобразованием API-вызовов. Отсюда и его основное преимущество — эффективность.
Однако такой выигрыш даётся не бесплатно. Поддержка TMRV требует существенно больше усилий, чем поддержка JEMI. Автор прямо подчёркивает, что это более трудоёмкий путь, и никто не должен ожидать, что EMI будет вкладывать такой же объём работы в поддержку API, который изначально не учитывался при проектировании. Поэтому TMRV полезен тем, кто осознанно выбирает производительность и расширенную совместимость, понимая, что цена этого подхода — более сложное сопровождение самого проекта.
Отдельно важно помнить о лицензии. В описании проекта отдельно отмечено, что использование мода в любой форме означает явное согласие с условиями его лицензии. Для пользователя это не техническая мелочь, а базовое условие использования проекта.
Основные характеристики и как работает TMRV
Техническая сила TooManyRecipeViewers проявляется в двух ключевых направлениях: совместимость плагинов и эффективность работы. Именно эти два аспекта автор прямо называет главными преимуществами перед JEMI.С точки зрения совместимости TMRV покрывает JEI API шире, чем JEMI, хотя есть и отдельные исключения, перечисленные в ограничениях. На момент описания мод поддерживает более качественное преобразование встроенных типов рецептов. Если JEMI работает только с crafting и info recipe types, то TMRV заявляет поддержку всех встроенных типов рецептов JEI. Кроме того, указана поддержка alias для ингредиентов и поиска, а также поддержка createRecipeExtras. Для многих сборок это важнее, чем кажется на первый взгляд: проблема совместимости часто проявляется не в базовом открытии рецептов, а в деталях интерфейса и обработке специфических данных.
Второе направление — производительность. Здесь логика TMRV особенно заметна. При использовании JEMI инициализация JEI-плагинов блокирует загрузку мира: игрок не начинает играть, пока процесс не завершится. EMI, напротив, умеет загружать плагины асинхронно уже после открытия мира. TMRV использует именно этот подход, поэтому даже в гипотетической ситуации, если бы плагины JEI обрабатывались медленнее, чем у JEI, сам мир всё равно открывался бы раньше, чем в связке с JEMI. Но автор отмечает, что на практике TMRV загружает их ещё и измеримо быстрее.
Причина этого выигрыша — отказ от лишних промежуточных этапов. TMRV не инициализирует и не хранит полноценный реестр рецептов JEI там, где это не нужно. Вместо этого мод конвертирует вызовы JEI API в вызовы EMI API и преобразует ответы обратно в формат JEI. Автор предлагает понятную аналогию: TMRV относится к задаче как Wine или Proton, тогда как JEMI больше похож на виртуальную машину. Это сравнение хорошо объясняет суть: TMRV не тащит весь «настоящий» JEI за собой, а пытается переводить запросы напрямую.
С этим связана и важная оговорка. Поскольку JEMI использует реальный JEI, возможны сценарии, где TMRV выдаст ошибку, а JEMI внешне будет выглядеть рабочим. Но это не всегда означает, что JEMI действительно корректно поддерживает такой случай — иногда он лишь создаёт видимость поддержки. В большинстве обычных сценариев TMRV всё равно должен быть эффективнее.
В описании приведены и конкретные бенчмарки. По времени загрузки мира разница заметна:
- Craftoria: TMRV — 3201 мс, JEMI — 8277 мс, разница — 5076 мс
- ATM10: TMRV — 7484 мс, JEMI — 18658 мс, разница — 11174 мс
- ATM9: TMRV — 32392 мс, JEMI — 49409 мс, разница — 17017 мс
- Craftoria: 2.722 GiB против 2.872 GiB
- ATM10: 3.580 GiB против 4.491 GiB
- ATM9: 4.345 GiB против 5.939 GiB
Как выбрать: критерии и практичный чек-подход
Выбирать TooManyRecipeViewers стоит не по принципу «что новее», а по тому, какой именно сценарий у вас в модпаке и что для вас важнее: максимальная простота встроенного решения или более эффективная совместимость JEI-плагинов с EMI.Первый критерий — используете ли вы EMI. Это обязательная отправная точка. В описании прямо сказано: для работы TMRV нужен установленный EMI. Без него мод не имеет смысла. Поэтому если ваша сборка не использует EMI, рассматривать TooManyRecipeViewers как решение совместимости не стоит.
Второй критерий — насколько важна производительность. Если сборка тяжёлая, запуск мира долгий, а потребление памяти уже близко к пределу, TMRV выглядит особенно выгодно. Его подход позволяет быстрее входить в мир и уменьшать нагрузку на систему по сравнению с JEMI. Для крупных паков это может быть одним из главных доводов в пользу выбора.
Третий критерий — какие именно JEI-плагины и функции вам нужны. Если вы опираетесь на built-in recipe types JEI шире, чем просто crafting и info, TMRV предлагает более полное покрытие. То же относится к alias-поиску ингредиентов и createRecipeExtras. Если ваш сценарий затрагивает эти вещи, TooManyRecipeViewers потенциально даст лучший результат, чем JEMI.
Четвёртый критерий — готовность мириться с известными ограничениями. У TMRV есть чётко обозначённые границы. Он почти полностью игнорирует конфигурационные файлы JEI, кроме .minecraft/config/jei/blacklist.json. Он не планирует полноценно поддерживать Recipe Manager Plugins, не поддерживает расширения vanilla-категорий Crafting и Smithing и не допускает runtime-изменения реестров после вызова IModPlugin.onRuntimeAvailable. Если сборка зависит именно от таких сценариев, нужно учитывать этот момент заранее.
Пятый критерий — степень важности прямой «настоящей» совместимости JEI. JEMI использует реальный JEI, поэтому в некоторых спорных случаях он может выглядеть устойчивее. Но если вам важнее оптимизация и современная интеграция с EMI, чем буквальная опора на внутренности JEI, TMRV выглядит сильнее.
Практический чек-подход можно сформулировать так:
- у вас уже стоит EMI;
- вы хотите запускать JEI-плагины без установки JEI;
- вам важны скорость входа в мир и меньший расход памяти;
- вам полезно более широкое покрытие JEI API;
- ваша сборка не завязана на устаревшие или специфические возможности JEI, которые TMRV не поддерживает.
Пошагово: как использовать TooManyRecipeViewers правильно
Работа с TMRV начинается с понимания базовой зависимости. Первое, что нужно сделать, — убедиться, что EMI уже установлен. Это обязательное условие, прямо указанное в описании проекта. TooManyRecipeViewers не заменяет EMI и не работает сам по себе как отдельный просмотрщик рецептов. Он нужен именно как совместимый слой между JEI-плагинами и EMI.После этого важно определить цель установки. Если вы хотите просто использовать JEI-плагины в окружении EMI без установки JEI, TMRV подходит под этот сценарий напрямую. Если же вы ожидаете полного повторения всех возможностей JEI, включая его конфигурационную систему и runtime-изменения реестров, лучше заранее скорректировать ожидания. Мод целенаправленно не поддерживает ряд вещей, которые автор считает либо устаревшими, либо несовместимыми с архитектурой EMI.
Следующий шаг — проверить, насколько ваша сборка зависит от специальных API-возможностей JEI. В обычных сценариях TMRV выигрывает за счёт прямого сопоставления JEI API и EMI API. Но если конкретный мод использует Recipe Manager Plugins, расширения vanilla-категорий Crafting или Smithing, либо активно меняет реестры уже во время выполнения, возможны ограничения. На практике это означает простое правило: чем ближе плагин к стандартным возможностям JEI, тем выше шанс, что TMRV покажет себя с лучшей стороны.
Дальше стоит обратить внимание на конфигурацию скрытия ингредиентов. TMRV читает только файл blacklist.json из конфигурации JEI. Этот механизм рассматривается как временный стоп-gap для сборок, переходящих с JEI. Если вы хотите скрывать ингредиенты на постоянной основе, сам автор рекомендует использовать собственную конфигурацию EMI, а не рассчитывать на файлы JEI. Это важный практический момент: правильнее сразу настраивать интерфейс через родные механизмы EMI, а не пытаться переносить старую конфигурационную логику без изменений.
После установки и запуска сборки есть смысл оценить поведение именно в реальной загрузке мира. Одна из главных сильных сторон TMRV в том, что мир открывается быстрее, а инициализация плагинов происходит уже после входа. Для пользователя это означает простой, но ощутимый эффект: играть можно раньше, не дожидаясь полной блокирующей инициализации JEI-плагинов, как в случае с JEMI.
Наконец, важно не игнорировать лицензионное уведомление проекта. В тексте прямо указано, что использование проекта в любой форме означает явное согласие с условиями лицензии. Для модпаков и публичных сборок это особенно важно, потому что вопрос лицензий здесь не формальность, а часть корректного использования проекта.
Частые ошибки и как их избежать
Одна из самых типичных ошибок — устанавливать TMRV без EMI. Это базовое несоответствие, которое делает мод бесполезным, потому что сам TooManyRecipeViewers не является автономной заменой EMI. Правильный подход прост: сначала проверяется наличие EMI, и только после этого имеет смысл подключать слой совместимости.Вторая ошибка — ожидать, что TMRV будет полностью повторять JEI во всех мелочах. Автор проекта прямо показывает обратное: мод стремится заменить JEI API там, где это целесообразно, а не копировать весь JEI как есть. Поэтому воспринимать его как «JEI без JEI, но со стопроцентной идентичностью» — неверно. Если изначально подходить к нему как к эффективному совместимому слою, а не как к буквальному клону, оценка будет гораздо точнее.
Третья ошибка — использовать конфиги JEI так, как будто они полностью поддерживаются. На деле TMRV читает только blacklist.json, а остальные файлы конфигурации JEI игнорирует. Если продолжать опираться на старую структуру конфигов, можно получить путаницу в скрытии ингредиентов и настройках отображения. Решение здесь прямое: использовать настройки EMI для того, что относится к EMI.
Четвёртая ошибка — делать ставку на Recipe Manager Plugins как на полноценный поддерживаемый сценарий. В описании прямо сказано, что TMRV попытается извлечь рецепты из таких плагинов, но для большинства из них это не работает корректно и не считается полноценной поддержкой. Если сборка зависит от такого механизма, лучше не строить ожидания на том, что всё заработает без ограничений.
Пятая ошибка — не учитывать запрет на runtime-изменения реестров после IModPlugin.onRuntimeAvailable. В архитектуре JEI это допускается, но с EMI такой подход не совместим. Поэтому TMRV после этого этапа выбрасывает IllegalStateException при попытке изменить реестр в рантайме. Для разработчиков и сборщиков это важный нюанс: если сценарий завязан на динамическую перестройку реестров, проект сознательно не будет его поддерживать.
Шестая ошибка — считать, что если JEMI внешне не падает, то он всегда поддерживает ситуацию лучше. Сам автор отдельно предупреждает: иногда JEMI просто выглядит рабочим за счёт использования реального JEI, но это не всегда означает корректную поддержку. Поэтому оценивать стоит не только факт отсутствия ошибки, но и качество, скорость и логичность общего поведения.
FAQ
Что такое TooManyRecipeViewers и зачем он нужен?TooManyRecipeViewers, или TMRV, — это слой совместимости, который позволяет запускать JEI-плагины в EMI без необходимости устанавливать сам JEI. Он нужен тем, кто хочет использовать инфраструктуру EMI, но при этом сохранить работоспособность модов и плагинов, рассчитанных на JEI. Основные причины выбрать его — более быстрая загрузка мира, меньший расход памяти и более широкое покрытие JEI API по сравнению с JEMI в ряде случаев.
Нужен ли EMI для работы TMRV?
Да, EMI обязателен. В описании проекта это указано прямо и без оговорок. TMRV не является самостоятельным модом для просмотра рецептов, а работает именно как совместимый слой поверх EMI. Если установить только TooManyRecipeViewers без EMI, он не выполнит свою задачу, потому что ему не с чем сопоставлять JEI API.
Чем TMRV отличается от JEMI?
Главное отличие в архитектуре. JEMI встроен в EMI и старается максимально просто использовать внутренности JEI: сначала JEI обрабатывает данные рецептов, затем они импортируются в EMI. TMRV идёт по другому пути и, где это возможно, заменяет JEI API прямыми мапперами к API EMI. За счёт этого он обычно эффективнее, быстрее загружает мир и требует меньше памяти, но поддерживать его технически сложнее.
Почему TMRV считается более эффективным?
Потому что он не заставляет систему полностью разворачивать и хранить полноценный реестр рецептов JEI там, где это не нужно. Вместо этого вызовы JEI преобразуются в вызовы EMI, а ответы — обратно в формат JEI. Дополнительно JEI-плагины не блокируют вход в мир на стадии загрузки так, как это происходит с JEMI. В результате пользователь начинает играть раньше, а общая нагрузка на систему становится ниже.
Какие преимущества TMRV даёт по совместимости?
Автор прямо выделяет несколько преимуществ. Во-первых, TMRV лучше конвертирует встроенные типы рецептов JEI: не только crafting и info, но все built-in recipe types JEI. Во-вторых, поддерживаются alias для ингредиентов и поиска. В-третьих, есть поддержка createRecipeExtras. Всё это делает проект более интересным для тех сборок, где важны не только базовые рецепты, но и дополнительные возможности экосистемы JEI.
Есть ли у TMRV ограничения по API?
Да, и они обозначены достаточно чётко. Мод почти полностью игнорирует конфигурационные файлы JEI, кроме blacklist.json. Полноценная поддержка Recipe Manager Plugins не планируется. Также не поддерживаются расширения vanilla-категорий Crafting и Smithing. Кроме того, runtime-изменения реестров после IModPlugin.onRuntimeAvailable намеренно запрещены, потому что такая модель не сочетается с архитектурой EMI.
Какие результаты показывают бенчмарки TMRV?
В приведённых тестах TMRV стабильно выигрывает у JEMI и по времени загрузки, и по памяти. Например, в Craftoria загрузка занимает 3201 мс против 8277 мс у JEMI. В ATM10 — 7484 мс против 18658 мс. В ATM9 — 32392 мс против 49409 мс. По RAM разница тоже заметна: от примерно 153.6 MiB до 1.594 GiB в пользу TMRV, в зависимости от сборки.
Поддерживает ли TMRV конфиги JEI?
Почти нет. Из конфигурационных файлов JEI мод читает только .minecraft/config/jei/blacklist.json. Этот файл должен работать для ванильных типов ингредиентов и для модифицированных типов, добавленных JEI-плагином, но сам автор считает это временной мерой для сборок, переходящих с JEI. Для скрытия ингредиентов рекомендуется использовать собственную конфигурацию EMI, а не ожидать полной поддержки JEI-конфигов.
Почему TMRV может выдавать ошибку там, где JEMI внешне работает?
Потому что JEMI использует реальный JEI, а TMRV старается заменить его API более прямым способом. Из-за этого возможны случаи, где JEMI выглядит стабильнее просто потому, что тащит оригинальную инфраструктуру JEI. Но автор отдельно предупреждает: видимое отсутствие ошибки не всегда означает настоящую поддержку сценария. Во многих обычных условиях TMRV всё равно остаётся более рациональным и быстрым решением.
Нужно ли учитывать лицензию при использовании TooManyRecipeViewers?
Да. В проекте есть отдельное важное уведомление: любое использование означает явное согласие с условиями лицензии. Это касается не только разработчиков, но и обычных пользователей, потому что автор прямо указывает на выраженное принятие условий при использовании проекта в любой форме. Для сборок, публичных публикаций и аккуратного обращения с модами этот пункт нельзя игнорировать.
