神人MC模组代码大赏

记录在做 Kumo O Tagayasu Everbloom 过程中遇到的神人模组……

预备知识

一个模组的分包正常由以下部分构成，不同的版本、不同的作者可能会有所不同，但是基本是一致的：

• 主类：一个 <模组名称>.java 的文件，用来声明模组、定义 MODID 和 LOGGER、注册模组内的一系列东西。
• init：注册模块，枚举模组中需要注册的物品，之后在主类统一注册。一些比较旧的模组可能会把这些都拆分到各自的模块中。
• client ：客户端模块，模型渲染屏幕按键都在这里。
• data：数据生成模块。手写数据包很容易出错，并且不利于版本的迁移，因此通常会用代码生成。
• compat：联动模块，放置其他模组的联动代码。
• config：配置，有的作者喜欢放到根目录下。
• event：事件，监听 Forge 提供的事件（比如方块破坏、玩家死亡）并进行操作。
• mixin：事件提供的接口不够的时候，会使用 Mixin 强行修改代码，这些用来改代码的代码放在这里。
• block/item/entity/container/tag/worldgen…：字面意思的各种内容

不理解也没关系，最关键的一点是：模组的结构应该是条理清晰、便于维护的，而不是和印度料理一样变成糊糊。

中文混淆大师

项目地址：Admsgenter/Convenient-Storage: The source of Minecraft Mod Convenient Storage

是的，所有的package、class、field和method都是中文！但是我说实话，这已经是这些模组里面最正常的一个了。分包非常清晰，唯一的问题是把 Event 全堆到了主类，很难不让人怀疑他是为了不让 AI 看懂故意用中文混淆的（）

手写数据包的 King

项目地址：ribs498/VintageDelight-master

在我尝试迁移这个模组之前， Pink_Cats 已经做了非常多工作了：duckgun13476/VintageDelight-master: Port version for this mod.。Ta 还原了 1.0.6 的源代码，并且将其迁移到了 NeoForge 1.21.1，只是留下了一些 Bug 没修。我寻思，这个模组内容也不多，使用量也大，就修复一点点旧 Bug，应该不会有多难吧？然后我就看到了这个：

datagen 一共三个类，第一个类不是 datagen，第二个类是入口，第三个类只写了腌渍罐。

难怪一大堆数据包相关的 Bug，合着你数据包和资源包全 TM 是手写的是吧！

我让 Codex 跑了两天两夜，才终于把这一大堆数据包资源包转为用代码生成；而且由于资源包书写不规范，Codex 还出现了不少错误，经过反馈后三天才搞定。

你以为这就结束了吗？不不不，这个模组的逆天之处远不及如此：

17 个一模一样的，没有实现任何功能的类！按照摸里傻的说法，只有 MCr 模组会这样写；要不是这个模组没有 MCr 的影子并且开源，真得怀疑这个模组究竟怎么写出来的了。

这个模组还有一个经典 Bug，在背包全部装满时，手持厨师帽右键交换头盔，会直接吞掉之前的头盔：

那么这个模组究竟干了什么呢？让我们来看看：

它先将玩家的头盔脱下，塞进背包，然后再装上厨师帽。这个过程没有检查背包是否已满，因此如果背包是满的，之前的头盔就会塞不进背包而直接吞掉。

但是问题又来了：原版的 ArmorItem 本来就有右键换掉身上装备的功能，这样写不是纯纯没事找事？于是我往上看……

public class ChefHatItem extends Item {

？神金啊？为什么不继承 ArmorItem ？然后我让 Codex 改成继承 ArmorItem，模型变成了基础皮革套，我才想起来如果写盔甲，模型是需要用代码定义的。于是我又让 Codex 按照原本的模型改成代码，炸了。于是我去看了这个模型：

乍一看一切正常对吧？如果我们放到 Blockbench 里面去看呢？

我草，怎么不是箱型 UV 啊？合着你就为了省点贴图大小，包了这么一顿饺子是吧？

不仅于此，为了实现手上的贴图和戴在头上的模型不同，Ribs 还干了这么一茬事：

不是，"loader": "forge:separate_transforms" 是什么鬼东西啊？为了在不同渲染状态下渲染不同模型，这是从什么犄角旮旯里挖出来的特性啊？

我修了一晚上这个东西，无果，遂将其删除。拉倒吧您！