同步官网文档8m_25d

mconline/15-玩法组件教程/6-认识附加包/0-摘要.md

@@ -0,0 +1,15 @@
+---
+front: https://nie.res.netease.com/r/pic/20211104/69055361-2e7a-452f-8b1a-f23e1262a03a.jpg
+hard: 入门
+time: 5分钟
+---
+
+# 摘要
+
+在本章中，我们将一起认识**附加包**（**Add-on**）.
+
+- 在第一节（*理解附加包的结构*）中，我们将一起了解附加包的结构，认识**资源包**（**Resource Pack**）和**行为包**（**Behavior Pack**），以及它们之间的区别。
+- 在第二节（*了解附加包的功能*）中，我们将一起学习附加包的功能，分别从资源包和行为包的角度了解附加包都有哪些功能。
+- 在最后一节（*挑战：亲手新建一个附加包*）中，我们将通过一个挑战，亲手创建一个附加包并导入我的世界开发工作台。
+
+本章关键词：附加包 资源包 行为包 基岩引擎 清单文件 定义文件 脚本文件 纹理包 光影包

mconline/15-玩法组件教程/6-认识附加包/1-理解附加包的结构.md

@@ -0,0 +1,108 @@
+---
+front: https://nie.res.netease.com/r/pic/20211104/69055361-2e7a-452f-8b1a-f23e1262a03a.jpg
+hard: 入门
+time: 10分钟
+---
+
+# 理解附加包的结构
+
+接下来在本节中，我们将着重且正式介绍前文中已经出现过多次的**附加包**（**Add-on**）的概念。
+
+## 附加包的概念
+
+附件包这一概念由是微软引入我的世界开发，在我的世界中国版中，网易沿用了这一概念同样作为中国版作品的代名词。从本质上看，国际版和中国版的附加包性质是一样的。**附加包**就是一个带有一个**清单文件**（**Manifest File**）的能够通过**基岩引擎**（**Bedrock Engine**）对我的世界做出修改的**模组**（**Mod**），一般是以一个文件夹、一个压缩包或者某种特殊格式的加密文件出现。
+
+基岩引擎就是我的世界游戏读取并应用附加包的一套接口和程序。我们只要按照规定的格式编写附加包，引擎就不会报错。而清单文件则是一个被称作`pack_manifest.json`或者`manifest.json`的文件，用于引领整个附加包的内容，同时方便基岩引擎了解附加包的类型，使其能够知道应选择何种接口来对接这个附加包。
+
+从上述定义可以看出，附加包根据清单文件中的规定可以分为不同的类型。在中国版中，我们主要使用的便是**资源包**（**Resource Pack**）和**行为包**（**Behavior Pack**）两种附加包。
+
+- **资源包**：资源包是一种用来存放客户端资源的附加包，其中存放的大部分内容都是用于客户端显示、渲染、计算的内容。比如，资源包中常放着方块、物品、实体等物体的纹理，有些资源包中还存放着渲染用的自定义的材质和着色器。对于和行为包一起制作用于特定玩法的一些资源包，还存放着各种方块、物品、实体等元素的客户端定义文件。
+- **行为包**：顾名思义，行为包主要用来存放各种元素、物体的行为。同时行为包还存放着各种用于逻辑计算的表、脚本，决定了游戏的服务端如何运作。比如，行为包中一般用来存放玩法的方块、物品、实体等元素的服务端定义文件，以及交易表、战利品表、维度、群系、地物等用于游戏服务端的数据或逻辑。模组API编写的脚本也存在于行为包中。
+
+国际版和中国版的附加包的格式有相同之处，也有不同之处，这里我们着重介绍中国版的附加包格式。
+
+## 资源包结构
+
+```shell
+RESOURCE_PACK
+│  biomes_client.json # 客户端生物群系配色定义文件
+│  blocks.json # 客户端方块属性定义文件，包括纹理、各向异性和方块形状等
+│  pack_icon.jpg # 资源包的图标，也可以为.png或.tag格式
+│  pack_manifest.json # 资源包的清单文件，也可以单纯地为manifest.json
+│  sounds.json # 声音定义文件，将声音事件链接到对应的系统音效类型上
+│
+├─animations # 客户端动画定义
+├─animation_controllers # 客户端动画控制器定义，主要用于实体骨骼动画
+├─attachables # 附着物定义
+├─effects # 中国版特效定义
+├─entity # 国际版客户端实体定义
+├─fogs # 迷雾定义
+├─font # 字体图片及其定义
+├─items # 国际版客户端物品定义
+├─materials # 材质定义
+├─models # 模型定义，包括了几何、骨架和网格等
+├─netease_items_res # 中国版客户端物品定义
+├─particles # 国际版粒子定义
+├─render_controllers # 渲染控制器定义
+├─shaders # 着色器
+├─sounds # 声音，包含了声音文件和声音事件的定义文件
+├─texts # 本地化
+├─textures # 纹理（资源包必须存在的文件夹）
+└─ui # JSON UI定义
+```
+
+## 行为包结构
+
+```shell
+BEHAVIOR_PACK
+│  pack_icon.jpg # 行为包的图标，也可以为.png或.tag格式
+│  pack_manifest.json # 行为包的清单文件，也可以单纯地为manifest.json
+│
+├─animations # 服务端动画定义
+├─animation_controllers # 服务端动画控制器定义，主要用于实体命令动画
+├─biomes # 国际版服务端生物群系定义
+├─BoxData # 中国版素材
+├─config # 中国版模组配置文件
+├─customBook # 中国版自定义书
+├─blocks # 国际版服务端方块定义
+├─entities # 国际版服务端实体定义（行为包必须存在的文件夹）
+├─features # 国际版地物定义
+├─feature_rules # 国际版地物规则定义
+├─functions # 函数
+├─Galaxy # 中国版逻辑编辑器的宏和模板
+├─items # 国际版服务端物品定义
+├─loot_tables # 战利品表定义
+├─netease_biomes # 中国版服务端生物群系定义
+├─netease_blocks # 中国版服务端方块定义
+├─netease_dimension # 中国版维度定义
+├─netease_effects # 中国版状态效果定义
+├─netease_enchants # 中国版魔咒定义
+├─netease_features # 中国版特征定义
+├─netease_feature_rules # 中国版特征规则定义
+├─netease_group # 中国版物品分组定义
+├─netease_items_beh # 中国版服务端物品定义
+├─netease_micro_blocks # 中国版微缩方块定义
+├─netease_recipes # 中国版配方定义
+├─netease_tab # 中国版物品分类/物品栏分页定义
+├─Parts # 中国版零件定义及其脚本
+├─Presets # 中国版预设定义
+├─recipes # 国际版配方定义
+├─Script_xxx # 中国版的各类Python脚本
+├─spawn_rules # 生成规则定义
+├─storyline # 中国版逻辑编辑器的逻辑文件
+├─structures # 结构
+├─texts # 本地化
+└─trading # 交易定义
+```
+
+以上为完整的资源包和行为包的文件夹模板框架。大部分资源包和行为包无需拥有以上全部的文件夹，只须在需要的时候建立对应的文件夹和相关的文件即可。在上述所有文件中，只有**清单文件**（`pack_manifest.json`或`manifest.json`）是必须正确存在的，这关系到一个附加包是否能被游戏正常识别。
+
+## 资源包、纹理包和光影包的区别
+
+为了避免大家对各种概念的混淆，这里着重强调一下**资源包**、**纹理包**（**Texture Pack**，旧译**材质包**）和**光影包**（**Shader Pack**）的区别。
+
+前面我们已经介绍了，资源包就是一种附加包的类型，一般包含着纹理文件、声音文件、着色器文件、各种客户端的实体、物品、方块定义文件中的全部或者一部分。这种包我们统称为资源包。
+
+而纹理包（旧译材质包）则是指那些基本上只有**纹理**（**Texture**）贴图文件的资源包。一般的纹理包都主要用于修改原版纹理，更改原版游戏的外观，使游戏画风焕然一新。
+
+光影包则是指主要包含**着色器**（**Shader**）文件的资源包，有些光影包还包含一些自定义材质（Material），或暴露出一些纹理（Texture）接口供其他纹理包使用（比如这段时间很火的四合一PBR贴图规则接口）。光影包主要用于改变游戏的渲染效果，同样的纹理在不同的渲染效果下显示的样貌和状态是不同的。阴影效果、水面反射、体积云雾都是光影包能够实现的特效。

mconline/15-玩法组件教程/6-认识附加包/2-了解附加包的功能.md

@@ -0,0 +1,85 @@
+---
+front: https://nie.res.netease.com/r/pic/20211104/69055361-2e7a-452f-8b1a-f23e1262a03a.jpg
+hard: 入门
+time: 10分钟
+---
+
+# 了解附加包的功能
+
+通过附加包，我们可以实现对我的世界各种功能的修改。而前面我们知道，我的世界开发工作台里的编辑器也可以可视化地支持我们对我的世界进行一键式修改。那么，这两者又有什么不同呢？事实上，在编辑器的“AddOn组件”中操作各种功能修改的过程的本质就是一个制作和修改附加包，从而进一步对我的世界游戏进行修改的过程。只不过，编辑器中的修改更加可视化，也更加简便。但是同时相对地，在编辑器中修改的扩展性、灵活性和结果的复杂性都比直接操作文件进行修改低很多。因此，如果我们要制作一些大型的、复杂的、功能全面的附加包，我们还是需要学会如何通过直接操作文件的方式进行内容与功能的修改。
+
+## 定义文件
+
+我们介绍一类在附加包中需要经常接触到的文件，那便是**定义文件**（**Definition File**）。定义文件是一种能够通过其中包含的数据来定义游戏中各种内容的文件类型，通常都是JSON文件，也就是我们所见到的`.json`扩展名的文件。
+
+这些JSON格式的定义文件都采用了一种可带注释的JSON格式。所以如果要看懂并且正确书写定义文件，我们需要先了解**JSON**（**JavaScript Object Notation**，**JavaScript对象表示法**）的格式。这一块知识各位开发者可以在网络上自行了解。
+
+事实上，在上一章的挑战节中，我们在小节开头接触到原版的`Vanilla_Resource_Pack/entity/slime.entity.json`和`Vanilla_Behavior_Pack/entities/slime.json`便是实体的两个定义文件。`slime.entity.json`定义了客户端实体的渲染、模型、纹理等属性，而`slime.json`定义了同一个实体的服务端组件、事件等内容。
+
+定义文件决定了大部分游戏玩法的“初始状态”和少部分“伪逻辑”（比如实体的动画）。也正因如此，定义文件中的内容往往仅仅被称为是一种静态的**数据**（**Data**），而通过这种数据新增或更改的内容、为这种数据提供的接口和组件都被称为是**数据驱动**（**Data-Driven**）的。
+
+## 脚本文件
+
+**脚本文件**（**Script File**）是仅次于定义文件的最重要的文件类型。脚本文件指那些可以被我的世界基岩引擎加载的脚本。在我的世界国际版中，开发者们通常会使用JavaScript脚本，但是在我的世界中国版中，我们可以使用另一种中国版独占且接口功能强大的脚本——**Python**脚本。我的世界中国版中的Python脚本的接口又被称作**模组API**（**Mod API**）。这是中国版开发组精心打造的我的世界模组接口，富有非常强大的功能，并且和数据驱动接口紧密结合，在充分发挥数据驱动接口的功能的同时为其添加”真正“的逻辑，通过“真正”的事件系统和组件工厂实现更加强大的游戏玩法。
+
+脚本文件的内容一般都被称为**脚本**（**Script**），而通过脚本新增或更改的内容、为脚本提供的接口和组件都被称为是**脚本使能**（**Script-Enabled**）的。
+
+数据驱动内容和脚本使能内容紧密结合，可以使附加包作为一个游戏模组拥有相当高的功能上限。
+
+## 依赖行为包的功能
+
+下面我们一起了解主要有哪些功能是依赖于行为包的。
+
+### 实体、物品和方块的服务端内容
+
+实体、物品和方块都是由两个定义文件定义的，一个位于资源包，负责客户端内容，一个位于行为包，负责服务端内容。其中，位于服务端的定义文件往往更加重要，因为服务端定义文件占据了实体、物品和方块的主要游戏表现形式。我们在游戏中看到的各种功能、行为、游戏玩法其实大部分都源自他们的服务端行为。
+
+同时，如果我们要给他们加上脚本逻辑，那么这些脚本也全部位于服务端。所以，实体、物品和方块在行为包的部分尤为重要。
+
+### 维度、生物群系和特征
+
+维度、生物群系和地物的定义也全部位于行为包，因为他们决定了世界生成，而世界生成全部都是在服务端完成的。**维度**（**Dimension**）是一种类似于主世界、下界和末路之地的世界概念；**生物群系**（**Biome**）是决定了类似于哪里是草原、森林、海洋，哪里生成各种生物，以及哪里生成各种地物的的世界概念；而**特征**（**Feature**，又译**地物**）则是一种类似于大到遗迹建筑、小到矿石矿脉的在世界中零散分布的实物。
+
+### 预设和零件
+
+**预设**（**Preset**）是一种预先设定好的可以是方块、实体、玩家或世界的抽象结构，但是可以通过实例化变为世界中真实存在的事物或逻辑。**零件**（**Part**）是一种可以挂接在预设上的逻辑脚本，可以跟随预设发挥作用。这两类的文件全部都应存储在行为包中。
+
+### 模组API脚本
+
+前面我们介绍了中国版独占的一种脚本——模组API的Python脚本。所有的模组API脚本全应位于行为包中。
+
+### 其他内容
+
+配方、交易、战利品表和逻辑编辑器中的宏、逻辑蓝图也全都是由行为包来定义和存储的。
+
+## 依赖资源包的功能
+
+下面我们一起了解主要有哪些功能是依赖于资源包的。
+
+### 纹理贴图
+
+所有的纹理贴图，不论是覆盖原版纹理的贴图文件，还是为了自定义新的玩法而加入的文件，全都应存储在资源包对应的文件夹中。只有这样，客户端才能找到对应的纹理并将其渲染。
+
+### 着色器（光影）
+
+所有的**着色器**（**Shader**，俗称**光影**）都是在资源包中定义和实现的。这是因为着色器是用来提供给渲染器进行渲染的，而渲染器的渲染是仅发生于客户端的内容。
+
+### UI
+
+虽然微软正在研发我的世界的新型UI，但是目前在游戏中广泛采用的依旧是一种沿用了很多年的由JSON驱动的UI格式，我们通常称其为**JSON UI**。JSON UI的定义文件全部位于资源包内，通过基岩引擎解析来发挥作用。
+
+但是，在资源包内定义的UI事实上几乎没有什么逻辑。原版的JSON UI空间大部分都需要绑定硬编码的功能来实现逻辑，但是我们可以使用模组API来为我们自定义的UI添加逻辑。不过，由于使用了模组API，UI逻辑相关的脚本文件全部都应位于行为包内，还请各位开发者谨记。
+
+### 实体、物品和方块的客户端内容
+
+这部分内容往往是实体、物品和方块用于绑定纹理（Texture）、模型和材质（Material）的，而材质会进一步将它们关联到着色器上，方便游戏内的渲染。
+
+当然，物品中也有一些组件是客户端独占的组件，它们被写在物品的客户端定义文件中。
+
+### 模型
+
+显然，模型是用来渲染的。游戏中实体、方块真正的碰撞箱往往与模型不同，大部分时候都比模型要简陋一些，大多是一个大的或一些小立方体的组合，这可以方便服务端的计算。而更为精细的模型则是用来输出在玩家的屏幕上的，服务端无需得知此类精细的信息。所以模型也被安置在了资源包中。
+
+### 其他内容
+
+粒子和特效定义、字体文件及其定义、声音文件（音效和音乐）等内容都是用于在客户端计算和输出的内容，他们都应位于资源包中。

mconline/15-玩法组件教程/6-认识附加包/3-挑战：亲手新建一个附加包.md

@@ -0,0 +1,256 @@
+---
+front: https://nie.res.netease.com/r/pic/20211104/69055361-2e7a-452f-8b1a-f23e1262a03a.jpg
+hard: 高级
+time: 10分钟
+---
+
+# 挑战：亲手新建一个附加包
+
+在本节中，我们一起来完成一个挑战，亲手通过文件级操作的形式制作一个附加包！
+
+## 新建一个完整的附加包
+
+事实上，要制作一个没有功能的附加包格外简单。因为附加包中唯一必须的文件是清单文件（`pack_manifest.json`或`manifest.json`），所以当一个文件夹只包含一个清单文件的时候，我们就认为这个附加包已经具备正常的基本功能了。事实上，一个只含有清单文件的附加包是可以被游戏正常世界并加载的，只是其中任何额外的功能都没有罢了。
+
+不过也正因如此，我们首先便需要为附加包制作正确的清单文件。
+
+### 新建工作区和清单文件
+
+为了使我们的附加包今后可以同时兼容我的世界开发工作的编辑器，我们在创建附加包的文件夹结构时也应稍加注意。
+
+![主文件夹](./images/7.3_main_folder.png)
+
+由于我们希望我们的附加包同时具备资源包部分和行为包部分，所以我们新建一个大的文件夹用于容纳一个资源包和一个行为包。同时，如果我们后续将该附加包导入我的世界开发工作台，那么这个文件夹将用于作为我们的“工作区”文件夹。因此，我们也不要在这个文件夹中再额外放置任何除了资源包和行为包的东西了。在这里，我们使用了`DemoAddon`作为我们的大的主文件夹的名字。需要注意的是，为了后续能够在我的世界开发工作台中导入，我们所有文件夹的名字都需要使用**全英文书写**。
+
+接下来，我们应该建立资源包文件夹和行为包文件夹。在上图中，我们可以看到我已经建立了这两个文件夹。但是，我们还需要注意一点，那便是，**资源包和行为包文件夹的名字不应太过简单**，比如，不应如上述仅仅是用“资源包”和“行为包”的英文名直接来命名。因为在资源包和行为包导入游戏后，不同开发者开发的不同模组的资源包和行为包都会放在一起。所以如果有一个玩家加载了大量的模组，那么就极易可能出现其中两个模组的文件夹名称“撞车”的现象，这将导致出现各种的潜在错误。因此，我们建议将这两个文件夹的名字尽可能修改成“只有你可能写得出来的样子”，或者使用随机生成的数字或字母来命名。这样可以在最大程度上避免重名而导致的游戏加载失败。
+
+![](./images/7.3_main_folder_random.png)
+
+如图所示，我们使用了随机生成的两串字母和数字来重命名了文件夹。有人会问，咱们给这些文件夹重命名成了不同的样子，那么之后编辑器或者游戏怎么还能知道哪个是资源包，哪个是行为包呢？因为，不管是编辑器还是游戏本身，他们都会通过读取清单文件的方式来区分各种附加包。所以，接下来我们为资源包和行为包建立清单文件。
+
+资源包和行为包都分别需要建立一个清单文件。我们首先在资源包中建立。我们打开我们的资源包文件夹。新建一个名字叫做`manifest.json`的文件。
+
+![](./images/7.3_manifest.png)
+
+用任何一种文本编辑器打开文件，输入我们的清单文件的内容。此时，我们了解一下清单文件的格式。
+
+#### 清单文件格式
+
+以下是一个清单文件的格式：
+
+```json
+{
+    "format_version": 1, // Number类型，清单文件的格式版本（Format Version），在目前的中国版附加包中请填写1。
+    "header": { // Object类型，以下这部分是你的附加包的头（Header），这里是该附加包最主要的信息，所有类型的附加包的清单都必须包含如此的头。
+        "name": "Name", // String类型，该附加包的名字。
+        "description": "Main Description", // String类型，该附加包的简介。
+        "uuid": "f61b3faf-e3f3-448d-b19a-0445f504263b", // String类型，该附加包的UUID，格式为Version 4 UUID：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx，其中x可以为任意数字或a-f的任意字母，不能和其他UUID相同。UUID可以用UUID生成器：https://www.uuidgenerator.net/ 获取。
+        "version": [0, 0, 1], // Array类型，该附加包的版本，格式为“语义化版本（Semver）”格式，即[Major, Minor, Patch]，分别为该附加包的主版本号、次版本号和修订版本号，这里代表0.0.1版本。
+        "min_engine_version": [1, 2, 0], // 格式版本为“1”时为可选，Array类型，该附加包适配基岩引擎的最低版本，格式为“语义化版本（Semver）”格式。若我的世界低于该版本，则该附加包不会工作。该值如若填写，将会影响到游戏中的版本化变更（Versioned Change）接口，比如影响到引擎使用哪种版本的命令和Molang的语法。
+    },
+    "modules": [ // Array类型，以下是该附加包具有的模块（Module），一个模块对应一个附加包所具有的功能，可以有一个模块，也可以由多个模块，但不论有几个，这里都必须是一个数组的形式，而里面的每个模块分别以一个对象的形式存在，并且一个附加包至少要求有一个模块。
+        {
+            "description": "Module Description", // String类型，该模块的简介，不在游戏内显示。
+            "uuid": "9b75733a-cf3b-48fe-9df0-91fb4fc81dfe", // String类型，该模块的UUID，不能和其他UUID相同。
+            "version": [ 0, 0, 1 ], // Array类型，该模块的版本，格式为“语义化版本（Semver）”。
+            "type": "resources" // String类型，该模块的类型，代表了该包拥有哪些功能，在中国版附加包中可以为“resources”或“data”，分别代表资源包和数据包。
+        } // Object类型，第一个模块。
+        // ...
+    ],
+    "dependencies": [ // 可选，Array，该附加包的依赖（Dependency）包，只有当该数组内所有附加包都加载时，该包才会正常加载。其中UUID和版本需要完全对应。当你在游戏里将该附加包加入当前运行的包列表时，如果该附加包有依赖，则其依赖也会自动加入对应列表。建议附加包中的资源包和行为包互为依赖，这样可以最大可能避免“玩家只加载了其中一个包”的情况出现。
+        {
+            "uuid": "a0490260-2b0f-40a2-b31e-bd992ed0a14d",
+            "version": [ 0, 0, 1 ]
+        } // Object类型，第一个依赖项。
+        // ...
+    ],
+    "capabilities": [ // 可选，Array类型，该附加包的权能（Capability，又称固有功能），目前中国版附加包中只有下述两者可用。
+        "chemistry", // 允许使用化学。
+        "raytraced" // 允许使用光线追踪。
+    ]
+}
+```
+
+我们可以看到，一个清单文件是一个JSON对象，其中该对象有如下字段：
+
+- **格式版本**（**Format Version**，`format_version`）：在我的世界附加包中，几乎大部分JSON文件都具有一个格式版本，格式版本代表了该JSON文件使用的**模式**（**Schema**）为哪个版本。换言之，格式版本决定了游戏应该用“什么格式”来读取这个JSON文件。
+- **头**（**Header**，`header`）：头是一个附加包最主要的信息，包括了名称、描述和UUID。
+- **模块**（**Module**，`modules`）：模块是决定一个附加包类型的地方。目前我们可以在其类型字段中使用`resources`来代表资源包，`data`来代表行为包。
+- **依赖**（**Dependency**，`dependencies`）：一个附加包的依赖往往也是一个附加包，此时依赖里的UUID就是那个附加包的UUID。资源包和行为包互为依赖是制作附加包时最方便且可信的填写形式。
+- **权能**（**Capability**，又称**固有能力**，`capabilities`）：该附加包能够使用的固有能力。
+
+例如，我们在我们的资源包的清单文件中如下书写：
+
+```json
+{
+    "format_version": 1,
+    "header": {
+        "name": "Resource Pack",
+        "description": "A demo resource pack",
+        "uuid": "f61b3faf-e3f3-448d-b19a-0445f504263b",
+        "version": [0, 0, 1]
+    },
+    "modules": [
+        {
+            "description": "A demo resource module",
+            "uuid": "9b75733a-cf3b-48fe-9df0-91fb4fc81dfe",
+            "version": [ 0, 0, 1 ],
+            "type": "resources"
+        }
+    ],
+    "dependencies": [
+        {
+            "uuid": "a0490260-2b0f-40a2-b31e-bd992ed0a14d",
+            "version": [ 0, 0, 1 ]
+        } // 依赖行为包
+    ]
+}
+```
+
+我们在我们的行为包的清单文件中如下书写：
+
+```json
+{
+    "format_version": 1,
+    "header": {
+        "name": "Behavior Pack",
+        "description": "A demo behavior pack",
+        "uuid": "a0490260-2b0f-40a2-b31e-bd992ed0a14d",
+        "version": [0, 0, 1]
+    },
+    "modules": [
+        {
+            "description": "A demo behavior module",
+            "uuid": "426f64e6-f008-4965-8a80-ce1bf4184321",
+            "version": [ 0, 0, 1 ],
+            "type": "data"
+        }
+    ],
+    "dependencies": [
+        {
+            "uuid": "f61b3faf-e3f3-448d-b19a-0445f504263b",
+            "version": [ 0, 0, 1 ]
+        } // 依赖资源包
+    ]
+}
+```
+
+这样，我们的两个清单文件就完成了！
+
+### 补充其他文件夹
+
+事实上，当具备清单文件之后，一个附加包就可以正常运作了。但是，我们依旧可以再补充一些我们需要的文件夹，比如，我们需要接下来创建实体，那么我们就可以在资源包中创建`entity`文件夹，同时在行为包中创建`entities`文件夹。
+
+在这里，为了演示需要，我们尝试创建了所有的文件和文件夹。各位开发者可以根据自己的需要自行选择需要创建的文件夹。我们创建好文件夹之后如下：
+
+```shell
+DEMOADDON
+├─behavior_pack_bf114e04
+│  │  pack_icon.jpg
+│  │  manifest.json
+│  │
+│  ├─animations
+│  ├─animation_controllers
+│  ├─biomes
+│  ├─blocks
+│  ├─config
+│  ├─customBook
+│  ├─entities
+│  ├─features
+│  ├─feature_rules
+│  ├─functions
+│  ├─Galaxy
+│  │  ├─Macro
+│  │  └─Template
+│  ├─items
+│  ├─loot_tables
+│  ├─netease_biomes
+│  ├─netease_blocks
+│  ├─netease_dimension
+│  ├─netease_effects
+│  ├─netease_enchants
+│  ├─netease_features
+│  ├─netease_feature_rules
+│  ├─netease_group
+│  ├─netease_items_beh
+│  ├─netease_micro_blocks
+│  ├─netease_recipes
+│  ├─netease_tab
+│  ├─Parts
+│  ├─Presets
+│  ├─recipes
+│  ├─Script_xxx
+│  ├─spawn_rules
+│  ├─storyline
+│  │  └─level
+│  ├─structures
+│  ├─texts
+│  └─trading
+└─resource_pack_8b514eca
+    │  biomes_client.json
+    │  blocks.json
+    │  pack_icon.jpg
+    │  manifest.json
+    │  sounds.json
+    │
+    ├─animations
+    ├─animation_controllers
+    ├─attachables
+    ├─effects
+    ├─entity
+    ├─font
+    ├─items
+    ├─materials
+    ├─models
+    │  ├─animation
+    │  ├─editor_materials
+    │  ├─effect
+    │  ├─geometry
+    │  ├─mesh
+    │  ├─netease_block
+    │  └─skeleton
+    │
+    ├─netease_items_res
+    ├─particles
+    ├─render_controllers
+    ├─shaders
+    │  ├─glsl
+    │  └─hlsl
+    ├─sounds
+    ├─texts
+    ├─textures
+    │  │  terrain_texture.json
+    │  │
+    │  ├─blocks
+    │  ├─entity
+    │  ├─items
+    │  ├─models
+    │  ├─particle
+    │  ├─sfxs
+    │  └─ui
+    └─ui
+```
+
+## 尝试修改方块纹理
+
+我们尝试将一个方块的纹理修改为其他的贴图，然后导入游戏来验证我们的包是否能够成功运作。
+
+我们得知，原版的泥土方块的纹理位于资源包的`textures\blocks`文件夹中的`dirt.png`文件，我们不妨将其替换为基岩的纹理。我们从原版的模板包中找到基岩的纹理，将其重命名为`dirt.png`然后复制到我们资源包的`textures\blocks`文件夹内。如图所示：
+
+![](./images/7.3_block_texture.png)
+
+这样，我们便等于是将原版的某个纹理进行了替换。接下来我们就需要进入游戏验证了。
+
+## 导入我的世界开发工作台并应验效果
+
+为了验证效果，我们需要先将我们的附加包导入我的世界开发工作台。
+
+我们打开我的世界开发工作台，切换到“**作品库**”选项卡，点击右上角的“**本地导入**”按钮，即可弹出一个“导入”对话框。我们输入“作品名称”，在“作品分类”处选择基岩版“附加包”。然后将我们最一开始的那个附加包工作区文件夹输入或“选择”到最下面的地址栏中。点击“**导入**”按钮即可成功导入作品。
+
+![](./images/7.3_import.png)
+
+然后，我们便可以像往常一样，打开编辑器或者直接进入开发测试进行自测了。
+
+![](./images/7.3_dirt_in-game.png)
+
+我们可以看到，我们的泥土的纹理已经全部变成基岩的纹理了！这代表我们的附加包制作取得了成功！接下来，各位开发者们可以进一步根据自己的意愿进行其他附加包内容的文件级创作了。