游戏版本1.20.1

前言

如果你下定了足够的决心，点击上方的目录，直接跳转到准备工作一栏开始你的工作。

如果你只是有这个想法，那么不管你打算做什么样的插件，指令也好，数据包也好，或者是一整个模组，最重要的一点就是克服对未知的恐惧，不能说看到一堆看不懂的代码，就知难而退了，写这种技术类的文件要有足够的耐心。另外，即使你对于JSON一窍不通也不重要，因为你完全可以先了解一个文件的作用，然后用复制粘贴来进行自己的魔改。

另外，无论你要做什么样的包，一定不能把MC的本体发出去，这是违规的。

了解原版与各种模组的压缩包结构

如果你用的是PCL或者HMCL启动器，那么你应该可以发现在你的版本文件夹里面有一个和版本名称完全相同的压缩包，比如这样：

这里就是[MC] 我的世界原版 (Minecraft)这个“模组”的所有数据包和资源包，点开他，然后随便找一个模组的压缩包，再次打开，你会发现这两个压缩包里面的结构几乎一模一样。几乎每个模组，甚至不能算模组的我的世界原版，都有内置的数据包和资源包，这是它们不可被分割的一部分，事实上，如果你查看过游戏加载过的资源包，你会发现有一项叫做模组资源，而如果你输入/datapack list，然后检查这两项内容，你会发现你装的模组全部被数据包和资源包成功识别了，这直接证明了模组也使用了数据包和资源包的技术。首先直接忽略除了名为data（数据）和assets（资产）以外的所有文件和文件夹因为剩下的基本上都是些JAVA代码相关的玩意，我要是会，那就直接去做正牌模组了，在添加模组识别必要文件前，不要把这两个文件夹直接放在同一个包里，因为其中数据包只能读取data文件夹里的内容，而材质包（其实应该叫纹理包）和汉化包等全部隶属于资源包，只能读取assets文件夹里的内容。数据包和资源包都需要pack.mcmeta文件，只要有这个文件，无论你把这些文件装在一个文件夹还是一个正常压缩成.zip的压缩包里，它们都可以被原版读取。由于游戏运行时压缩包不能被更改，而数据包和资源包本身是可以在游戏存档运行时重载的，所以可以使用文件夹实现热修改热重载，否则改一次数据包就得重启一次游戏。

可覆盖性

大家可能会发现，有些模组的数据包/资源包里面放了点其他命名空间下的数据，这其实就是每个模组之间形成兼容与覆盖的原因。一个模组的兼容性的好坏，与其数据包的适配程度密不可分，这个就不详细介绍了，那么，如果同样的命名空间出现在了多个数据包/资源包里面该怎么结算呢？答案是，模组数据包/资源包会优先加载，其他途径带来的数据包/资源包会在这之后加载，而同一个文件夹里面的不同的模组/数据包/资源包也有先后顺序，在文件夹中的名称（不是命名空间ID）的首字母，越靠近Z的越靠后，例如，EMI可以读取JIE的内容从而兼容其他模组的配方，但是一旦EMI先加载了，那么某些模组的配方就会丢失，这时候我们可以将EMI置底，就像这样：

然后你会发现，你的合成表们回来了。无需担心这样会导致附属识别不到前置的问题，因为虽然加载的时候有顺序，但是模组判断需求关系这一步是游戏启动时一步到位的。

但是，虽然数据包和资源包都可以被覆盖，但不是说你写成什么样的路径数据包就能直接读取，实际上，想要加载新的数据包里的内容，模组本身必须写适配数据包的接口，一切不适配数据包的只能在模组内的数据包里被修改，这时只能用kubejs及其附属进行进一步的操作。而资源包就没有这个问题，基本上路径对了就能正常覆盖和调用。

注意

1：不要想着投机取巧，把资源和数据放在同一个文件夹里面，给这个文件夹取名assets然后用资源包全局加载，数据包和资源包对于格式和结构的要求很高，因格式错误等读取失败的文件全部都不会在游戏内加载。

2：数据包不支持其他压缩格式，如果你发现你用错了格式压缩，不要试图通过改后缀的方法更改，这是不能被原版识别的。

数据包与资源包的共同点：命名空间ID

不要被这个几个奇怪的字吓到了，实际上，命名空间ID用大白话说就是“名字”，系统用来整理来自不同模组的数据的名字，比如说我创建一个名为“李华”的文件夹，由于李华本来就带了一个装了一点铅笔屑的卷笔刀，一把没削的铅笔和一把削过的铅笔。当我用数据包向其中输入配方时，这个配方就会被识别为：”李华的没削的铅笔“通过“李华的卷笔刀”合成出“李华的削过的铅笔”和”李华的铅笔屑“，而我用资源包用同样（当然assets这个文件夹名和data不一样）的路径在其中放入一张图片，然后写了一个纹理加载JSON文件，那么这张图片就会把原版黑紫块的铅笔变成一根栩栩如生的铅笔。

原版数据包里面首先会嵌入一个名为minecraft的文件夹，而群峦传说：次世代的叫tfc，玩过/give 自己 钻石 这样的指令的玩家都知道，minecrfat:diamond的前面必须打上minecraft的大名，如果是群峦的钻石，则是tfc:gem/diamond，这个就叫做命名空间ID。为了防止相同名称的配方或者是物品被混淆，命名空间应运而生。利用好命名空间ID可以实现一些神奇的效果，例如，用kubejs批量禁用一个模组的所有配方，但是又想留几个，不想重新写，也不想一个一个删，怎么办？把不想被禁用的配方拿出来，放进另一个命名空间里recipes下的任意位置即可。有的人可能会问了，我把一个模组里的配方放进其他模组的文件夹里，会不会不能读取？其实是有可能的，但是一般情况下，模组特色合成配方会加上一些用于辅助读取的字段，例如：

最上面一行就是用来识别模组用的，只要这个模组在，那么这个配方就可以被读取，当然，随着配方类型的变化，下方的参数也会不一样，毕竟原版没有哪个配方会像图里这样要求温度达到300摄氏度。命名空间的适用范围特别广泛，几乎一个模组里面所有需要被识别的内容都需要加上它们对应的命名空间ID。

在数据包/资源包里，只要是带上了只有命名空间ID的数据（包括省略了”minecraft:“的），基本上都是模组本身注册完的，有就是有，没有就是没有，数据包是改不了这些的，只有这种”命名空间ID：/路径“格式的才能自定义。

准备工作

准备好一个文本编辑器，推荐VScode或者是他的绿色版本：Visual Studio Code - Insiders，这两个功能和界面是一样的别弄成紫色版的VS了。

在编辑器里面点击这个按钮，可以安装一些属于这个编辑器的“模组”必装的“模组”是：

1，Chinese (Simplified) (简体中文) Language Pack for Visual Studio Code，提供软件本身的汉化。

2，Unicode conversation，提供一键让纯UTF-8文本转化成unicode的快捷方式，简单来说就是把UTF-8编码下的中文“乱码”变成正常的中文。

3，NBT Viewer，可以打开.nbt后缀的文件。

数据包

我们都知道，数据包里面的所有基本数据存储单位都是JSON源文件，也就是那些.json后缀的文件，那么，编写数据包的整体思路大致就是找到你想变更的模组，打开他的压缩包，有目的性的翻一翻，然后一路找到你要改的具体的那一个JSON文件。当然，为了防止各位毫无头绪，我拿原版数据包给各位解读一下每个文件夹里面放了什么。

advancements

这个文件夹里的内容是每个进度的触发细则。注意，这不是原版的触发器，触发器只是个代号，就像是合成表的类型一样，而使用什么物品或者击杀什么实体才能达成这个成就，装在这些源文件里面。原版成就“交易”示例：

注意，在原版的数据包里面，只有前面几个和最后一个才是和进度本身有关的，而倒数第二个recipes是解锁原版配方进度的，非原版几乎不用。

chat_type

聊天信息类型，比较冷门，示例：

这个功能的最强用途仅仅是定义某种类型的聊天信息的颜色，只看上面这张图未免有点抽象，这是一条帮你大致了解这个功能的表格

（图片来自MCiki）

damage_type

一些定义伤害类型的数据，注意：1，原版数据包这里的id省略了命名空间ID。2，这个文件的作用是调整死亡信息以及增加的消耗度（俗称疲劳值，累计一定消耗度扣除饱和度和饱食度）我还真是头一回了解到有些伤害是可以加速消耗饱和度的，3，这些源文件还可以给伤害类型加一些额外的参数，例如造成伤害的音效，造成伤害与难度的联系以及致死时的消息显示形式，示例：

dimension_type

显然，这是维度类型。这里你可以批量操作一些维度与那些刻意的游戏设计之间的联系，示例：

这里参数比较多，我附一张wiki上的辅助图：

loot_tables

战利品表存放位置，使用NBT标签的时候可以调取这其中的战利品。这里的路径不重要，因为调取的时候是按照路径输入，只要保证自己不把战利品表搞混就行了。战利品表的内容比较多，格式化之后往往都是上百行，这里就不展示了。

recipes

所有的合成表，由于合成表的读取不依赖于路径，所以你的合成表可以在这个文件夹里面随便放原版就是随便放的。当然，还是建议分分类。示例：

structures

所有结构的数据储存位置。

tags

低版本的矿物词典，现在的标签，作用非常简单，就是在可以使用标签的时候进行多种输入的统一。不仅是物品，方块，流体，甚至是世界生成都可以使用标签。示例：

trim_material

盔甲纹饰的材质（真·材质），在这些文件里面你可以修改纹饰材质名称显示在物品栏里面的RGB颜色，以及定位这些名称使用哪一条翻译，这个后面会提到。示例：

trim_pattern

和上面材质差不多，不过这个是加载盔甲的具体纹饰模型的，相当于资源包里的models。没错，这个功能不在资源包里面，而是在数据包里。示例：

worldgen

刚才提到了，数据包不能按照路径直接替换数据，而是必须被接口适配。此功能非常不稳定，我当时修改其他模组的世界生成的内容时一改就显示数据损坏进不去游戏，目前wiki显示此内容处于测试阶段，就不展示了。

材质包/汉化包/资源包

首先，材质包（纹理包）和汉化包都属于资源包，因为材质包所需的贴图在assets/ID/textures里面，而汉化包所需的翻译文件在assets/ID/lang里面lang其实是language的缩写。

atlases

纹饰，木制方块等物品/方块的集成加载文件，众所周知有些模组大量添加木质方块，要是全手绘的话手都要废了，这些文件就是用来解决这个问题的。比如，原版的每一件盔甲对应每一种材料都写了一个模型加载文件，如果一共有10件盔甲和10种纹饰，那么一共就是10×10个模型文件，但是这些文件还需要二次调用，因为没有纹饰的盔甲也要加载模型，所以需要110个文件才能完整加载所有的纹饰。群峦传说优化了这一点，tfc的盔甲纹饰利用了这里的block.json加载，这样一来10件盔甲可以按照纹饰在游戏内加载，只需要10个文件就能实现原版110个文件的效果，非常的先进，利用这一个参数甚至可以兼容其他模组提供的纹饰，比如：在使用资源包前，Elytra Trims打上模组的材料的时候不会显示纹饰，只有原版的鞘翅贴图，而使用资源包后画面就会变成这样：

bolckstates

方块状态映射文件，与models配合加载有多种状态的方块的贴图的文件。

font

字体文件。详见秦始皇也玩MC？自定义字体教程 - [MC]我的世界原版 (Minecraft) - MC百科|最大的Minecraft中文MOD百科 (mcmod.cn)。

lang

语言翻译文件，示例：

是不是很乱？没关系，右键点击格式化文档：

看不懂怎么办？没关系，点击右键按下这个按钮（需要安装上面的插件）

这些unicode就变成了正常的中文，成为标准的汉化文件了。

注意，zh_ch是简体中文，zh_tw是繁体中文-台湾，zh_hk是繁体中文-香港。

models/particles

贴图是不能自己沾在物品上的，需要加载模型，models加载方块和物品的模型，而particles加载粒子的模型。你可能注意到过，虽然大部分物品贴图都是16✖16的，但是有些物品是横着拿的，比如铁锭，有些物品是竖着拿的，比如铁剑，还有的物品是立体的，比如各种方块，这些都和models有关。示例（这就是上面的鞘翅兼容使用的models文件）：

shaders

着色器。详见着色器 - 中文 Minecraft Wiki。

text

文本类文件，例如闪烁标语等。

textures

贴图文件，从方块到物品到GUI，都可以放在这里。GUI路径对了就能自动读取，但是其他的不行，需要用到atlases，models和particles。

一般的物品和方块都是16✖16像素的。画像素级别的画建议使用PS我没有正版用破解版模拟一下。示例：

sounds

游戏音乐的存放和加载文件。音乐文件必须是.ogg格式而不能是.mp3格式。

全局数据包和资源包

原版的数据包想要存放必须在存档里面找到数据包文件夹，或者像加载光影包一样拖进游戏窗口里的对应位置，而资源包虽然可以放在版本文件夹的资源包文件夹里面，但是这些数据包和资源包是不能被自动应用在所有存档里面的，这时候就需要安装kubejs，就算你JAVAscript一个字也不会，连抄都不想抄，这个模组也能解决一个经典问题——全局数据包，就像开放式加载那样。运行一次游戏，找到版本文件夹中的kubejs/data这个文件夹，就像这样：

而旁边的assets也是一样的，存放资源包。

简易模组

刚才提到了，由于数据包和资源包不能同时读取，但是把资源包和数据包分开发布有点太麻烦了，因此，我们可以添加一些文件使其被识别成为一个模组。我以[MFS] MC百科闪烁标语 (MCmod Flashing Slogan)为例，forge端的模组需要添加一个名为META-INF的文件夹，然后在其中放入至少两个文件，一个名为MANIFEST.MF，格式是：

Manifest-Version: 1.0
Specification-Title: MC百科标语
Specification-Vendor: mcmodstsareus
Specification-Version: 1
Implementation-Title: 1.16.5
Implementation-Version: 3.2
Implementation-Vendor: mcmodstsareus
Implementation-Timestamp: 1145年 1月4日 19:19:8

另一个名为mod.tolm，格式是：

modLoader="javafml" #mandatory
loaderVersion="[*,)"
license="阿巴阿巴"
[[mods]] #mandatory
modId="mcmodst" #mandatory
version="3.2" #mandatory
displayName="MC百科标语" #mandatory
logoFile="logo.png"
credits="热血少年小乐,FeO_Fe2O3,初雪·冰,187J3X1,重生是希望"
authors="热血少年小乐"
description='''
emmmmmmmmmm,这个mod本质上就个资源包(还有个输出日志的代码),需要解释吗.. by 187J3X1
'''
# This version range declares a minimum of the current minecraft version up to but not including the next major version
    versionRange="[*,)"
    ordering="NONE"
    side="BOTH"

但是这么做其实不够，你还得想办法在com文件夹里的main.class里写入你的自定义信息，而想要把可编写的.java转化成不可编写的.class比较困难。

同理，fabric端和quilt端的也可以通过拆包的方式进行解读。

整合包

整合包本质上就是把你自己的版本文件夹里面所有需要搬运的文件全部打包成一个压缩包，供其他玩家游玩，因此，制作整合包前学会使用kubejs是不可或缺的。但是，本篇教程默认了你会使用kubejs，只阐述如何导出整合包。

方法一：curseforge APP

我们都知道，curesforge是一个类似于MCmod的平台，但其实他是有一个启动器APP的。在curseforge官网下载APP，将语言设置为中文虽然是机翻，点击创建自定义配置文件其实是游戏版本

随便点点，点击创建

然后在下图所示的界面点击打开文件夹，这就是该版本的文件夹。

把模组和各种配置文件等文件夹复制进来，甚至是一些用于提供信息的文本文件，只要它们不会干扰到游戏的正常运行，你可以放任何你想要放的文件。

最后，回到上面那张图里的页面并点击导出配置文件，你的整合包就被导出了。但是，这个整合包只能被curseforge启动器安装。

方法二：modrinth APP

我……modrinth是……，但……。在modrinth官网下载APP。这个APP和curseforge的主要区别就是完全不支持中文，以及更新文件夹后需要重启一次APP。点击左下角的加号按钮新建一个游戏版本

除了游戏版本，forge（当然也可以是别的），版本名称，和icon以外不建议乱动，点击creat创建。

点击folder打开文件夹

按照一样的方式，点击export modpack完成打包

方法三：HMCL启动器

打开HMCL启动器，点击要导出的游戏版本

点击管理-导出整合包

点击中间的那一个

然后随便点点就可以导出了。

注意事项

首先，如果你想要修改原模组的数据包或者是资源包，请使用本教程里面提到的方式，不要直接在模组压缩包里修改，这样不便于更新与排查错误。

其次，当你遵守相关的协议，你可以把你的整合包发布到bilibil，mcmod，curseforge或者是modrinth（后面两个要求比较高）。

最后，不是游戏版本里的每一个文件都需要导出的。

无需导出

一般来说，只要名称为某一个模组的都不需要导出，当然像kubejs这种存放了重要数据的不能不导出。游戏存档也不需要（除非你自己建了一个特殊的存档，没他玩不了）。这些内容带到其他玩家的服务端可能出问题。logs是日志，crash_report是崩溃报告，native是原版文件，这些都是不需要导出的。

可以不导出

option是游戏设定，包括默认键位等一切你自己在游戏内调整过的设置。shaderpack是光影包，需要遵守协议。

必须导出

1，版本配置文件，所有模组的版本配置文件都在这里。

2，默认配置文件，这里面的所有文件会自动生成在新创建的存档的serverconfig文件夹里面。因此，你可以把所有服务端配置文件放在这里供玩家自动使用。但是，这些文件不能自动更新，如果你要更新这个里面的文件，请告诉你的玩家删除存档的serverconfig文件夹以进行更新。

3，刚才提到的全局数据包和资源包，当然也有你的魔改内容存放处。如果你用了其他模组进行魔改，那么也要记得加入相应的文件夹。

4，所有的模组。