本帖最后由 秦无心_Renoi 于 2020-3-16 16:22 编辑
在 2018 年 12 月 10 日，Minecraft mod 界大佬 asiekierka 发表声明，Fabric 隆重登场，并随着 1.14 和 1.15 快照的发展一直走到今天。它的背后究竟有什么故事？为什么它在 1.14 的时候诞生而不是 1.13？
注：有问题需要楼主补充直接留言要求就行。
前言
在 2018 年 12 月 10 日，Minecraft mod 界大佬 asiekierka 发表声明，Fabric 隆重登场，并随着 1.14 和 1.15 快照的发展一直走到今天。它的背后究竟有什么故事？为什么它在 1.14 的时候诞生而不是 1.13？
注：有问题需要楼主补充直接留言要求就行。
人物
asiekierka
asiekierka，常称 asie。个人网站是asie.pl。
在 Fabric 的故事中，asie 是当之无愧的主角。他从最早创立 Fabric 到现在 3 年一路走来，虽然他也有隐退，但是他还是坚持了下来。
他是波兰的一位快毕业的大学生。最早在社区中出人头地是在 2014 年左右；当时他从 SpaceToad 手里接坑建筑 mod BuildCraft。在时间积累的过程中，他也因为社区的一些活动吸引了注意力，让他人气暴增。后来他一直在社区各处做贡献，同时维护 FoamFix、Charset 和一些小 mod。
当然，除了 Fabric，他还开过几个坑，以 NovaAPI 尤为有名；但是后来除了 Fabric 都弃坑了。
Vazkii有过一个辛辣的比喻，体现了 asiekieria 的冒险精神。
asie 有个 mcbbs 账号，用 Google 翻译来看 mcbbs。
在 2019 年 9 月 9 日，asie 光荣“退休”，退出 Fabric Discord 群（仍然在 IRC 上），同时在 Fabric 开发中的活动也大幅减少。
modmuss50
Fabric 另外一个**物是 modmuss50。他为 Fabric 的内容，比如 maven 和构建系统提供架构，现在也对 Fabric 进行主要的维护。
他是一位英国人。他以前以维护科技重生（TechReborn）mod 出名，后在 1.10.2 左右开始维护 Steves Carts Reborn，接了 Steves Carts 的坑。
他一直以来对类似 Fabric 的轻量级 API 有兴趣，以前也做过其它的 API，是 Fabric 最早的创始人之一。同时还参与过和 Fabric 对立的工程（OpenModLoader）。
因 modmuss50 撤销资金支持，maven.fabricmc.net 域名过期，asie 被迫使用 modmuss50 的域名。
sfPlayer1
这个**家也许不知道，不过他的作品却是如雷贯耳——工业 2 实验版和 FastCraft。对，这就是工业 2 编写组领头人、FastCraft 作者、能让 Java 版比基岩鸡眼版跑得快的神人，所谓的 Player。
Player 是德国人。他除了维护工业和 FastCraft（和 FastCraft 2）以外，还写过 Matcher，一个重要的反混淆工具（它允许 intermediary 中间名称能够跨版本保存）。同时也是 Java 高级专家，精通如何提升程序的运行效率。
他本来维护 Matcher，后来开发了 tiny remapper 和 tiny 这种反混淆数据格式，给 Fabric 提供了不可或缺的技术支持。同时也主导 Fabric API 的设计，避免性能问题。
Prospector
Prospector 是 modmuss50 的 TechReborn 组织的成员。原以开发生态群系 mod Traverse 而闻名。
Prospector 跟同 modmuss50 便进入了 Fabric。他在 Fabric 中进行一般开发。
他最有名的 Fabric mod 是 Mod Menu，是在 Fabric 中唯一在游戏中（不包括日志）查看 mod 列表的方式。
在 OpenModLoader 完蛋，Fabric 咸鱼翻身之际，是他好心伸手把我拉上 Fabric 这艘贼船的
最近和 asiekierka 一样潜水，同时 ModMenu 由 modmuss50 接坑。
Runemoro
Runemoro 是 DimensionalDoors 开发组的管理。他最有名的作品是 VanillaFix，同时也是 1.13 有名 mod API Rift 的作者。
然而，后来 Rift 因为分发 MCP 的 searge name 反混淆数据，被迫停止开发。于是他便转战 Fabric，并经常给 Fabric 的反混淆数据 yarn 进行贡献。
同时也是一位技术高超的开发者（能写出 VanillaFix 这种强大的 mod 水平够硬），修复了多种工具中的棘手问题。
现已全心全意投入 Fabric，基本不怎么动 Rift 或者 VanillaFix 了。最近还表示要将 VanillaFix 搬运至 Fabric。
Chocohead
Chocohead 和 Player 一样，也是德国人。同时他和 Player 一样，也是工业 2 开发组的成员。
他经常以一些特立独行的作品一鸣惊人，比如他是最早实现 Fabric 和 Optifine 兼容的人。
性格和 asiekierka 类似，都是最早吃螃蟹的人。还教育过群众如何构建可以运行的 Railcraft 包。
曾经在 Runemoro 弃坑 Rift 后在 1.13.2 接盘，但是也弃坑了。改写过 ForgeGradle 2，使其兼容 1.13。
也有一个魔改版的 fabric-loom，添加了许多功能；开发了 Fabric ASM，允许实现一些一般 Mixin 做不到的东西（比如添加枚举）
Lexmanos
LexManos 是 Minecraft Forge 的作者。他脾气相对暴躁（常常在 Forge 爆粗口骂人），独断专行（大家曾经激烈讨论是否要添加 Forge 官方能源 API，但是 LexManos 没有征求任何意见就添加了 Forge Energy），自己也在 GoFundMe 筹资修卡车的时候承认名声并不大好（“but for a large chunk of you i'm also known as the Evil Guy who is ruining Minecraft Modding”）。一些人讨厌的对象。
同时也是 Mod Coder Pack 维护者。
他经常用开源许可和使用许可维权，创造过一个单身码农（就是 Lex）强迫网易开源魔改版 Forge 的奇迹。也用 Mod Coder Pack 的许可威胁过 Rift 和一些 Forge + Bukkit 合体端。
很反对大家写 coremod，但他写的 Forge 却是最大的 coremod。
允许大家在 Forge 的 Discord 群里面谈 Fabric，但是有人（Valoghese）提议用 yarn 代替 MCP 后被秒 ban。
Coded
Coded 是 Horizon (Hrzn) 工作室的**。Horizon 工作室以编写 matter overdrive 和 curseforge 更新检测机器人闻名。
工作室里面很多员工是 Fabric modder，还有一个 Fabric 工程（Fabric 星系 mod）。
然而他本人相对讨厌 Fabric，不信任 asiekierka，并多次错误预言 Fabric 的弃坑。他是 OpenModLoader 作者，是 Fabric 有一段时间的直接竞争对手。
Horizon 工作室和 Gilded Games 组织（天域 mod 作者组织）宣布合作后，Aether Legacy 的 Fabric 版本被下架并搁置。让人怀疑有py交易
虽然不喜欢 Fabric，但是喜欢 Fabric 的一些概念（enigma、轻量级加载器、mixin等）。对 Fabric API 模块化的结构并不赞赏，更希望写一个像 Forge 一样的整体化 API。和楼主观念相近
Thog, ShadowFacts, mezz, Nedelosk, Unascribed, copygirl
这几位都是当时 2016 年左右给 Fabric 贡献的人。其中有些人已经退坑（Una、Thog、shadowfact、Nedelosk），有些保持谨慎观望态度（mezz）。
copygirl 编写 Fabric mod，但不再参与核心开发和贡献了。但是 Thog、shadowfact 在 Fabric 组织中保留名额。
其它还有一些人物，比如 InsomniaKitten（Chloe Dawn）、jamierocks、Chocohead、kashike、liach（不要脸的楼主把自己放进来了）、3TUSK（u.s.knowledge）、Danielshe等为 Fabric 做过贡献。
术语
Fabric Loader
Fabric Loader 是 Fabric 最重要的部分。角色相当于 Forge Mod Loader （FML，1.8 以前 Minecraft Forge 的依赖）。Apache 2.0 开源许可。
Fabric Loader 对游戏兼容性优异，任何用 Java 编写的游戏都能安装 Fabric Loader。有愚人节新闻为证！（只能和 1.14 之前版本的 Forge 一起运行，能安在 3D Shareware v1.34 和别的游戏上倒是真实的）
同时因为它的优秀兼容性，一般 Fabric Loader 版本和 Minecraft 版本并没有强制对应关系，不像 Forge。
自带 yarn 反混淆数据、Knot（替代 LaunchWrapper）和 Mixin，便利用户。同时安装器有翻译，不用担心语言问题看不懂。
运行时将游戏变为 intermediary 名称（一种中间名，类似于 searge name），以便跨版本和跨反混淆数据兼容。
除了 Fabric API 以外，现在有些作弊客户端因为 Fabric Loader 带 Mixin、yarn 更新快等原因转战 Fabric 了，例如 aristois作弊客户端。
Fabric API
Fabric API 是 Fabric 给 mod 提供接口的部分。角色相当于 Minecraft Forge 本身。Apache 2.0 开源许可。
在 CurseForge 上看到的 Fabric 下载就是这个 API，而不是 Fabric Loader。
Fabric API 是一个 mod。里面有很多个小模块包，都放在自己的包里面，每个小模块都是一个 mod（术语叫 jar in jar，由 Fabric Loader 实现）。大多数 Fabric mod 一般依赖其中的某一个或者某几个模块，所以一般安装 Fabric Loader 都会安装 Fabric API 包。
Fabric API 在不同 Minecraft 版本中有可能会因 Minecraft 改动而无法跨版本使用，需要看情况而定。
不像 Forge 打死补丁，Fabric API 使用 Mixin 暴露接口和打补丁。
yarn
yarn 是 Fabric 的反混淆工程（曾用名 pomf，publicly open mapping files）。角色相当于 Mod Coder Pack。CC0（公共领域）许可。
因为 Mod Coder Pack 对搬运其数据的限制和 Lexmanos 对 MCP 的控制，Fabric 开发组被迫维护自己的反混淆工程；但是同时也给了它超越 MCP 的机会。
yarn 本身是 Enigma 反混淆工具的存档。构建后会变成含 tiny 反混淆数据的 GZip 压缩文件，更轻量而且 Fabric Loader 和 mod 开发直接可用。
yarn 比 MCP 更好使用。Enigma 可以随时采用你的反混淆名，你起名时可以看清代码环境，不像 MCP 的机器人脱离源代码。
指令：
可以直接打开 Enigma 修改反混淆数据。完成后保存再用 Git 记录，就可以提交合并请求（Pull Request），为 yarn 做贡献了。
会用现在的反混淆数据反混淆原版包。反混淆的包（名称以 named 结尾）反编译后就得到 Minecraft 反混淆的源代码了，适合研究原版的人使用。
yarn 现在直接把官方混淆名称反混淆，没有使用像 MCP 的 searge name 这类中间名，虽然 Fabric 编写组有一套中间名（intermediary）并有意迁移。
loom
loom 是 Fabric 的构建工具。角色相当于 ForgeGradle。MIT 开源许可。
loom 是专门为 Fabric Mod 开发使用的工具。有反编译、反混淆 Minecraft、将使用 yarn 名称的代码转为使用 intermediary 名称的（类似 ForgeGradle 把 MCP 转 Searge 名）、还有自带的 Mixin 编译支持。
楼主个人感觉 loom 总体上比 ForgeGradle 3 稳定，但是 loom 有时候会有下载错误。这时候就要打开用户根目录中 .gradle/caches/fabric-loom 文件夹并将出错的文件和它的 etag 文件（若存在，是记录下载信息的）一起删掉，就会恢复正常了。
使用 loom 编写 Fabric Mod 推荐导入 https://github.com/FabricMC/fabric-example-mod/ 作为模板（可以下载 zip 或者使用 GitHub 的导入模板功能放到你自己的仓库）
不同 IDE 使用方法：
默认不会生成源码。需要执行
才会生成可以检索（找方法、字段用途之类的）的源码。多模块工程上暂时不能使用这个 Gradle 命令（例如 Fabric API 上不能用）
loom 和 yarn、intermediary 等反编译工具无关；它们在 Gradle 中使用外部命令行工具 （Stitch、Weave、Enigma）
Mod Coder Pack
Mod Coder Pack 是 Minecraft 历史最悠久的反混淆服务，由 Searge 创办。多位**成功登仙，例如 Searge 和 ProfMobius。现在由 bspkrs 和 LexManos 领导。
它的反混淆数据是通过跟一个 IRC 机器人（MCP Bot）交互进行修改和查询的。
最早会给一整套 python 脚本等，允许用户直接修改现场反编译的 Minecraft 源码。1.12 以后不再发行一整套东西，只把几个核心反混淆数据发布。
它的许可臭名昭著。主要限制：
1、未经 MCP 小组许可不许搬运 MCP 数据；
2、它的创意是保留权利的，所以不能被拿到公共领域（比如拿到 yarn 用 MCP 就可以打掉 yarn）
Rift 和某些 Forge+Bukkit 服务端由于第一点限制被迫改动；Rift 因此弃坑。
Rift
Rift 是 1.13 的一个 Mod API，作者是 Runemoro，后来 Chocohead 接坑至 1.13.2。相对于 Forge 比较轻量。
使用 Mixin。
和 Fabric 相比更加臃肿。
使用 LaunchWrapper 启动游戏。使用 MCP 反混淆。
使用 ForgeGradle 2 的魔改版本作为构建工具。
后来因为 MCP 版权问题逐渐弃坑。作者转战 Fabric。
LiteLoader
LiteLoader 是 1.5.2 到 1.12.2 的一个 Mod API，作者是 Mumfrey。专用于客户端的轻量级 Mod API。
前身是 Risugami 的 ModLoader，但是 Mumfrey 觉得 ModLoader 太臃肿就开发了 LiteLoader。
从 Minecraft 1.8.9 起使用 Mixin，是最早使用 Mixin 的 Mod API。原因很简单，因为 Mumfrey 就是 Mixin 作者。
（SpongeForge 和 SpongeVanilla 虽然也携带 Mixin，但是 Sponge API 不包含 Mixin）
很轻量，一般升级新 Minecraft 版本比 Forge 快多了。
但是因为启动时有行代码会重新加载所有资源包，会导致有时在大型整合包中运行时增加启动时间。
提供修改客户端和内置服务器（局域网、单人游戏的服务器）的接口。
使用 LaunchWrapper 启动游戏。使用 MCP 反混淆。
使用 ForgeGradle 作为构建工具。（ForgeGradle 自带 LiteLoader 兼容）
后来 Mumfrey 逐渐潜水，LiteLoader 似乎就死在了 1.12.2。一些 LiteMod（比如 VoxelMap）就 1.13 转战 Rift，1.14 转战 Fabric。
OpenModLoader
OpenModLoader 是 1.13 和 1.14 快照版本的一个 Mod API，** Coded。成员有 Modmuss50、Gegy1000、Prospector 等人。
类似 Fabric 的轻量级 Mod API。（实际上直接舔了 Fabric 的包，把 2016 年剩下的基建直接拿过来用了）
前身是 Fabric。但是 Coded 的展望不一样，想做一个像 Forge 一样的大型 API 而不是零散化模块化的结构。（类似楼主的想法）
使用 ModLauncher 启动游戏。使用魔改版 pomf（yarn 前身的魔改版，直接从 MCP 抄了一些名称）反混淆。
使用 OpenGradle（loom 魔改版）作为构建工具。
后来 asiekierka 重新出山，OpenModLoader 大将 Modmuss50弃暗投明反水回归 Fabric。OpenModLoader 便死在黎明前最后一刻的黑暗中。
Mixin
Mixin 是 SpongePowered 为了更好地实现 Sponge API 而编写的一个可以修改 Java 字节码（Java assembly/ASM）的库。由 Mumfrey 负责维护。
Mixin 的目的是安全和方便地修改 Minecraft 的字节码。它跟 Forge 使用的字节码二进制补丁相比可以在其它 mod 打补丁后正常使用，而且编译时省下很多时间。有一套很优秀的安全系统。
Mixin 能够实现一般字节码修改的大多数目的，但是还是有些限制：
但是 Mixin 已经涵盖了大多数字节码修改者需要做的事情，而且比纯 ObjectWeb ASM 更好理解，所以在 Sponge 之外用户很多，比如有 ForgeEssentials、Mal**core、Hyperium 等。
虽然介绍上说是基于 LaunchWrapper 的，但是实际上有一个兼容层允许任何人实现兼容（比如 asiekierka 就给 knot 肝了个 Mixin 兼容层，而截止 Forge 1.14 发布 ModLauncher 也没有 Mixin 兼容层都在等 Mumfrey 写）。
历史
你以为 Fabric 是 Forge 的分支不肖子孙吗？
错了。
Fabric 的传承
一般大家概念中，Mod 加载器就是 Forge 一家独大，偶尔 LiteLoader 出来冒个泡。
但是 1.13 时 Forge 大重写给很多新型 Mod 加载器冒泡的机会。尝试过的 Mod 加载器也不止一个（Rift、OpenModLoader、Fabric），为什么 Fabric 在轻量级加载器的战争中获胜？
Minecraft Mod 加载器有很多，但是随时间推移，在 1.6 中 ModLoader 弃坑后，因为维护成本等原因，Forge 一家独大。（Sponge API 规模上也可以算重量级加载器，但是并不提供注册物品等非插件功能）
剩下就是轻量级加载器的战场了。
这中间最有名的是的 LiteLoader 了。
虽然 LiteLoader 主要加载客户端 mod，但是实际上也可以加载添加物品、方块等的大型 mod。有个BlazeLoader就是基于 LiteLoader 加载器的一个 mod API。
在 Forge 一家独大的时候，风平浪静的表面下却是暗流涌动。
有很多 Mod API 存在过，又烟消云散了。Paper Mod Loader运气还算好，在 GitHub 上留了个全尸；在现在的 OpenModLoader 之前实际上还有一个老的 OpenModLoader，连骨灰都不剩了（modmuss50 电脑本地有存档）。
说 Fabric 是 Forge 的竞争者，更不如说它是这些夭折工程中的幸运儿。
创作者走向
在 Fabric 的聊天群和 Mod 作者中，大概有这几类：
为什么 Fabric 一炮成名
asiekierka 总结，Fabric 的成功和在 Feedthebeast reddit 上的帖子息息相关。的确如此；Fabric 群中大多数成员都是在 2018 年 12 月 10 日发帖后才加入的。
然而除此之外，Fabric 为什么能有如此好的基建呢？楼主认为还是 Fabric 作者们肝出来的，比如 Knot 启动器（兼容 Java 8 以上版本）和 Mixin 的 Knot 兼容层都是 asiekierka 自己写的。Forge 虽然有重构，但是本末倒置，基建一团糟就急功近利。ModLauncher 名义上高大上，但是实际使用并不多，连 Optifine 都不用；而 Knot 却成功很多，实现了更安全的字节码修改。ForgeGradle 3 稳定性还没有 ForgeGradle 2 好，所以 Rift 使用了修改版的 ForgeGradle 2。
Forge 的说法
Fabric 如火如荼，当然就有人去问 Forge 对 Fabric 的看法。Forge 开发组在 2019 年 6 月 2 日的 Forge Annual Parley 上也简单回答了几个问题。
某人写的 Forge Annual Parley 总结
Forge 和 Fabric 互动：
开发者合作：
Fabric 更新快的原因：
Fabric 的弱点
Fabric 亮点很多，但是也有弱点。
Fabric 的玩家用户不多。Mod 在 curseforge 上的下载量都偏低。Twitch 启动器也不支持 Fabric。
Fabric 的有些基础设施还需要改进，比如 Enigma 反混淆软件和 procyon 反编译器还有一些 bug。loom 也有些小问题。
前言
在 2018 年 12 月 10 日，Minecraft mod 界大佬 asiekierka 发表声明，Fabric 隆重登场，并随着 1.14 和 1.15 快照的发展一直走到今天。它的背后究竟有什么故事？为什么它在 1.14 的时候诞生而不是 1.13？
注：有问题需要楼主补充直接留言要求就行。
2021.12 数据，可能有更多内容
前言
在 2018 年 12 月 10 日，Minecraft mod 界大佬 asiekierka 发表声明，Fabric 隆重登场，并随着 1.14 和 1.15 快照的发展一直走到今天。它的背后究竟有什么故事？为什么它在 1.14 的时候诞生而不是 1.13？
注：有问题需要楼主补充直接留言要求就行。
人物
asiekierka
asiekierka，常称 asie。个人网站是asie.pl。
在 Fabric 的故事中，asie 是当之无愧的主角。他从最早创立 Fabric 到现在 3 年一路走来，虽然他也有隐退，但是他还是坚持了下来。
他是波兰的一位快毕业的大学生。最早在社区中出人头地是在 2014 年左右；当时他从 SpaceToad 手里接坑建筑 mod BuildCraft。在时间积累的过程中，他也因为社区的一些活动吸引了注意力，让他人气暴增。后来他一直在社区各处做贡献，同时维护 FoamFix、Charset 和一些小 mod。
当然，除了 Fabric，他还开过几个坑，以 NovaAPI 尤为有名；但是后来除了 Fabric 都弃坑了。
Vazkii有过一个辛辣的比喻，体现了 asiekieria 的冒险精神。
asie 有个 mcbbs 账号，用 Google 翻译来看 mcbbs。
在 2019 年 9 月 9 日，asie 光荣“退休”，退出 Fabric Discord 群（仍然在 IRC 上），同时在 Fabric 开发中的活动也大幅减少。
modmuss50
Fabric 另外一个**物是 modmuss50。他为 Fabric 的内容，比如 maven 和构建系统提供架构，现在也对 Fabric 进行主要的维护。
他是一位英国人。他以前以维护科技重生（TechReborn）mod 出名，后在 1.10.2 左右开始维护 Steves Carts Reborn，接了 Steves Carts 的坑。
他一直以来对类似 Fabric 的轻量级 API 有兴趣，以前也做过其它的 API，是 Fabric 最早的创始人之一。同时还参与过和 Fabric 对立的工程（OpenModLoader）。
代码:
- Fabric 估计两星期都活不到
因 modmuss50 撤销资金支持，maven.fabricmc.net 域名过期，asie 被迫使用 modmuss50 的域名。
sfPlayer1
这个**家也许不知道，不过他的作品却是如雷贯耳——工业 2 实验版和 FastCraft。对，这就是工业 2 编写组领头人、FastCraft 作者、能让 Java 版比基岩
Player 是德国人。他除了维护工业和 FastCraft（和 FastCraft 2）以外，还写过 Matcher，一个重要的反混淆工具（它允许 intermediary 中间名称能够跨版本保存）。同时也是 Java 高级专家，精通如何提升程序的运行效率。
他本来维护 Matcher，后来开发了 tiny remapper 和 tiny 这种反混淆数据格式，给 Fabric 提供了不可或缺的技术支持。同时也主导 Fabric API 的设计，避免性能问题。
Prospector
Prospector 是 modmuss50 的 TechReborn 组织的成员。原以开发生态群系 mod Traverse 而闻名。
Prospector 跟同 modmuss50 便进入了 Fabric。他在 Fabric 中进行一般开发。
他最有名的 Fabric mod 是 Mod Menu，是在 Fabric 中唯一在游戏中（不包括日志）查看 mod 列表的方式。
最近和 asiekierka 一样潜水，同时 ModMenu 由 modmuss50 接坑。
Runemoro
Runemoro 是 DimensionalDoors 开发组的管理。他最有名的作品是 VanillaFix，同时也是 1.13 有名 mod API Rift 的作者。
然而，后来 Rift 因为分发 MCP 的 searge name 反混淆数据，被迫停止开发。于是他便转战 Fabric，并经常给 Fabric 的反混淆数据 yarn 进行贡献。
同时也是一位技术高超的开发者（能写出 VanillaFix 这种强大的 mod 水平够硬），修复了多种工具中的棘手问题。
现已全心全意投入 Fabric，基本不怎么动 Rift 或者 VanillaFix 了。最近还表示要将 VanillaFix 搬运至 Fabric。
Chocohead
Chocohead 和 Player 一样，也是德国人。同时他和 Player 一样，也是工业 2 开发组的成员。
他经常以一些特立独行的作品一鸣惊人，比如他是最早实现 Fabric 和 Optifine 兼容的人。
性格和 asiekierka 类似，都是最早吃螃蟹的人。还教育过群众如何构建可以运行的 Railcraft 包。
曾经在 Runemoro 弃坑 Rift 后在 1.13.2 接盘，但是也弃坑了。改写过 ForgeGradle 2，使其兼容 1.13。
也有一个魔改版的 fabric-loom，添加了许多功能；开发了 Fabric ASM，允许实现一些一般 Mixin 做不到的东西（比如添加枚举）
Lexmanos
LexManos 是 Minecraft Forge 的作者。他脾气相对暴躁（常常在 Forge 爆粗口骂人），独断专行（大家曾经激烈讨论是否要添加 Forge 官方能源 API，但是 LexManos 没有征求任何意见就添加了 Forge Energy），自己也在 GoFundMe 筹资修卡车的时候承认名声并不大好（“but for a large chunk of you i'm also known as the Evil Guy who is ruining Minecraft Modding”）。一些人讨厌的对象。
同时也是 Mod Coder Pack 维护者。
他经常用开源许可和使用许可维权，创造过一个单身码农（就是 Lex）强迫网易开源魔改版 Forge 的奇迹。也用 Mod Coder Pack 的许可威胁过 Rift 和一些 Forge + Bukkit 合体端。
很反对大家写 coremod，但他写的 Forge 却是最大的 coremod。
允许大家在 Forge 的 Discord 群里面谈 Fabric，但是有人（Valoghese）提议用 yarn 代替 MCP 后被秒 ban。
Coded
Coded 是 Horizon (Hrzn) 工作室的**。Horizon 工作室以编写 matter overdrive 和 curseforge 更新检测机器人闻名。
工作室里面很多员工是 Fabric modder，还有一个 Fabric 工程（Fabric 星系 mod）。
然而他本人相对讨厌 Fabric，不信任 asiekierka
Horizon 工作室和 Gilded Games 组织（天域 mod 作者组织）宣布合作后，Aether Legacy 的 Fabric 版本被下架并搁置。
虽然不喜欢 Fabric，但是喜欢 Fabric 的一些概念（enigma、轻量级加载器、mixin等）。对 Fabric API 模块化的结构并不赞赏，更希望写一个像 Forge 一样的整体化 API。
代码:
- 说过多少遍了，Fabric 早就有了。之前 asie 觉得无聊了，Fabric 就弃坑了。asie 所有工程都这样弃坑的。
Thog, ShadowFacts, mezz, Nedelosk, Unascribed, copygirl
这几位都是当时 2016 年左右给 Fabric 贡献的人。其中有些人已经退坑（Una、Thog、shadowfact、Nedelosk），有些保持谨慎观望态度（mezz）。
copygirl 编写 Fabric mod，但不再参与核心开发和贡献了。但是 Thog、shadowfact 在 Fabric 组织中保留名额。
其它还有一些人物，比如 InsomniaKitten（Chloe Dawn）、jamierocks、Chocohead、kashike、liach
术语
Fabric Loader
Fabric Loader 是 Fabric 最重要的部分。角色相当于 Forge Mod Loader （FML，1.8 以前 Minecraft Forge 的依赖）。Apache 2.0 开源许可。
Fabric Loader 对游戏兼容性优异，任何用 Java 编写的游戏都能安装 Fabric Loader。有
同时因为它的优秀兼容性，一般 Fabric Loader 版本和 Minecraft 版本并没有强制对应关系，不像 Forge。
自带 yarn 反混淆数据、Knot（替代 LaunchWrapper）和 Mixin，便利用户。同时安装器有翻译，不用担心语言问题看不懂。
运行时将游戏变为 intermediary 名称（一种中间名，类似于 searge name），以便跨版本和跨反混淆数据兼容。
除了 Fabric API 以外，现在有些作弊客户端因为 Fabric Loader 带 Mixin、yarn 更新快等原因转战 Fabric 了，例如 aristois
Fabric API
Fabric API 是 Fabric 给 mod 提供接口的部分。角色相当于 Minecraft Forge 本身。Apache 2.0 开源许可。
在 CurseForge 上看到的 Fabric 下载就是这个 API，而不是 Fabric Loader。
Fabric API 是一个 mod。里面有很多个小模块包，都放在自己的包里面，每个小模块都是一个 mod（术语叫 jar in jar，由 Fabric Loader 实现）。大多数 Fabric mod 一般依赖其中的某一个或者某几个模块，所以一般安装 Fabric Loader 都会安装 Fabric API 包。
Fabric API 在不同 Minecraft 版本中有可能会因 Minecraft 改动而无法跨版本使用，需要看情况而定。
不像 Forge 打死补丁，Fabric API 使用 Mixin 暴露接口和打补丁。
yarn
yarn 是 Fabric 的反混淆工程（曾用名 pomf，publicly open mapping files）。角色相当于 Mod Coder Pack。CC0（公共领域）许可。
因为 Mod Coder Pack 对搬运其数据的限制和 Lexmanos 对 MCP 的控制，Fabric 开发组被迫维护自己的反混淆工程；但是同时也给了它超越 MCP 的机会。
yarn 本身是 Enigma 反混淆工具的存档。构建后会变成含 tiny 反混淆数据的 GZip 压缩文件，更轻量而且 Fabric Loader 和 mod 开发直接可用。
yarn 比 MCP 更好使用。Enigma 可以随时采用你的反混淆名，你起名时可以看清代码环境，不像 MCP 的机器人脱离源代码。
指令：
代码:
- ./gradlew yarn
可以直接打开 Enigma 修改反混淆数据。完成后保存再用 Git 记录，就可以提交合并请求（Pull Request），为 yarn 做贡献了。
代码:
- ./gradlew mapNamedJar
会用现在的反混淆数据反混淆原版包。反混淆的包（名称以 named 结尾）反编译后就得到 Minecraft 反混淆的源代码了，适合研究原版的人使用。
yarn 现在直接把官方混淆名称反混淆，没有使用像 MCP 的 searge name 这类中间名，虽然 Fabric 编写组有一套中间名（intermediary）并有意迁移。
loom
loom 是 Fabric 的构建工具。角色相当于 ForgeGradle。MIT 开源许可。
loom 是专门为 Fabric Mod 开发使用的工具。有反编译、反混淆 Minecraft、将使用 yarn 名称的代码转为使用 intermediary 名称的（类似 ForgeGradle 把 MCP 转 Searge 名）、还有自带的 Mixin 编译支持。
楼主个人感觉 loom 总体上比 ForgeGradle 3 稳定，但是 loom 有时候会有下载错误。这时候就要打开用户根目录中 .gradle/caches/fabric-loom 文件夹并将出错的文件和它的 etag 文件（若存在，是记录下载信息的）一起删掉，就会恢复正常了。
使用 loom 编写 Fabric Mod 推荐导入 https://github.com/FabricMC/fabric-example-mod/ 作为模板（可以下载 zip 或者使用 GitHub 的导入模板功能放到你自己的仓库）
不同 IDE 使用方法：
- Intellij Idea：直接导入 Gradle 工程即可
- Eclipse：导入 Gradle 工程，然后运行
代码:
- ./gradlew eclipse
- VSCode：导入 Gradle 工程，然后运行
代码:
- ./gradlew vscode
默认不会生成源码。需要执行
代码:
- ./gradlew genSources
才会生成可以检索（找方法、字段用途之类的）的源码。多模块工程上暂时不能使用这个 Gradle 命令（例如 Fabric API 上不能用）
loom 和 yarn、intermediary 等反编译工具无关；它们在 Gradle 中使用外部命令行工具 （Stitch、Weave、Enigma）
Mod Coder Pack
Mod Coder Pack 是 Minecraft 历史最悠久的反混淆服务，由 Searge 创办。多位**成功登仙，例如 Searge 和 ProfMobius。现在由 bspkrs 和 LexManos 领导。
它的反混淆数据是通过跟一个 IRC 机器人（MCP Bot）交互进行修改和查询的。
最早会给一整套 python 脚本等，允许用户直接修改现场反编译的 Minecraft 源码。1.12 以后不再发行一整套东西，只把几个核心反混淆数据发布。
它的许可臭名昭著。主要限制：
1、未经 MCP 小组许可不许搬运 MCP 数据；
2、它的创意是保留权利的，所以不能被拿到公共领域（比如拿到 yarn 用 MCP 就可以打掉 yarn）
Rift 和某些 Forge+Bukkit 服务端由于第一点限制被迫改动；Rift 因此弃坑。
Rift
Rift 是 1.13 的一个 Mod API，作者是 Runemoro，后来 Chocohead 接坑至 1.13.2。相对于 Forge 比较轻量。
使用 Mixin。
和 Fabric 相比更加臃肿。
使用 LaunchWrapper 启动游戏。使用 MCP 反混淆。
使用 ForgeGradle 2 的魔改版本作为构建工具。
后来因为 MCP 版权问题逐渐弃坑。作者转战 Fabric。
LiteLoader
LiteLoader 是 1.5.2 到 1.12.2 的一个 Mod API，作者是 Mumfrey。专用于客户端的轻量级 Mod API。
前身是 Risugami 的 ModLoader，但是 Mumfrey 觉得 ModLoader 太臃肿就开发了 LiteLoader。
从 Minecraft 1.8.9 起使用 Mixin，是最早使用 Mixin 的 Mod API。原因很简单，因为 Mumfrey 就是 Mixin 作者。
（SpongeForge 和 SpongeVanilla 虽然也携带 Mixin，但是 Sponge API 不包含 Mixin）
很轻量，一般升级新 Minecraft 版本比 Forge 快多了。
但是因为启动时有行代码会重新加载所有资源包，会导致有时在大型整合包中运行时增加启动时间。
提供修改客户端和内置服务器（局域网、单人游戏的服务器）的接口。
使用 LaunchWrapper 启动游戏。使用 MCP 反混淆。
使用 ForgeGradle 作为构建工具。（ForgeGradle 自带 LiteLoader 兼容）
后来 Mumfrey 逐渐潜水，LiteLoader 似乎就死在了 1.12.2。一些 LiteMod（比如 VoxelMap）就 1.13 转战 Rift，1.14 转战 Fabric。
OpenModLoader
OpenModLoader 是 1.13 和 1.14 快照版本的一个 Mod API，** Coded。成员有 Modmuss50、Gegy1000、Prospector 等人。
类似 Fabric 的轻量级 Mod API。（实际上直接舔了 Fabric 的包，把 2016 年剩下的基建直接拿过来用了）
前身是 Fabric。但是 Coded 的展望不一样，想做一个像 Forge 一样的大型 API 而不是零散化模块化的结构。（类似楼主的想法）
使用 ModLauncher 启动游戏。使用魔改版 pomf（yarn 前身的魔改版，直接从 MCP 抄了一些名称）反混淆。
使用 OpenGradle（loom 魔改版）作为构建工具。
后来 asiekierka 重新出山，OpenModLoader 大将 Modmuss50
Mixin
Mixin 是 SpongePowered 为了更好地实现 Sponge API 而编写的一个可以修改 Java 字节码（Java assembly/ASM）的库。由 Mumfrey 负责维护。
Mixin 的目的是安全和方便地修改 Minecraft 的字节码。它跟 Forge 使用的字节码二进制补丁相比可以在其它 mod 打补丁后正常使用，而且编译时省下很多时间。有一套很优秀的安全系统。
Mixin 能够实现一般字节码修改的大多数目的，但是还是有些限制：
- 遇到包私有类束手无策（无法正确引用，需要 Access Transformer 解决）
- 不能修改某些继承类的东西（比如改一个类的父类）
但是 Mixin 已经涵盖了大多数字节码修改者需要做的事情，而且比纯 ObjectWeb ASM 更好理解，所以在 Sponge 之外用户很多，比如有 ForgeEssentials、Mal**core、Hyperium 等。
虽然介绍上说是基于 LaunchWrapper 的，但是实际上有一个兼容层允许任何人实现兼容（比如 asiekierka 就给 knot 肝了个 Mixin 兼容层，而截止 Forge 1.14 发布 ModLauncher 也没有 Mixin 兼容层
历史
你以为 Fabric 是 Forge 的分支
错了。
Fabric 的传承
一般大家概念中，Mod 加载器就是 Forge 一家独大，偶尔 LiteLoader 出来冒个泡。
但是 1.13 时 Forge 大重写给很多新型 Mod 加载器冒泡的机会。尝试过的 Mod 加载器也不止一个（Rift、OpenModLoader、Fabric），为什么 Fabric 在轻量级加载器的战争中获胜？
Minecraft Mod 加载器有很多，但是随时间推移，在 1.6 中 ModLoader 弃坑后，因为维护成本等原因，Forge 一家独大。（Sponge API 规模上也可以算重量级加载器，但是并不提供注册物品等非插件功能）
剩下就是轻量级加载器的战场了。
这中间最有名的是的 LiteLoader 了。
虽然 LiteLoader 主要加载客户端 mod，但是实际上也可以加载添加物品、方块等的大型 mod。有个BlazeLoader就是基于 LiteLoader 加载器的一个 mod API。
在 Forge 一家独大的时候，风平浪静的表面下却是暗流涌动。
有很多 Mod API 存在过，又烟消云散了。Paper Mod Loader运气还算好，在 GitHub 上留了个全尸；在现在的 OpenModLoader 之前实际上还有一个老的 OpenModLoader，连骨灰都不剩了（modmuss50 电脑本地有存档）。
说 Fabric 是 Forge 的竞争者，更不如说它是这些夭折工程中的幸运儿。
创作者走向
在 Fabric 的聊天群和 Mod 作者中，大概有这几类：
- 技术类玩家：MinecraftCommands reddit 的 Discord 群就在帮助中放了 Fabric 群的加群链接，Carpet Mod（一个原版技术 debug 类的模组）也搬运到了 Fabric
- 新快照玩家：有些 Minecraft Wiki 编辑员参与 yarn 工程以更好了解新快照的添加内容和变动，再添加至 Wiki 上。
- 想搬运 mod 到新快照的人：可以尝鲜
- 讨厌 Forge 的人：Fabric 气氛相对更自由
- 作弊端作者：Aristois 作弊客户端从独立 mod 变成了 Fabric 模组，可以更快更新，吸引用户
- 前 LiteLoader/Rift 作者：VoxelMap AutoFish 等多个 1.12.2 的 LiteMod 因为 LiteLoader 弃坑，1.13 改用 Rift，而 1.14 改用 Fabric。
为什么 Fabric 一炮成名
asiekierka 总结，Fabric 的成功和在 Feedthebeast reddit 上的帖子息息相关。的确如此；Fabric 群中大多数成员都是在 2018 年 12 月 10 日发帖后才加入的。
然而除此之外，Fabric 为什么能有如此好的基建呢？楼主认为还是 Fabric 作者们肝出来的，比如 Knot 启动器（兼容 Java 8 以上版本）和 Mixin 的 Knot 兼容层都是 asiekierka 自己写的。Forge 虽然有重构，但是本末倒置，基建一团糟就急功近利。ModLauncher 名义上高大上，但是实际使用并不多，连 Optifine 都不用；而 Knot 却成功很多，实现了更安全的字节码修改。ForgeGradle 3 稳定性还没有 ForgeGradle 2 好，所以 Rift 使用了修改版的 ForgeGradle 2。
Forge 的说法
Fabric 如火如荼，当然就有人去问 Forge 对 Fabric 的看法。Forge 开发组在 2019 年 6 月 2 日的 Forge Annual Parley 上也简单回答了几个问题。
某人写的 Forge Annual Parley 总结
Forge 和 Fabric 互动：
- Forge 不会加载 Fabric mod（正常，Forge 也不会加载 LiteMod）
- 共同运行：需要统一名称，Searge name 和 intermediary name 二选一（说实话，Forge + Bukkit 这种操作多的是，不会难的）
开发者合作：
- 各人自扫门前雪，莫管他人瓦上霜
- 有需求可以随时沟通
Fabric 更新快的原因：
- Forge 在大动筋骨，Fabric 趁机出头（骗骗无知群众可以，看过 OpenModLoader 嗝屁的就知道没那么简单）
- Fabric 补丁少（如果是纯 Loader 补丁更少）
- Forge 更新快照的话维护成本太高（Forge 对自身的评估还是比较准确的）
- Forge 要维护 Searge name，Fabric 不用（不是也有 intermediary……楼主认为只是 MCP 用的匹配工具没有 sfPlayer1 写的 Matcher 高效而已）
- Fabric 的目标是轻量和模块化（很对）
- Fabric 年轻（也是 2016 年的了，有点年头了）
Fabric 的弱点
Fabric 亮点很多，但是也有弱点。
Fabric 的玩家用户不多。Mod 在 curseforge 上的下载量都偏低。Twitch 启动器也不支持 Fabric。
Fabric 的有些基础设施还需要改进，比如 Enigma 反混淆软件和 procyon 反编译器还有一些 bug。loom 也有些小问题。
啊，对不起……这个坑我本来准备慢慢填，结果不小心发了……
本帖最后由 派达星 于 2019-5-20 10:41 编辑
Fabric Api 0.3会导致游戏卡顿2-3s。即便我什么mod都不加，只放Fabric Api也会卡顿。我看到GitHub上已经有人反馈了，不知道啥时候能解决。
Fabric Api 0.3会导致游戏卡顿2-3s。即便我什么mod都不加，只放Fabric Api也会卡顿。我看到GitHub上已经有人反馈了，不知道啥时候能解决。
派达星 发表于 2019-5-20 10:02
Fabric Api 0.3会导致游戏卡顿2-3s。即便我什么mod都不加，只放Fabric Api也会卡顿。我看到GitHub上已经有 ...
是的。原因是jar in jar有个效率问题，导致游戏在最早加载某些类的时候卡顿一下。但是一次性卡顿后，在游戏中之后就再也不会卡顿了。
推荐的临时解决方法是搞一个临时创造世界，每次启动游戏先进一下那个世界过一下这个卡顿期。然后再进入你所游玩的正式存档或者服务器。
本帖最后由 1a2s3d4f1 于 2019-5-26 22:03 编辑
fabric的模块化也是...蹦服还要安装FabricProxy，mod显示要安装modmenu，加载条也要安装mod，jar套jar也就是说这些模块可以包含到一个jar里面（上次打开一个fabric mod发现前置mod都套进去了
）
fabric的模块化也是...蹦服还要安装FabricProxy，mod显示要安装modmenu，加载条也要安装mod，jar套jar也就是说这些模块可以包含到一个jar里面（上次打开一个fabric mod发现前置mod都套进去了
）1a2s3d4f1 发表于 2019-5-26 22:01
fabric的模块化也是...蹦服还要安装FabricProxy，mod显示要安装modmenu，加载条也要安装mod，jar套jar也就 ...
对，同时不同mod搬运同一个前置时还会只选最新的那个使用。只是现在这个特性有点卡顿，asie正在修复
原来背后有这样的故事
原来背后有这样的故事
坐等填坑。
没想到一段时间没关注后不仅原版巨变，连mod api都换了几波。
没想到一段时间没关注后不仅原版巨变，连mod api都换了几波。
本帖最后由 1a2s3d4f1 于 2019-6-30 21:59 编辑
fabric默认无法探测tps（不排除额外mod）fabric版本的星系https://github.com/StellarHorizons/Galacticraft-Rewoven（试图移植forge的tps获取指令代码失败了） 如果某个mod的方块/实体出错导致崩溃，fabric无法移除出错方块/实体，靠其他mod实现这个功能
fabric默认无法探测tps（不排除额外mod）fabric版本的星系https://github.com/StellarHorizons/Galacticraft-Rewoven（试图移植forge的tps获取指令代码失败了
） 如果某个mod的方块/实体出错导致崩溃，fabric无法移除出错方块/实体，靠其他mod实现这个功能1a2s3d4f1 发表于 2019-6-18 18:26
fabric默认无法探测tps（不排除额外mod）fabric版本的星系https://github.com/StellarHorizons/Galacticraf ...
tps的话个人不推荐forge内置的这种，一般你安装个warmroast的检测效果更好（或者可以使用原版的/debug命令）
wegood9 发表于 2019-6-18 16:01
坐等填坑。
没想到一段时间没关注后不仅原版巨变，连mod api都换了几波。
forge大开刀的时候给了新api一些空间嘛，但是改进后forge现在看来后劲不足，fabric满足了forge做不到的一些需求
感谢楼主dalao的科普嗷！
本帖最后由 2714491883MP 于 2019-7-11 11:08 编辑
dalao好！
我找到了些可能奇怪的问题，不知道dalao可否回答
从某些角度看，1.14下Fabric的很多Mod具有创意，给人一种1.7.10的清新感
但Mod社区也因此分成了Fabric和Forge 2大块
不过
Forge不会去支持Fabric，而Fabric无法提供Forge的大型Mod生态
这样，未来的MC Modding既有可能会分成2块（其实现在已经这样了），一边是Fabric的轻量Mod，另一边是Forge的FTB大型Mod体系
最近的趋势是，新的模组作者都使用Fabric，老的Mod也也涌向Fabric的趋势（VanillaFix，ReplayMod），这样，随着时间的推移，FTB下的大型Mod体系中很多看似微不足道却举足轻重的Mod（VanillaFix其实就是其中之一）走向Fabric，Forge下的Mod体系几乎会解体，而Fabric无法提供Forge那样的大型Mod生态，对MC Modding是个毁灭性的打击。
另一种可能是，FTB下的大型Mod体系依旧存在，但是百年没有变化，缺少新鲜血液，Fabric虽然生意红火，但是无法建立大型的Mod生态，到头来1.7.10还是Mod最辉煌的版本，MC Modding就和PVP和小游戏一样，辉煌永远留在1.7
liach 发表于 2019-6-18 22:59
forge大开刀的时候给了新api一些空间嘛，但是改进后forge现在看来后劲不足，fabric满足了forge做不到的一 ...
dalao好！
我找到了些可能奇怪的问题，不知道dalao可否回答
Wouldn't all that new modloaders (Rift for 1.13, Fabric for 1.14) fragmentate the modding community as time goes on?
从某些角度看，1.14下Fabric的很多Mod具有创意，给人一种1.7.10的清新感
但Mod社区也因此分成了Fabric和Forge 2大块
不过
LexManos Posted June 14:
Anyways, getting tired of answering this. Forge will never use Fabric. Fabric's core design of "screw it everyone's a coremod!" is NOT feasible for a large compatible modding ecosystem. Forge's major rewrite is done, which means updates should be back to our normal same day target. Sorry for being 'slow' because we decided to cleanup 8 years of technical debt and plan for the next 10 years.
Forge不会去支持Fabric，而Fabric无法提供Forge的大型Mod生态
这样，未来的MC Modding既有可能会分成2块（其实现在已经这样了），一边是Fabric的轻量Mod，另一边是Forge的FTB大型Mod体系
最近的趋势是，新的模组作者都使用Fabric，老的Mod也也涌向Fabric的趋势（VanillaFix，ReplayMod），这样，随着时间的推移，FTB下的大型Mod体系中很多看似微不足道却举足轻重的Mod（VanillaFix其实就是其中之一）走向Fabric，Forge下的Mod体系几乎会解体，而Fabric无法提供Forge那样的大型Mod生态，对MC Modding是个毁灭性的打击。
另一种可能是，FTB下的大型Mod体系依旧存在，但是百年没有变化，缺少新鲜血液，Fabric虽然生意红火，但是无法建立大型的Mod生态，到头来1.7.10还是Mod最辉煌的版本，MC Modding就和PVP和小游戏一样，辉煌永远留在1.7
那么Sponge会推出Fabric版本吗
因为所以
2714491883MP 发表于 2019-7-11 11:05
dalao好！
我找到了些可能奇怪的问题，不知道dalao可否回答
Fabric 和 Forge 的分歧会有，但是因为两个主要还是基于 Minecraft 源码的，搬运起来不会太难。
LexManos 的话我个人认为不足为信。Fabric 的 mod 不一定需要 mixin 或修改字节码。同时，LexManos 名义上说清理了过期老代码，但是实际上 Forge 还有很多问题老代码，而且照常忽略 modder 的需求。
Fabric 有大型 mod 生态，现在也有大型整合包（虽然包里面的大型 mod 很少）
Forge 实际上和以前生态不同了。现在的 Optifine 都和 Forge 分道扬镳了，前景不妙啊。
tian051011 发表于 2019-8-6 11:29
那么Sponge会推出Fabric版本吗
Sponge 内部决定不会提供官方实现。
Sponge 的开源许可（MIT License）允许任何人自己去实现（但是估计没人有空）。
如果有实现，理论上只使用 SpongeAPI 的 Sponge 插件可以基于其运行。
新生fabric也许是一个新的起点。支持一下。
我等官方肝出API和加载器
本帖最后由 1a2s3d4f1 于 2019-10-15 22:07 编辑
似乎有2个关于forge与fabric的项目，一个是加载forge mod(不能加载forgemod的class文件）一个是把forge mod搞成fabric mod
1a2s3d4f1 发表于 2019-10-12 17:50
似乎有2个关于forge与fabric的项目，一个是加载forge mod(不能加载forgemod的class文件）一个是把forge mod ...
最近patchwork比较火，而且patchwork已经能够处理一些基础forge mod了
我觉得以后Fabric会加上可以运行大型mod的代码
也罢，Forge现在这微操是要玩完的节奏（也不一定，毕竟工业2，建筑，林业，神秘这些老牌mod还没移植到Fabric上）
现在curseforge上mod模块化越发明显了，大概是因为1.14.4的轻量化，我看到有个作者直接把exu的各种东西拆了做成一个个mod了，这下可能功能性mod和大型环境型mod差别会越来越大吧…
锁相环则 发表于 2019-10-30 10:51
现在curseforge上mod模块化越发明显了，大概是因为1.14.4的轻量化，我看到有个作者直接把exu的各种东西拆了 ...
主要是移植新版本方便
现在不懂点编程连游戏都玩不好了
66666666666666666666666666666666
本帖最后由 1a2s3d4f1 于 2019-12-16 12:54 编辑
fabric 的注册表模块效率不高，遇到剃除填充了注册表的mod(指那种添加大量装饰块的mod)，就会缓慢去除注册表中的移除项目，但是一个一个去也太慢了吧没内存的问题
1a2s3d4f1 发表于 2019-12-12 21:59
fabric 的注册表模块效率不高，遇到剃除填充了注册表的mod(指那种添加大量装饰块的mod)，就会缓慢去除注册 ...
移除注册表只会在游戏启动或者玩家加入世界/读取世界的时候处理。是说mod客户端连原版服务器进去的时候移除注册表项目太慢？
liach 发表于 2019-12-14 17:32
移除注册表只会在游戏启动或者玩家加入世界/读取世界的时候处理。是说mod客户端连原版服务器进去的时候移 ...
mod客户端进入存档的时候因为移除了mod而移除注册表的项目，但是不知道怎么回事1秒1个项目的速度移除，遇到物品多的mod被删掉就可以卡更久
为什么一个讨论帖子那么专业啊！！
1a2s3d4f1 发表于 2019-12-14 18:57
mod客户端进入存档的时候因为移除了mod而移除注册表的项目，但是不知道怎么回事1秒1个项目的速度移除，遇 ...
嗯，很奇怪，你有stacktrace或者性能报告吗
liach 发表于 2019-12-16 08:05
嗯，很奇怪，你有stacktrace或者性能报告吗
抱歉，之前因为内存没分配足，是之前太卡了，本地世界的tps也是各位数<10（1.14.4优化真的烂）
一秒23个项目的移除速度，遇到多的项目要10分钟处理完毕，不知道forge用了什么骚操作，几下就移除完毕了
1a2s3d4f1 发表于 2019-12-16 12:55
抱歉，之前因为内存没分配足，是之前太卡了，本地世界的tps也是各位数
话说你的mod整合包是怎么样的？我自己来试试看，看了下代码没看出瓶颈在哪里
liach 发表于 2019-12-16 16:54
话说你的mod整合包是怎么样的？我自己来试试看，看了下代码没看出瓶颈在哪里 ...
https://pan.baidu.com/s/1dBuGvixh1IDtlF4kMhnB1w
自己整合的mod，莫名卡顿
1a2s3d4f1 发表于 2019-12-16 17:16
https://pan.baidu.com/s/1dBuGvixh1IDtlF4kMhnB1w
自己整合的mod，莫名卡顿
给mod列表我自己打吧，百度盘下载下不动
本帖最后由 1a2s3d4f1 于 2019-12-29 22:43 编辑
UseItemCallback在客户端上有bug，就是如果想在客户端环境下控制玩家物品使用，就会崩溃游戏复制代码
UseItemCallback在客户端上有bug，就是如果想在客户端环境下控制玩家物品使用，就会崩溃游戏
- UseItemCallback.EVENT.register((PlayerEntity playerEntity, World world, Hand hand) -> {
- if (world.isClient) return TypedActionResult.pass(ItemStack.EMPTY);
- if (Config.PREVENT_USING_ITEMS) {
- ClaimData cd = ClaimManager.get(playerEntity.getBlockPos().getX() >> 4, playerEntity.getBlockPos().getZ() >> 4, playerEntity.dimension.getRawId());
- if (!cd.isOwned()) return TypedActionResult.pass(ItemStack.EMPTY);
- if (cd.isOwner(playerEntity.getUuid()) || cd.isMember(playerEntity.getUuid())) {
- return TypedActionResult.pass(ItemStack.EMPTY); //就在客户端上会出现NPE，服务端环境没问题
- } else {
- return TypedActionResult.fail(ItemStack.EMPTY); //相当于让玩家不能用物品，达到领地保护目的
- }
- } else {
- return TypedActionResult.pass(ItemStack.EMPTY);
- }
- });
1a2s3d4f1 发表于 2019-12-29 22:41
UseItemCallback在客户端上有bug，就是如果想在客户端环境下控制玩家物品使用，就会崩溃游戏
见 https://github.com/FabricMC/fabric/issues/470
还是读书好 不然什么都不懂
Mcbbs有你更精彩~
本帖最后由 1a2s3d4f1 于 2020-1-6 21:58 编辑
https://github.com/FabricMC/fabric/issues/458
这个同步bug延续在1.15.1的fabric上，希望能被修复掉
fabric没考虑对原版服的兼容性？
https://github.com/FabricMC/fabric/issues/458
这个同步bug延续在1.15.1的fabric上，希望能被修复掉
fabric没考虑对原版服的兼容性？
1a2s3d4f1 发表于 2020-1-5 13:01
https://github.com/FabricMC/fabric/issues/458
这个同步bug延续在1.15.1的fabric上，希望能被修复掉
fabr ...
可以的话你要从fabric中手动移除registry sync mod(改fabric jar的meta inf里面一个列jar in jar的文件)
liach 发表于 2020-1-7 08:15
可以的话你要从fabric中手动移除registry sync mod(改fabric jar的meta inf里面一个列jar in jar的文件) ...
registry sync mod可以发送一个数据包，如果是fabric server就会接收客户端的数据包并发送数据包给客户端接收，这样就打开registry sync mod的功能，没接收到就禁用registry sync mod
1a2s3d4f1 发表于 2020-1-7 12:55
registry sync mod可以发送一个数据包，如果是fabric server就会接收客户端的数据包并发送数据包给客户端 ...
registry sync主要问题是不看data fixer有没有改过原版的id，所以会有点问题……而且registry sync是直接把存档里的id先在服务端上重定向(remap)然后发给客户端，如果客户端没有重定向机制（registry sync mod）就嗝屁了
liach 发表于 2020-1-7 08:15
可以的话你要从fabric中手动移除registry sync mod(改fabric jar的meta inf里面一个列jar in jar的文件) ...
完全不行，删除后服务端都打不开，客户端删除也打不开
1a2s3d4f1 发表于 2020-1-7 12:55
registry sync mod可以发送一个数据包，如果是fabric server就会接收客户端的数据包并发送数据包给客户端 ...
这个问题该怎么解决？
无敌啦呵呵 发表于 2020-3-8 11:55
完全不行，删除后服务端都打不开，客户端删除也打不开
不要作死，这问题也没什么大事，没必要删