TooManyRecipeViewers

重要许可证声明

以任何形式使用本项目，即表示你已对本项目许可证条款作出“明确同意”（见 [License](#license)），并承认我（本项目作者）已经履行了许可证中“在具体情况下作出合理努力，以获得接收者对本许可证条款的明确同意”的义务。

TooManyRecipeViewers

TooManyRecipeViewers（或 TMRV）是一个兼容层，可让 JEI 插件在 EMI 中运行，且无需安装 JEI，由 Nolij 编写。

使用此模组需要先安装 EMI。

为什么要用 TMRV 而不是 EMI+JEI（也就是 JEMI）？

JEMI 是 EMI 内置的兼容层，通过高度依赖 JEI 的内部实现，让 JEI 插件在 EMI 中“大体上”可以工作。它的设计目标是尽可能简单，并依赖 JEI 先处理配方数据，再将其导入 EMI。

TMRV 与 JEMI 不同——它的目标是完全替代 JEI API（注意：TMRV 确实包含一些未经修改的 JEI 内部代码——见 [JEI Code Re-Use](#jei-code-re-use)）。在可行的情况下，TMRV 会用直接映射到 EMI API 的方式替代 JEI API，而不是加载整个 JEI 注册表再在事后查询它。这带来了若干优势，包括更高效地使用系统资源，但这也是一种权衡，因为 TMRV 的这种做法会让维护工作远比 JEMI 更复杂。JEMI 被刻意设计成这样，是为了让 EMI 的开发重点放在改进 EMI 本身，我完全支持这种做法。

简而言之：TMRV 比 JEMI 高效得多，代价是维护它所需投入的工作量也大得多，并且没人应该期待 EMI 会投入这么大的精力去支持一个在设计时就刻意没有参考的 API。EMI 一开始就能开箱即用地加载 JEI 插件，这本身就已经很不错了——毕竟这仍然花费了相当多的努力。

话虽如此，TMRV 相较于 JEMI 主要有两个优势：

1. 插件兼容性

TMRV 对 JEI API 的覆盖比 JEMI 更好（有一个例外——见 [Known API Limitations](#known-api-limitations)）。截至撰写本文时，包括：

• 对内置配方类型有更好的转换支持（JEMI 只支持 crafting 和 info 配方类型；TMRV 支持所有内置 JEI 配方类型）
• 配料/搜索别名支持
• createRecipeExtras 支持

2. 效率

使用 TMRV 时，你进入世界的速度始终会比使用 JEMI 更快。这是因为 JEI 插件初始化会阻塞世界加载——在所有 JEI 插件初始化完成之前，你无法开始游戏。而 EMI 会在世界加载完成后异步加载插件。

这意味着，即使 TMRV 加载 JEI 插件的速度比 JEI 更慢（事实并非如此，它的加载速度可测得更快——见 [benchmarks](#benchmarks)），使用 TMRV 时世界加载速度也始终会比使用 JEMI 更快。

如前所述，TMRV 用映射到对应 EMI API 的方式替代了 JEI 的大量 API——这意味着 JEI 内部实现中的整块内容都可以被直接移除。无需初始化并存储整个 JEI 配方注册表——TMRV 只需把 JEI API 调用转换为 EMI 调用，再把返回结果转换成 JEI 格式。可以把 TMRV 看作 Wine 或 Proton，而把 JEMI 看作虚拟机。JEMI 使用真正的 JEI，因此会存在某些场景下 TMRV 报错而 JEMI 不报错的情况（注意，这并不一定意味着 JEMI 真的正确支持了该场景，只是看起来像支持了），但总体来说，TMRV 通常会比 JEMI 更高效。

基准测试

完整结果以及获取这些结果所遵循的步骤记录在 BENCHMARKS.md 中。这些结果并非刻意挑选。操作完全严格按照该文件中记录的说明执行。我也鼓励社区自行验证。

加载时间

内存占用

已知 API 限制

JEI 配置文件

.minecraft/config/jei/blacklist.json 是 TMRV 唯一会读取的 JEI 配置文件。对于原版配料类型，以及由 JEI 插件添加的模组配料类型，这个文件应该可以正常工作（这不包括同时原生支持 JEI 和 EMI 的模组，例如 Mekanism）。这是为了给从 JEI 迁移过来的整合包提供一个临时过渡方案。JEMI 也有类似缺陷。EMI 有它自己的隐藏配料配置——请优先使用那个。除此之外，所有其他 JEI 配置文件都会被 TMRV 完全忽略，而且也没有计划支持它们。

Recipe Manager Plugins

JEI API 支持“Recipe Manager Plugins”。这些插件允许模组控制自己的配方注册表，并在运行时自行处理配方查询。

TMRV 会尝试从这些插件中提取配方，但这对大多数插件都不起作用，也绝不意味着对该功能提供了正确支持。除此之外的进一步支持没有计划。Recipe Manager 插件是一个已经过时的概念，如今仍在使用它的插件非常少，而且若不对 EMI 使用非常侵入式的 mixin，就无法正确支持它——而这正是我不打算在本项目中使用的东西。

原版配方分类扩展

JEI API 支持对原版 Crafting 和 Smithing 配方分类进行“扩展”。关于 JEI API 这部分的工作方式，目前还没有进行足够的分析（而这些分析是判断是否可行支持它所必需的）。因此，目前 TMRV 不支持这些内容。

运行时注册表更改

JEI API 支持在运行时修改配方和配料注册表（即在插件注册完成之后）。这个概念与 EMI 不兼容，也不是我想支持的做法。因此，在调用 IModPlugin.onRuntimeAvailable 之后，所有用于运行时修改注册表的 API 一旦被调用，都会抛出 IllegalStateException，以避免造成潜在混淆。

JEI 代码复用

计划是在未来更新中替换掉更多 JEI 内部实现。不过，由于各种原因，JEI 的某些部分确实不值得重新实现。无论如何，TMRV 目前已经替换了足够多的 JEI 内容，因此我可以有信心地说：

• 想仅通过 mixin 实现相对于 JEMI 的这些改进是不可行的（至少很难以合理方式做到），并且
• 已经有足够多的 JEI 内部实现被替换或移除，因此我不认为这对 JEI 不公平，尤其考虑到 JEI's license 已经明确允许这样做。

License

本项目采用 OSL-3.0 许可协议。更多信息见 LICENSE。

部分代码在遵守其版权许可证的前提下复制自 EMI 和 JEI。本项目中存在的所有修改内容，均采用与本项目其余部分相同的许可证，即 OSL-3.0。