跳到正文
heyaican
中文EN

Forbric

一个 Minecraft 模组加载器，让 Fabric、Forge 与 NeoForge 的模组跑在同一个游戏里。

打开看看 源码 提交更正
Screenshot of Forbric
编辑截图， 4 Oct 2026Forbric ↗

这是什么

一个模组只为三种加载器中的一种而做，通常你只能装其中一种，剩下的模组就留在另一套环境里。Forbric 是你要装的第四样东西：Fabric、Forge 与 NeoForge 的模组全部丢进同一个 mods 文件夹、混在一起，它自己判断每个文件是什么再加载。它不是挂在普通加载器上的翻译层。Fabric Loader 与 Forge、NeoForge 内部的加载器都不启动，由 Forbric 代做，而模组调用的仍是真正的 Fabric API 与真正的 Forge、NeoForge 类。README 同样直说它不是什么：Sinytra Connector 成熟、Forbric 不成熟，能用 Connector 跑起来的模组就用 Connector。

谁做的这个仓库是一个人的。1,105 次提交里 1,076 次来自 Ray-T-r 账号，该账号在提交里出现过两个 git 名字（Jerry 与 RayT）；28 次来自另一个叫 claude 的账号，1 次来自第三个人。同一位作者把项目发到了 B 站，视频播放 411,541 次。

它是怎么搭起来的

组成 · 6

这些加载器是被重新实现，而不是被桥接。Fabric Loader 与 Forge、NeoForge 内部的加载器都不启动；类加载、模组发现、加载顺序、生命周期、Mixin 服务以及 Fabric Loader 自身的 API（类型照搬、实现自写）都由 Forbric 做。底下的游戏是一个合并后的 jar，由安装器从两个 Forge 家族的补丁合成。MinecraftForge 与 NeoForge 改过同一个方法的有约一千处，同一个位置只能留一个版本，除五处之外留下的都是 NeoForge 的。调用因此丢失的事件，只有在 Forbric 重新派发时才能到达监听者。Mixin 打在合并后的代码上，并放宽模组自己的配置：目标不存在时注入器什么都不做而不是报错，目标全部移走的 Mixin 整个丢掉，而不是打一半。

forbric-kernel
安装器实际安装的东西，也是当前工作所在：加载器的重新实现、合并工具与测试。
forbric-loader
第一代加载器，保留下来是因为 kernel 由它长出来。从源码构建它需要 ./bootstrap.sh，当前的开发流程不需要。
两个安装器
一个 kernel 安装器 jar，加上 Windows 的 .bat 与 macOS 的 .command，这样在 .jar 被关联到别的程序、双击只闪一下黑窗口的机器上也能装。
tools/
开发入口，包括一个 Python 脚本：准备好依赖、构建，然后用当前源码启动客户端或服务端。
那几份文档
给读者看的 README.md，给开发者看的 introduction.md（启动顺序、Mixin、事件桥），114 KB 的 COMPATIBILITY_IMPLEMENTATION.md，以及列出什么失败、为什么失败的 MOD_TEST_FAILURES.md。
事件桥
让这次合并不至于无声发生的那一层：调用被另一个加载器的版本取代掉的事件，会被重新派发给等着它的监听者。

取舍，以及另一种做法

  • 重新实现加载器，而不是在它们之间做翻译 替代 Connector 式的兼容模组

    README 自己划了这条线：Kilt 与 Sinytra Connector 是加在普通加载器上的模组，它们在另一边重建这一边的功能；而 Forbric 本身就是加载器。Fabric Loader 的公开 API 类型被携带并实现，版权仍归 FabricMC。

  • 两个 Forge 家族都改过的方法，保留 NeoForge 的版本 替代 保留 MinecraftForge 的

    约一千处方法被两边同时改过，而同一位置只能活一个。README 写明了比例：除五处之外全部保留 NeoForge，那五处保留 MinecraftForge。

  • 放宽模组的 Mixin 配置，而不是在目标缺失时报错 替代 让加载失败

    对模组设置 required: false 与 defaultRequire: 0：目标已经不存在时，注入器什么都不做，而不是把游戏带崩，除非模组自己设了 require。

  • 在读者的机器上组装游戏 替代 直接发一个合并好的 jar

    这是授权边界而不是偏好：仓库里不含那部分代码，它们从 Mojang、Forge 与 NeoForge 自己的服务器下载，在本地合并。

依据Ray-T-r/Minecraft-Forbric-mod-loader 的 README.md、introduction.md 与仓库历史，2026-10-04 读取。

制作过程

4 个阶段
  1. 01

    两个月的提交，一个人，以及大多数提交里署名的那个模型

    仓库有 1,105 次提交，日期从 2026-07-29 到 2026-10-04。其中 1,076 次来自 Ray-T-r 账号，该账号在提交里出现过两个 git 名字；28 次来自一个叫 claude 的账号，1 次来自第三个人。958 次提交带共同作者尾注，而这些尾注全部署名 Claude 系列：Claude Opus 5.5 占 529 次、Claude Opus 5 占 359 次、Claude Fable 5.1 占 70 次。仓库在 GitHub 上的创建日期是 2026-09-10，比库里最早的那次提交晚六周，所以公开的历史是从工作做到一半开始的，不是从头开始的。

  2. 02

    把它带出去的那条视频，也是谁做的

    作者于 2026-09-30 把项目发到 B 站，视频 1 分 17 秒，标题是「我合并了3个mc模组加载器」，播放 411,541、点赞 68,204、收藏 32,364。简介里放着安装链接，还有一句：这条视频本身由 Claude Opus 5.5 制作。GitHub 仓库是 204 星，所以这个项目的传播渠道是中文视频，而工作在仓库里。

  3. 03

    测试方式是约三百个模组一个一个启动

    README 写的是方法而不是结论：从 Modrinth 取三批各约 100 个随机模组，热门和冷门都有、三种类型齐全，每次只装一个模组启动一次游戏。0.2.0 上 80.5% 无错加载，0.3.0 上是 89.0%；0.3.0 那轮有 91.8% 进得了世界，79.1% 没有被报告有部分功能失效。README 接着说明这个测试覆盖不到什么：不逐个试模组功能，也不测试模组之间的组合；并且点名了四个在 0.2.0 上能用、到 0.3.0 不能用的模组。构建通过也不等于游戏能启动：持续集成只验证构建，从不启动 Minecraft。

  4. 04

    仓库里没有任何不能分发的东西

    仓库不含 Minecraft、Forge 或 NeoForge 的代码。安装器从它们自己的服务器下载，并在读者的机器上组装出一个合并后的游戏 jar，所以首次安装需要约 730 MB 的空闲磁盘和一条网线，也就需要几分钟而不是解压一个压缩包。Forbric 自身是 Apache-2.0；它重新实现什么、携带什么，这条清洁室边界写在 forbric-loader/CREDITS.md 与 MAPPINGS.md 里。

他会告诉你什么

  • README 明确写出它不承诺什么：大约每十个模组里仍有一个单独加载就失败，而各自能用的模组放在一起仍可能冲突。
  • 模组的一部分可以无声失效。Forbric 会让模组其余部分继续跑，通常也会告诉你；但某一块挂上之后行为不对，Forbric 和它的测试都看不出来。
  • 一个写在文档里而不是藏起来的已知 bug：NeoForge 版 Sodium 会在启动时崩溃，除非同时装了 Fabric API，依赖它的模组同样如此。
  • 启动扩展完全不支持。ModLauncher 的转换服务、coremods.json、NeoForge 的 ClassProcessorProvider，以及自定义的模组或依赖定位器，目前会被跳过且不给警告。
  • 这是一个 0.3.0 的研究项目，没有支持、没有路线图；而持续集成从不启动游戏，所以构建通过并不说明它能跑起来。

相关档案

全部档案 →

第 124 号

Lemmalog

一个用 Rust 写的 Datalog 引擎，它把 agent 记忆当成演绎数据库，而不是一个更大的向量库。事实在抽取边界断言，分层规则推导闭包与时态视图，每条派生事实都带着回到来源 episode 的溯源，派生视图按 epoch 增量维护，并以十二个 MCP 工具的形式交给 Claude Code 与 Kimi CLI 使用。

第 077 号

Engram

一条把「学一门东西」做成流水线的办法：课程架构师拆出第一性原理的概念图，一名看不见讲课过程的评分者盲评你写下的原话。再由 FSRS 排程，每次判分都在磁盘上留下一条收据。

第 143 号

Jeff

一个 0.8B 的开源模型先回答，只有自己的置信度低于阈值时，才把问题交给大模型。