[TMRV]TooManyRecipeViewers
模组属性评比

距离显示结果还剩5票~

路过的这位少侠,你觉得这款Mod怎么样,可否愿意来评一评它呢?登录并评比
更新日志
  • 暂无日志..

历史编辑记录更多
    管理组

      暂无管理组..

    编辑组

      暂无编辑组..

    开发组申请

      暂无开发组..

    活跃
    开源
    [TMRV]

    TooManyRecipeViewers

    0.0

    无人问津

    昨日指数: 32
    昨日平均指数: 70.745

    3672

    总浏览

    --

    资料填充率


    如何下载?
    • TooManyRecipeViewers

      TooManyRecipeViewers(简称 TMRV)是由 Nolij 开发的一款兼容层模组,可在不安装 JEI 的情况下通过 EMI 运行 JEI 插件。

      使用此模组需预先安装 EMI

      重要许可证声明

      以任何形式使用本模组,即视为您已“明确同意”本项目的许可条款(详见 许可证 ),并确认本模组作者已履行许可条款中“make a reasonable effort under the circumstances to obtain the express assent of recipients to the terms of this License”的义务。

      为何选择 TMRV 而非 EMI+JEI(即 JEMI)?

      JEMI 是 EMI 内置的兼容层,通过深度依赖 JEI 内部代码使其插件基本兼容 EMI。其设计追求极简,需先通过 JEI 处理配方数据再导入 EMI。

      TMRV 与 JEMI 不同,其目标是完全替代 JEI API(注:TMRV 包含部分未修改的 JEI 内部代码,详见 JEI 代码复用 )。TMRV 尽可能将 JEI API 直接映射至 EMI API,而非加载完整 JEI 注册表并事后查询。这带来了更高系统资源效率等优势,但代价是维护成本远高于 JEMI。JEMI 的设计初衷是让 EMI 专注于自身优化,此理念作者完全支持。

      简而言之​:TMRV 比 JEMI 高效得多,但维护难度也大得多。EMI 在设计时已刻意避免依赖 JEI API,因此用户不应期望 EMI 投入同等精力支持此 API。请知足吧——EMI 能原生加载 JEI 插件已付出了相当多的努力。

      尽管如此,TMRV 仍有两项核心优势优于 JEMI:

      插件兼容性

      TMRV 对 JEI API 的覆盖度更高(除一项例外,详见 已知 API 限制 ),包括:

      • 更全面的内置配方类型支持(JEMI 仅支持合成与信息类配方;TMRV 支持所有 JEI 内置配方类型)。

      • 材料/搜索别名支持。

      高效率

      使用 TMRV 时,进入世界的速度始终快于 JEMI。这是因为 ​JEI 插件的初始化会阻塞世界加载进程——必须等待所有 JEI 插件初始化完成后才能开始游戏。而 EMI 会在世界加载完成后异步加载插件。

      这意味着,即便 TMRV 加载插件的速度慢于 JEI(实际并非如此,测试表明 TMRV 加载速度明显更快——详见 基准测试 ),使用 TMRV 仍能比 JEMI 更快进入世界。

      如前所述,TMRV 将大量 JEI API 替换为直接映射至 EMI API 的接口——这意味着 JEI 的完整内部代码可被彻底移除。例如,无需初始化并存储完整的 JEI 配方注册表,TMRV 仅需将 JEI API 调用转换为 EMI 接口,再将响应结果转回 JEI 格式。可将 TMRV 类比为 Wine 或 Proton,而 JEMI 类似虚拟机。JEMI 使用真实的 JEI 代码,因此某些场景中 JEMI 可能看似兼容而 TMRV 报错(但未必代表 JEMI 真正支持该功能)。总体而言,TMRV 的资源利用效率显著高于 JEMI。

      基准测试

      完整测试结果与复现步骤已记录 BENCHMARKS.md。所有数据均未经过人工筛选,测试流程严格遵循文件描述。作者鼓励社区成员进行验证。

      加载耗时

      整合包TMRVJEMI差异对比
      Craftoria2732ms(世界加载前 2ms,
      世界加载后 273ms)
      6895ms(世界加载前 5559ms,
      世界加载后 1336ms)
      ​−4163ms(世界加载前 −5557ms,
      世界加载后 +1594ms)
      ATM10821ms(世界加载前 3ms,
      世界加载后 8211ms)
      17468ms(世界加载前 14670ms,
      世界加载后 2798ms)

      −9254ms(世界加载前 −14667ms

      ,世界加载后 +5413ms)

      内存占用

      整合包TMRVJEMI差异对比
      Craftoria5.28 GiB5.36 GiB​−80 MiB​(近似值)
      ATM105.05 GiB5.3 GiB​−250 MiB(近似值)

      已知 API 限制

      Scroll Widget

      目前 TMRV 和 JEMI 均无法正确渲染 JEI 的此部件。此限制问题最终会得到解决,但当前使用该部件的配方(例如 Chipped 工作台)将无法正常显示。

      JEI Config Files

      TMRV 仅会读取 .minecraft/config/jei/blacklist.json 这一个 JEI 配置文件。该文件对于原版材料类型和通过 JEI 插件添加的模组材料类型有效(不包括原生同时支持 JEI 和 EMI 的模组,例如通用机械)。

      此功能旨在为从 JEI 迁移的整合包提供临时解决方案,JEMI 也存在类似缺陷。EMI 拥有独立的材料隐藏配置 - 请改用该配置。TMRV 会完全忽略所有其他 JEI 配置文件,且暂无支持计划。

      Recipe Manager Plugins

      JEI API 支持“Recipe Manager Plugins”,此类插件允许模组控制自身的配方注册表并自行处理配方查询。这些插件将不被支持。它们是过时的,目前极少有插件仍在使用,如果没有深度侵入式 EMI Mixins(本项目中不愿采用的方案)便无法实现正确支持。

      Runtime Registry Changes

      JEI API 支持在运行时(即插件注册完成后)修改配方与材料注册表。此机制与 EMI 不兼容,且作者不提倡此类用法。

      因此,在 IModPlugin.onRuntimeAvailable 方法调用后,所有涉及运行时注册表修改的 API 均会抛出 IllegalStateException 异常,以避免潜在混淆。

      JEI 代码复用

      未来更新计划将替换更多 JEI 内部代码,但部分 JEI 组件因各类原因无重构必要。即便如此,TMRV 已替换足够多的 JEI 底层代码,可以明确地说:

      1. 通过 Mixin 实现与 JEMI 同等程度的优化并不可行(至少难以合理达成);

      2. 核心代码的大量替换或移除确保了对 JEI 的公平性,尤其在 JEI's license 明确允许此类操作的前提下。

      许可证

      本模组采用 OSL-3.0 许可证。详见 LICENSE

      部分代码依据版权许可条款从 EMI 和 JEI 复制而来。本项目的所有修改内容均采用与项目主体相同的 OSL-3.0 许可证。

      警告:不兼容 JEI物品管理器

    短评加载中..