更新文档导航顺序，添加新页面和翻译内容
This commit is contained in:
boybook
@@ -59,15 +59,16 @@ export default withMermaid({
|
||||
// https://vitepress.dev/reference/default-theme-config
|
||||
nav: [
|
||||
{ text: '首页', link: '/' },
|
||||
{ text: 'Wiki', link: '/wiki' },
|
||||
{ text: 'API文档', link: '/mcdocs/0-欢迎' },
|
||||
{ text: '开发指南', link: '/mcguide/0-欢迎' },
|
||||
{ text: '教学课程', link: '/mconline/0-欢迎' },
|
||||
{ text: 'Wiki', link: '/wiki', activeMatch: '^/wiki/' },
|
||||
{ text: 'API文档', link: '/mcdocs/0-欢迎', activeMatch: '^/mcdocs/' },
|
||||
{ text: '开发指南', link: '/mcguide/0-欢迎', activeMatch: '^/mcguide/' },
|
||||
{ text: '教学课程', link: '/mconline/0-欢迎', activeMatch: '^/mconline/' },
|
||||
],
|
||||
|
||||
sidebar: await generateSidebar(),
|
||||
|
||||
socialLinks: [
|
||||
{ icon: 'qq', link: 'https://qm.qq.com/q/NGIRFwEoMw' },
|
||||
{ icon: 'github', link: 'https://github.com/EaseCation/netease-modsdk-wiki' }
|
||||
],
|
||||
|
||||
@@ -76,6 +77,15 @@ export default withMermaid({
|
||||
text: '在 GitHub 上编辑此页'
|
||||
},
|
||||
|
||||
footer: {
|
||||
message: 'ICP备案/许可证号 <a href="https://beian.miit.gov.cn" target="_blank">浙ICP备2022033471号-1</a>',
|
||||
copyright: 'Made with ❤️ by EaseCation'
|
||||
},
|
||||
|
||||
sitemap: {
|
||||
hostname: 'https://mcwiki.easecation.net'
|
||||
},
|
||||
|
||||
search: {
|
||||
provider: 'algolia',
|
||||
options: {
|
||||
|
||||
File diff suppressed because one or more lines are too long
@@ -28,4 +28,6 @@ features:
|
||||
|
||||
<br>
|
||||
|
||||
> 如果需要查看官方文档，请访问 [我的世界开发者平台](https://mc.163.com/dev/)。
|
||||
> 如果需要查看我的世界官方文档，请访问 [我的世界开发者平台](https://mc.163.com/dev/)。
|
||||
|
||||
> 欢迎加入我们的 [交流QQ群](https://qm.qq.com/q/NGIRFwEoMw)，一起贡献教程和文档吧！
|
||||
72
docs/wiki/animation-controllers/afk-animation-controller.md
Normal file
72
docs/wiki/animation-controllers/afk-animation-controller.md
Normal file
@@ -0,0 +1,72 @@
|
||||
---
|
||||
title: AFK检测器
|
||||
tags:
|
||||
- 配方
|
||||
mentions:
|
||||
- SirLich
|
||||
- BlueFrog130
|
||||
- SmokeyStack
|
||||
- Keyyard
|
||||
- Ultr4Anubis
|
||||
---
|
||||
|
||||
# AFK检测器
|
||||
|
||||
<!--@include: @/wiki/bedrock-wiki-mirror.md-->
|
||||
|
||||
### AFK检测动画控制器
|
||||
|
||||
<BButton color="blue" link="animation-controllers-intro">了解更多动画控制器知识</BButton>
|
||||
|
||||
这是一个用于检测挂机玩家的示例实现。
|
||||
|
||||
::: code-group
|
||||
```json [BP/animation_controllers/afk.ac.json]
|
||||
{
|
||||
"format_version": "1.10.0",
|
||||
"animation_controllers": {
|
||||
"controller.animation.player.afk": {
|
||||
"states": {
|
||||
"default": {
|
||||
"transitions": [
|
||||
{
|
||||
"stands_still": "!q.is_moving"
|
||||
}
|
||||
]
|
||||
},
|
||||
"stands_still": {
|
||||
"on_entry": [
|
||||
"v.afk = q.life_time;"
|
||||
],
|
||||
"transitions": [
|
||||
{
|
||||
"afk": "(q.life_time - v.afk) >= 30 && !q.is_moving"
|
||||
},
|
||||
{
|
||||
"default": "q.is_moving"
|
||||
}
|
||||
]
|
||||
},
|
||||
"afk": {
|
||||
"on_entry": ["/tag @s add AFK", "/say 我现在处于挂机状态"],
|
||||
"animations": ["afk_animation"],
|
||||
"transitions": [
|
||||
{
|
||||
"default": "q.is_moving"
|
||||
}
|
||||
],
|
||||
"on_exit": ["/tag @s remove AFK", "/say 我已结束挂机状态"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
- `controller.animation.player.afk` 是该控制器的唯一标识符
|
||||
- 当[Molang](https://bedrock.dev/zh/MoLang)查询`!q.is_moving`返回false时（表示玩家未移动），状态会切换到"stands_still"
|
||||
- "stands_still"状态会持续检测：若玩家30秒内无移动则进入"afk"状态，否则返回"default"状态
|
||||
- 进入"afk"状态时，会触发"on_entry"中的命令
|
||||
- "animations"字段包含该状态激活期间持续播放的行为动画简称（用法与[资源动画控制器](#animation-controller)相同）
|
||||
- 当玩家恢复移动时，状态将转回"default"状态，并执行"on_exit"中的命令
|
||||
310
docs/wiki/animation-controllers/animation-controllers-intro.md
Normal file
310
docs/wiki/animation-controllers/animation-controllers-intro.md
Normal file
@@ -0,0 +1,310 @@
|
||||
---
|
||||
title: 动画控制器入门
|
||||
nav_order: 1
|
||||
tags:
|
||||
- 指南
|
||||
mentions:
|
||||
- SirLich
|
||||
- solvedDev
|
||||
- Joelant05
|
||||
- MedicalJewel105
|
||||
- stirante
|
||||
- cda94581
|
||||
- ThijsHankelMC
|
||||
- MetalManiacMc
|
||||
- ThomasOrs
|
||||
---
|
||||
|
||||
# 动画控制器入门
|
||||
|
||||
<!--@include: @/wiki/bedrock-wiki-mirror.md-->
|
||||
|
||||
动画控制器（AC）是一种可在资源包（RP）和行为包（BP）中使用的状态机。在资源包中，动画控制器（RPAC）用于播放动画；在行为包中（BPAC），它们用于执行命令和"动画"指令。
|
||||
|
||||
## 什么是状态机？
|
||||
|
||||
状态机是一种特殊的逻辑管理方式，它依赖于一系列状态。每个状态具有两个属性：
|
||||
|
||||
- 当前状态下执行的操作
|
||||
- 如何转移到其他状态
|
||||
|
||||
状态机在各类系统中广泛应用，尤其在传统编程领域。它们不仅存在于Minecraft中！您可以通过[此链接](https://www.itemis.com/en/yakindu/state-machine/documentation/user-guide/overview_what_are_state_machines)深入了解状态机。
|
||||
|
||||
状态机同一时间只能处于**一个**状态。当状态机"运行"时，可以理解为它在不同状态间转移，执行其中的逻辑，并遵循`transitions`规则转移到其他状态。
|
||||
|
||||
## 状态机示例
|
||||
|
||||
状态机的优势在于能够将动画自然分解为逻辑流程，每个状态独立处理自身动画**和**逻辑。
|
||||
|
||||
例如，假设您想为直升机螺旋桨制作动画，但仅在地面时停止旋转。这里有两个状态：
|
||||
|
||||
- `地面状态`
|
||||
- `飞行状态`
|
||||
|
||||
我们可以用前文提到的两个属性来注解这些状态：
|
||||
|
||||
- `地面状态`：
|
||||
- 不播放动画
|
||||
- 若处于空中则转移到`飞行状态`
|
||||
- `飞行状态`：
|
||||
- 播放飞行动画
|
||||
- 若着陆则返回`地面状态`
|
||||
|
||||
以下是状态机的流程图表示：
|
||||
|
||||
|
||||
|
||||
在流程图中，状态用矩形表示，箭头表示状态间的**转移**。让我们看一个更复杂的示例，新增了`爆炸状态`：
|
||||
|
||||
|
||||
|
||||
可见，一个状态可同时转移到多个状态。状态也可以是终止状态（直升机损毁后无需继续动画）。这种分支流程体现了动画控制器的强大之处。
|
||||
|
||||
## 什么是动画控制器？
|
||||
|
||||
动画控制器是Minecraft中用于播放动画和执行指令的状态机。动画控制器文件必须存放在资源包或行为包的`animation_controllers`文件夹中。
|
||||
|
||||
### 将控制器附加到实体
|
||||
|
||||
动画控制器需在实体文件中进行"附加"才能生效。附加AC需要完成两个步骤：
|
||||
|
||||
1. 为动画控制器定义简称
|
||||
2. 通过`scripts`运行动画控制器
|
||||
|
||||
以下示例展示了如何在`animations`中定义AC，并通过`scripts/animate`播放：
|
||||
|
||||
::: code-group
|
||||
```json [RP/entity/helicopter.ce.json 或 BP/entities/helicopter.se.json]
|
||||
"description": {
|
||||
"identifier": "wiki:helicopter",
|
||||
"animations": {
|
||||
"blade_controller": "controller.animation.helicopter.blade"
|
||||
},
|
||||
"scripts": {
|
||||
"animate": [
|
||||
"blade_controller"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
若需要条件触发动画控制器，可添加Molang参数。当参数为真时控制器才会运行：
|
||||
|
||||
::: code-group
|
||||
```json [RP/entity/helicopter.ce.json 或 BP/entities/helicopter.se.json]
|
||||
"scripts": {
|
||||
"animate": [
|
||||
{
|
||||
// 仅在直升机有骑手时播放blade_controller
|
||||
"blade_controller": "q.has_rider"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
### RP动画控制器
|
||||
|
||||
资源包动画控制器位于RP中，可附加到RP实体。用于播放骨骼动画。
|
||||
|
||||
### BP动画控制器
|
||||
|
||||
行为包动画控制器位于BP中，可附加到BP实体。用于执行命令和向实体发送事件。
|
||||
|
||||
## 动画控制器示例
|
||||
|
||||
### 基础示例
|
||||
|
||||
::: code-group
|
||||
```json [RP/animation_controllers/helicopter.ac.json]
|
||||
{
|
||||
"format_version": "1.10.0",
|
||||
"animation_controllers": {
|
||||
"controller.animation.helicopter.blade": {
|
||||
"initial_state": "ground",
|
||||
"states": {
|
||||
"ground": {
|
||||
"transitions": [
|
||||
{
|
||||
"flying": "!q.is_on_ground"
|
||||
}
|
||||
]
|
||||
},
|
||||
"flying": {
|
||||
"animations": ["flying"],
|
||||
"transitions": [
|
||||
{
|
||||
"ground": "q.is_on_ground"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
解析关键点：
|
||||
- `initial_state`: "ground" 表示初始状态
|
||||
- `ground`状态包含转移到"flying"状态的逻辑
|
||||
- `flying`状态播放"flying"动画并包含返回逻辑
|
||||
|
||||
### 完整示例
|
||||
|
||||
::: code-group
|
||||
```json [RP/animation_controllers/helicopter.ac.json]
|
||||
{
|
||||
"format_version": "1.10.0",
|
||||
"animation_controllers": {
|
||||
"controller.animation.helicopter.blade": {
|
||||
"initial_state": "ground",
|
||||
"states": {
|
||||
"ground": {
|
||||
"transitions": [
|
||||
{"flying": "!q.is_on_ground"},
|
||||
{"explode": "!q.is_alive"}
|
||||
]
|
||||
},
|
||||
"flying": {
|
||||
"animations": ["flying"],
|
||||
"transitions": [
|
||||
{"ground": "q.is_on_ground"},
|
||||
{"explode": "!q.is_alive"}
|
||||
]
|
||||
},
|
||||
"explode": {
|
||||
"animations": ["explode"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
## RP动画控制器扩展功能
|
||||
|
||||
资源包动画控制器可触发音效和粒子效果。使用前需在客户端实体文件中预先定义：
|
||||
|
||||
::: code-group
|
||||
```json [RP/entities/custom_tnt.json#minecraft:client_entity/description]
|
||||
"sound_effects": {
|
||||
"explosion": "wiki.custom_tnt.explosion" // 其中wiki.custom_tnt.explosion是在sound_definitions中定义的声音
|
||||
},
|
||||
"particle_effects": {
|
||||
"fuse_lit": "wiki:tnt_fuse_lit_particle"
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
::: code-group
|
||||
```json [RP/animation_controllers/custom_tnt.animation_controllers.json#controller.animation.custom_tnt]
|
||||
"states":{
|
||||
"default":{
|
||||
"transitions":[
|
||||
{"explode_state":"q.mark_variant == 1"}
|
||||
]
|
||||
},
|
||||
"explode_state":{
|
||||
"sound_effects":[{"effect":"explosion"}],
|
||||
"particle_effects": [
|
||||
{
|
||||
"effect": "fuse_lit"
|
||||
// "locator": "<骨骼名称>" 此处也可指定定位器
|
||||
}
|
||||
],
|
||||
"transitions":[
|
||||
{"default":"q.mark_variant == 0"}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
:::warning
|
||||
警告！并非所有粒子效果在此处都有效。若遇到问题，建议尝试其他粒子效果（例如参考烈焰人动画控制器中的示例）。
|
||||
:::
|
||||
|
||||
## BP动画控制器功能
|
||||
|
||||
行为包动画控制器支持两个新字段：
|
||||
- `on_entry`: 进入状态时执行的命令
|
||||
- `on_exit`: 退出状态时执行的命令
|
||||
|
||||
命令类型包含：
|
||||
- 斜杠命令：`/say Hello!`
|
||||
- 实体事件：`@s wiki:transform_into_plane`
|
||||
- Molang表达式：`v.tickets += 1;`
|
||||
|
||||
示例：
|
||||
|
||||
::: code-group
|
||||
```json [BP/animation_controllers/helicopter.ac.json]
|
||||
{
|
||||
"format_version": "1.10.0",
|
||||
"animation_controllers": {
|
||||
"controller.animation.helicopter.commands": {
|
||||
"initial_state": "ground",
|
||||
"states": {
|
||||
"ground": {
|
||||
"on_entry": ["/say 当前处于地面状态！"],
|
||||
"transitions": [
|
||||
{"flying": "!q.is_on_ground"}
|
||||
]
|
||||
},
|
||||
"flying": {
|
||||
"on_entry": ["/say 当前处于空中状态！"],
|
||||
"transitions": [
|
||||
{"ground": "q.is_on_ground"}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
## 动画控制器执行流程
|
||||
|
||||
### 加载阶段
|
||||
- 实体加载时进入初始状态（未定义时使用"default"）
|
||||
- 每Tick执行：
|
||||
1. 播放当前状态动画（循环或单次）
|
||||
2. 检查转移条件，执行首个有效转移
|
||||
|
||||
### 重置机制
|
||||
实体重载时（玩家进出、区块重载等）会重置到初始状态
|
||||
|
||||
## 高级功能
|
||||
|
||||
动画控制器支持变量重映射：
|
||||
|
||||
```json
|
||||
{
|
||||
"format_version": "1.17.30",
|
||||
"animation_controllers": {
|
||||
"controller.animation.sheep.move": {
|
||||
"states": {
|
||||
"default": {
|
||||
"variables": {
|
||||
"ground_speed_curve": {
|
||||
"input": "q.ground_speed",
|
||||
"remap_curve": {
|
||||
"0.0": 0.2,
|
||||
"1.0": 0.7
|
||||
}
|
||||
}
|
||||
},
|
||||
"animations": [
|
||||
"wiggle_nose",
|
||||
{"walk": "v.ground_speed_curve"}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
120
docs/wiki/animation-controllers/death-commands.md
Normal file
120
docs/wiki/animation-controllers/death-commands.md
Normal file
@@ -0,0 +1,120 @@
|
||||
---
|
||||
title: 死亡命令
|
||||
tags:
|
||||
- 配方
|
||||
mentions:
|
||||
- SirLich
|
||||
- BlueFrog130
|
||||
- SmokeyStack
|
||||
- cda94581
|
||||
- MedicalJewel105
|
||||
- Kaioga5
|
||||
- TheItsNameless
|
||||
---
|
||||
|
||||
# 死亡命令
|
||||
|
||||
<!--@include: @/wiki/bedrock-wiki-mirror.md-->
|
||||
|
||||
<BButton color="blue" link="animation-controllers-intro">了解更多关于动画控制器的知识</BButton>
|
||||
|
||||
我将"死亡效果"定义为"当实体死亡时执行某些操作"。以下是几种应该避免的错误实现方式：
|
||||
|
||||
- **在实体文件中检测死亡**：通过添加组件然后尝试在动画控制器中检测该组件。这种方法是错误的，因为实体在被移除前动画控制器没有机会运行。
|
||||
- **通过外部源检测死亡**：例如使用持续运行的命令方块。这种方法并非完全错误，在某些情况下甚至可能是优选方案，但存在性能损耗且容易出错。
|
||||
|
||||
## 使用 q.is_alive 查询
|
||||
|
||||
创建死亡效果的最佳方式是使用`is_alive`查询。只需在动画控制器中创建基于`is_alive`的状态过渡，`on_entry`中的命令会在实体被移除前执行。
|
||||
|
||||
示例动画控制器：
|
||||
|
||||
::: code-group
|
||||
```json [BP/animation_controllers/death.ac.json]
|
||||
{
|
||||
"format_version": "1.10.0",
|
||||
"animation_controllers": {
|
||||
"controller.animation.death": {
|
||||
"initial_state":"default",
|
||||
"states": {
|
||||
"default": {
|
||||
"transitions": [
|
||||
{
|
||||
"dead": "!q.is_alive"
|
||||
}
|
||||
]
|
||||
},
|
||||
"dead": {
|
||||
"on_entry": ["/say 我已死亡！"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
## 在玩家实体上的应用
|
||||
|
||||
对于玩家实体，需要在死亡状态中添加额外过渡来确保状态重置：
|
||||
|
||||
::: code-group
|
||||
```json [BP/animation_controllers/death.ac.json]
|
||||
{
|
||||
"format_version": "1.10.0",
|
||||
"animation_controllers": {
|
||||
"controller.animation.death": {
|
||||
"initial_state":"default",
|
||||
"states": {
|
||||
"default": {
|
||||
"transitions": [
|
||||
{
|
||||
"dead": "!q.is_alive"
|
||||
}
|
||||
]
|
||||
},
|
||||
"dead": {
|
||||
"on_entry": ["/say 我已死亡！"],
|
||||
"transitions": [
|
||||
{
|
||||
"default": "q.is_alive"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
:::warning
|
||||
需要启用实验性玩法
|
||||
:::
|
||||
|
||||
## 使用 minecraft:on_death 组件
|
||||
|
||||
通过在行为包的`entity.json`文件中使用`minecraft:on_death`组件，可以更直接地实现死亡命令：
|
||||
|
||||
1. 在组件部分添加触发逻辑：
|
||||
```json
|
||||
"minecraft:on_death" : {
|
||||
"event" : "wiki:on_death",
|
||||
"target" : "self"
|
||||
}
|
||||
```
|
||||
|
||||
2. 在事件部分定义执行内容：
|
||||
```json
|
||||
"wiki:on_death": {
|
||||
"run_command": {
|
||||
"command": [
|
||||
"say 我已经死了！"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
:::tip
|
||||
使用此方法可以在实体死亡后仍然为其添加计分板分数和标签
|
||||
:::
|
||||
275
docs/wiki/animation-controllers/entity-commands.md
Normal file
275
docs/wiki/animation-controllers/entity-commands.md
Normal file
@@ -0,0 +1,275 @@
|
||||
---
|
||||
title: 实体命令
|
||||
nav_order: 2
|
||||
tags:
|
||||
- 中级
|
||||
mentions:
|
||||
- SirLich
|
||||
- solvedDev
|
||||
- Joelant05
|
||||
- destruc7i0n
|
||||
- Dreamedc2015
|
||||
- MedicalJewel105
|
||||
- aexer0e
|
||||
- cda94581
|
||||
- ThijsHankelMC
|
||||
---
|
||||
|
||||
# 实体命令
|
||||
|
||||
<!--@include: @/wiki/bedrock-wiki-mirror.md-->
|
||||
|
||||
:::warning
|
||||
通过`run_command`事件响应来执行实体命令是更简单的方法，但目前该功能仍处于实验性阶段。
|
||||
:::
|
||||
|
||||
## 动画控制器
|
||||
|
||||
要触发斜杠命令，我们将使用行为包动画控制器。动画控制器应放置在`animation_controllers/some_controller.json`路径下。你可以在[bedrock.dev的实体事件章节](https://bedrock.dev/docs/stable/Entity%20Events)了解更多关于动画控制器的知识。
|
||||
|
||||
简而言之，动画控制器允许我们从行为包中触发事件：
|
||||
|
||||
- 斜杠命令（如`/say`）
|
||||
- Molang表达式（`v.foo += 1;`）
|
||||
- 实体事件（如`@s wiki:my_event`）
|
||||
|
||||
以下是一个动画控制器示例：
|
||||
|
||||
::: code-group
|
||||
```json [BP/animation_controllers/entity_commands.ac.json]
|
||||
{
|
||||
"format_version": "1.10.0",
|
||||
"animation_controllers": {
|
||||
"controller.animation.sirlich_entity_commands": {
|
||||
"states": {
|
||||
"default": {
|
||||
"transitions": [
|
||||
{
|
||||
"on_summon": "1" // 1表示真值
|
||||
}
|
||||
]
|
||||
},
|
||||
"on_summon": {
|
||||
"on_entry": ["/say I have been summoned"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
当实体被召唤到世界时，这个动画控制器会立即执行`/say I have been summoned`命令。如果对工作原理有疑问，请复习Molang、动画和实体事件相关内容。
|
||||
|
||||
简单来说，`states`可以通过`on_entry`子句触发事件。我们使用查询条件在不同状态间切换。除非定义了`initial_state`值，否则实体默认处于`default`状态。
|
||||
|
||||
:::warning
|
||||
当世界/区块重新加载时，查询会重新运行。这意味着`"/say I have been summoned"`命令实际上会在每次实体"加载"时执行——而不仅在被召唤时。
|
||||
:::
|
||||
|
||||
如果需要避免这种情况，需要添加额外查询条件，例如使用`skin_id`查询。首次生成实体时检查`skin_id = 0`，然后将其设置为更高的值如`skin_id = 1`。这样当实体重新加载时就不会再次触发命令。下文将展示具体实现方法。
|
||||
|
||||
## 使用动画控制器
|
||||
|
||||
要将动画控制器添加到实体中，可以在实体定义描述中使用以下代码：
|
||||
|
||||
::: code-group
|
||||
```json [BP/entities/entity_commands.se.json]
|
||||
"description": {
|
||||
"identifier": "wiki:entity_commands",
|
||||
"scripts": {
|
||||
"animate": [
|
||||
"wiki:entity_commands"
|
||||
]
|
||||
},
|
||||
"animations": {
|
||||
"wiki:entity_commands": "controller.animation.wiki_entity_commands"
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
如果对步骤有疑问，请再次查阅[实体事件文档](https://bedrock.dev/r/Entity%20Events)。
|
||||
|
||||
## 通过事件触发命令
|
||||
|
||||
动画状态过渡使用查询条件实现。可查阅[实体查询列表](https://bedrock.dev/docs/stable/MoLang#List%20of%20Entity%20Queries)。在第一个示例中，查询条件简化为`true`，因此命令会自动执行。我们可以使用更复杂的查询条件实现更精细的控制，其中通过组件作为Molang过滤器来触发命令是便捷的方法。
|
||||
|
||||
推荐使用[skin_id](https://docs.microsoft.com/en-us/minecraft/creator/reference/content/entityreference/examples/entityproperties/minecraftproperty_skin_id)组件。
|
||||
|
||||
更新后的动画控制器基于`skin_id`触发：
|
||||
|
||||
::: code-group
|
||||
```json [BP/animation_controllers/entity_commands.ac.json]
|
||||
{
|
||||
"format_version": "1.10.0",
|
||||
"animation_controllers": {
|
||||
"controller.animation.sirlich_entity_commands": {
|
||||
"states": {
|
||||
"default": {
|
||||
"transitions": [
|
||||
{
|
||||
"command_example": "q.skin_id == 1"
|
||||
},
|
||||
{
|
||||
"zombies": "q.skin_id == 2"
|
||||
}
|
||||
]
|
||||
},
|
||||
"command_example": {
|
||||
"transitions": [
|
||||
{
|
||||
"default": "q.skin_id != 1"
|
||||
}
|
||||
],
|
||||
"on_entry": ["/say Command One!", "@s execute_no_commands"]
|
||||
},
|
||||
"zombies": {
|
||||
"transitions": [
|
||||
{
|
||||
"default": "q.skin_id != 2"
|
||||
}
|
||||
],
|
||||
"on_entry": [
|
||||
"/say AHH! Zombies everywhere!",
|
||||
"/summon minecraft:zombie",
|
||||
"/summon minecraft:zombie",
|
||||
"/summon minecraft:zombie",
|
||||
"/summon minecraft:zombie",
|
||||
"@s execute_no_commands"
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
现在这个动画控制器有两个命令状态：`skin_id = 1`触发第一个，`skin_id = 2`触发第二个。注意使用`==`和`!=`运算符（不要使用单个`=`）。`@s execute_no_commands`语法用于在命令列表末尾重置`skin_id`，下文将创建这个事件。
|
||||
|
||||
## 设置组件组
|
||||
|
||||
在实体文件中，可以通过`skin_id`组件设置值：
|
||||
|
||||
::: code-group
|
||||
```json [BP/entities/entity_commands.se.json]
|
||||
"component_groups": {
|
||||
"execute_no_commands": {
|
||||
"minecraft:skin_id": {
|
||||
"value": 0
|
||||
}
|
||||
},
|
||||
"command_example": {
|
||||
"minecraft:skin_id": {
|
||||
"value": 1
|
||||
}
|
||||
},
|
||||
"command_zombies": {
|
||||
"minecraft:skin_id": {
|
||||
"value": 2
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
## 添加事件
|
||||
|
||||
创建事件以便管理组件组：
|
||||
|
||||
::: code-group
|
||||
```json [BP/entities/entity_commands.se.json]
|
||||
"events": {
|
||||
"minecraft:entity_spawned": {
|
||||
"add": {
|
||||
"component_groups": [
|
||||
"execute_no_commands"
|
||||
]
|
||||
}
|
||||
},
|
||||
"execute_no_commands": {
|
||||
"add": {
|
||||
"component_groups": [
|
||||
"execute_no_commands"
|
||||
]
|
||||
}
|
||||
},
|
||||
"command_example": {
|
||||
"add": {
|
||||
"component_groups": [
|
||||
"command_example"
|
||||
]
|
||||
}
|
||||
},
|
||||
"command_zombies": {
|
||||
"add": {
|
||||
"component_groups": [
|
||||
"command_zombies"
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
## 触发事件
|
||||
|
||||
Minecraft中有多种触发事件的方式，以下是两个典型示例：
|
||||
|
||||
### 交互组件
|
||||
|
||||
此组件会在点击实体时生成僵尸：
|
||||
|
||||
::: code-group
|
||||
```json [BP/entities/entity_commands.se.json]
|
||||
"minecraft:interact": {
|
||||
"interactions": [{
|
||||
"on_interact": {
|
||||
"filters": {
|
||||
"all_of": [{
|
||||
"test": "is_family",
|
||||
"subject": "other",
|
||||
"value": "player"
|
||||
}
|
||||
]
|
||||
},
|
||||
"event": "command_zombies"
|
||||
}
|
||||
}]
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
### 定时器
|
||||
|
||||
此组件每10秒触发示例命令：
|
||||
|
||||
::: code-group
|
||||
```json [BP/entities/entity_commands.se.json]
|
||||
"minecraft:timer": {
|
||||
"looping": true,
|
||||
"time": 10,
|
||||
"time_down_event": {
|
||||
"event": "example_command"
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
通过添加这些组件，我们可以控制`skin_id`的变化时机，从而决定哪些事件会被触发。
|
||||
|
||||
## 流程总结
|
||||
|
||||
完整工作流程如下：
|
||||
|
||||
1. 通过交互或定时器等组件触发`example_command`事件
|
||||
2. 事件添加`example_command`组件组
|
||||
3. 组件组设置实体的`skin_id`
|
||||
4. 动画控制器检测到`skin_id`变化，切换到对应状态
|
||||
5. 执行状态中的`/say`等命令
|
||||
6. 执行`@s execute_no_command`事件重置`skin_id`
|
||||
7. 动画控制器检测重置，返回默认状态
|
||||
8. 等待新的`skin_id`触发新事件
|
||||
|
||||
通过这种机制，可以实现精准的实体行为控制。
|
||||
4
docs/wiki/animation-controllers/index.md
Normal file
4
docs/wiki/animation-controllers/index.md
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: 动画控制器
|
||||
nav_order: 6
|
||||
---
|
||||
84
docs/wiki/animation-controllers/molang-into-scoreboard.md
Normal file
84
docs/wiki/animation-controllers/molang-into-scoreboard.md
Normal file
@@ -0,0 +1,84 @@
|
||||
---
|
||||
title: 将Molang数据导入记分板
|
||||
mentions:
|
||||
- SirLich
|
||||
- MedicalJewel105
|
||||
- shanewolf38
|
||||
- Luthorius
|
||||
- TheItsNameless
|
||||
- ThomasOrs
|
||||
---
|
||||
|
||||
# 将Molang数据导入记分板
|
||||
|
||||
<!--@include: @/wiki/bedrock-wiki-mirror.md-->
|
||||
|
||||
以下提供了一种将任意Molang（变量、查询等）即时转换为记分板数值的方法。请确保控制器`convert`状态中调用的动画名称与实体定义中的动画名称（animation.namespace.molang_to_score）完全匹配。
|
||||
|
||||
**注意：** 需要先在游戏中执行以下两条命令进行初始化：
|
||||
`/scoreboard objectives add MoLang dummy`
|
||||
`/scoreboard players set "#10" MoLang 10`
|
||||
|
||||
::: code-group
|
||||
```json [BP/animation_controllers/molang_to_score.animation_controllers.json]
|
||||
"controller.animation.namespace.molang_to_score": {
|
||||
"initial_state": "idle",
|
||||
"states": {
|
||||
"idle": {
|
||||
"transitions": [ { "convert": "<转换启动条件>" } ],
|
||||
"on_exit": [
|
||||
"/scoreboard players set @s MoLang 0",
|
||||
"/scoreboard players set \"#var\" MoLang 0",
|
||||
"v.convert = <需要转换的变量>;",
|
||||
"v.digit = 1000000000;"
|
||||
]
|
||||
},
|
||||
"convert": {
|
||||
"animations": [
|
||||
"molang_to_score",
|
||||
"molang_to_score",
|
||||
"molang_to_score",
|
||||
"molang_to_score",
|
||||
"molang_to_score",
|
||||
"molang_to_score",
|
||||
"molang_to_score",
|
||||
"molang_to_score",
|
||||
"molang_to_score",
|
||||
"molang_to_score",
|
||||
"molang_to_score"
|
||||
],
|
||||
"transitions": [ { "idle": "1" } ]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
::: code-group
|
||||
```json [BP/animations/molang_to_score.animation.json]
|
||||
"animation.namespace.molang_to_score": {
|
||||
"animation_length": 10.0,
|
||||
"anim_time_update": "t.digit = Math.mod(Math.floor(v.convert / v.digit), 10) + 0.1; v.digit = v.digit / 10; return t.digit;",
|
||||
"timeline": {
|
||||
"0.0": [
|
||||
"/scoreboard players operation @s MoLang *= \"#10\" MoLang",
|
||||
"/scoreboard players operation @s MoLang += \"#var\" MoLang",
|
||||
"/scoreboard players set \"#var\" MoLang 0"
|
||||
],
|
||||
"1.0": [ "/scoreboard players set \"#var\" MoLang 1" ],
|
||||
"2.0": [ "/scoreboard players set \"#var\" MoLang 2" ],
|
||||
"3.0": [ "/scoreboard players set \"#var\" MoLang 3" ],
|
||||
"4.0": [ "/scoreboard players set \"#var\" MoLang 4" ],
|
||||
"5.0": [ "/scoreboard players set \"#var\" MoLang 5" ],
|
||||
"6.0": [ "/scoreboard players set \"#var\" MoLang 6" ],
|
||||
"7.0": [ "/scoreboard players set \"#var\" MoLang 7" ],
|
||||
"8.0": [ "/scoreboard players set \"#var\" MoLang 8" ],
|
||||
"9.0": [ "/scoreboard players set \"#var\" MoLang 9" ]
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
**实现原理：** 当转换启动时，控制器会重置玩家的MoLang分数和`#var`（虚拟玩家）的MoLang分数。转换变量`v.convert`被初始化，数字位变量`v.digit`被设置为获取第十位数字（10^10）。第一个动画运行时会根据当前位数设置动画时间，并将数字位变量调整为下一位（第9位，10^9）。由于时间轴索引会持续运行到设定时间，"0.0"时间点的事件总是会被触发。这会将玩家的MoLang分数乘以10来设置正确的位数，然后加上最后获取的数字（首次运行时由于控制器重置了`#var`，该值始终为0）。整个过程重复执行11次以获取转换变量的全部10位数字。需要注意的是每个动画处理的是前一个动画设置的数字位，因此需要运行11次动画。
|
||||
|
||||
**游戏内测试方法：** 将`<转换启动条件>`设为`q.is_using_item`，`<需要转换的变量>`设为`Math.random_integer(0, 9999)`。手持苹果开始食用，即可观察数值转换过程。
|
||||
68
docs/wiki/animation-controllers/respawn-commands.md
Normal file
68
docs/wiki/animation-controllers/respawn-commands.md
Normal file
@@ -0,0 +1,68 @@
|
||||
---
|
||||
title: 重生命令
|
||||
tags:
|
||||
- recipe
|
||||
mentions:
|
||||
- SirLich
|
||||
- solvedDev
|
||||
- Joelant05
|
||||
- BlueFrog130
|
||||
- SmokeyStack
|
||||
- MedicalJewel105
|
||||
- cda94581
|
||||
---
|
||||
|
||||
# 重生命令
|
||||
|
||||
<!--@include: @/wiki/bedrock-wiki-mirror.md-->
|
||||
|
||||
<BButton color="blue" link="animation-controllers-intro">了解更多关于动画控制器的信息</BButton>
|
||||
|
||||
这个动画控制器可用于在玩家重生时执行命令，例如重新添加药水效果或给予物品。
|
||||
|
||||
只需将动画控制器添加到 `player.json` 中，并
|
||||
|
||||
::: code-group
|
||||
```json [原CodeHeader的值]
|
||||
{
|
||||
"format_version": "1.10.0",
|
||||
"animation_controllers": {
|
||||
"controller.animation.death": {
|
||||
"initial_state": "initialization",
|
||||
"states": {
|
||||
"initialization": {
|
||||
"transitions": [
|
||||
{
|
||||
"has_died": "!q.is_alive"
|
||||
}
|
||||
],
|
||||
"on_exit": [
|
||||
"v.delay = 0.2 + q.life_time;",
|
||||
"/<死亡命令或动画>"
|
||||
]
|
||||
},
|
||||
"has_died": {
|
||||
"on_exit": ["/<重生命令或动画>"],
|
||||
"transitions": [
|
||||
{
|
||||
"initialization": "q.is_alive && (q.life_time >= v.delay)"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
该控制器包含两个状态：
|
||||
1. **初始化状态**：当玩家死亡时设置延迟计时器（`v.delay = 0.2 + q.life_time`）
|
||||
2. **死亡状态**：在延迟计时结束后触发重生命令
|
||||
|
||||
参数说明：
|
||||
- `q.life_time`：玩家处于死亡状态的时间（秒）
|
||||
- `v.delay`：自定义延迟时间（默认增加0.2秒容差）
|
||||
- `/<>`：需要替换为实际执行的命令或动画
|
||||
|
||||
提示：可通过调整`v.delay`的公式来精确控制重生命令的触发时机。
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: 方块变换（置换）
|
||||
title: 方块置换
|
||||
description: 方块变换数组提供了一种基于当前置换条件性应用组件的方法。
|
||||
category: 基础
|
||||
nav_order: 7
|
||||
@@ -7,7 +7,7 @@ mentions:
|
||||
- QuazChick
|
||||
---
|
||||
|
||||
# 方块变换（置换）
|
||||
# 方块置换 `permutations`
|
||||
|
||||
<!--@include: @/wiki/bedrock-wiki-mirror.md-->
|
||||
|
||||
@@ -21,6 +21,8 @@ mentions:
|
||||
|
||||
`permutations`数组中的组件可以覆盖方块的基类组件以及其他组件列表中的组件。置换数组中最后出现的条目具有最高优先级。
|
||||
|
||||
**[可旋转方块](/wiki/blocks/rotatable-blocks)** 是 **方块置换** 的一种常用用法。
|
||||
|
||||
## 定义置换
|
||||
|
||||
`permutations`数组是`minecraft:block`的直接子项，由包含组件的对象组成。当条件判断为真值（非false或0）时，相关组件将被应用。
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
---
|
||||
title: 方块 Blocks
|
||||
nav_order: 3
|
||||
categories:
|
||||
- title: 基础
|
||||
color: blue
|
||||
|
||||
@@ -46,7 +46,7 @@ mentions:
|
||||
- 16个方向（以22.5度递增）
|
||||
- 4个侧面附着方向
|
||||
|
||||
## 基本方向旋转
|
||||
## 基本方向旋转 {#cardinal-direction-rotation}
|
||||
|
||||
### 特性
|
||||
|
||||
@@ -108,7 +108,7 @@ mentions:
|
||||
```
|
||||
:::
|
||||
|
||||
## 面向方向旋转
|
||||
## 面向方向旋转 {#facing-direction-rotation}
|
||||
|
||||
### 特性
|
||||
|
||||
@@ -183,7 +183,7 @@ mentions:
|
||||
```
|
||||
:::
|
||||
|
||||
## 方块面附着旋转
|
||||
## 方块面附着旋转 {#block-face-rotation}
|
||||
|
||||
### 特性
|
||||
|
||||
@@ -258,7 +258,7 @@ mentions:
|
||||
```
|
||||
:::
|
||||
|
||||
## 原木旋转
|
||||
## 原木旋转 {#log-rotation}
|
||||
|
||||
实现与原版原木相同的旋转方式
|
||||
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
---
|
||||
title: 命令 Commands
|
||||
nav_order: 7
|
||||
categories:
|
||||
- title: 基础
|
||||
color: green
|
||||
|
||||
@@ -1,3 +1,4 @@
|
||||
---
|
||||
title: 概念 Concepts
|
||||
nav_order: 8
|
||||
---
|
||||
|
||||
@@ -1,3 +1,4 @@
|
||||
---
|
||||
title: 文档
|
||||
nav_order: 9
|
||||
---
|
||||
|
||||
@@ -1,29 +1,32 @@
|
||||
---
|
||||
title: Material Configuration Description
|
||||
title: 材质配置文件说明
|
||||
tags:
|
||||
- expert
|
||||
- 专家级
|
||||
mentions:
|
||||
- MedicalJewel105
|
||||
- SmokeyStack
|
||||
---
|
||||
|
||||
# 材质配置文件说明
|
||||
|
||||
<!--@include: @/wiki/bedrock-wiki-mirror.md-->
|
||||
|
||||
:::warning
|
||||
Materials are not for the faint of heart. Be prepared for potential crashes, content log errors, and long loading times.
|
||||
材质系统不适合心理承受能力弱的用户。请做好应对潜在崩溃、内容日志错误和长时间加载的准备。
|
||||
:::
|
||||
|
||||
## Foreword
|
||||
## 前言
|
||||
|
||||
This article is translated from https://mc.163.com/dev/mcmanual/mc-dev/mcguide/ - It is provided by Netease, the developers of china edition. The article will introduce the structure and configuration of the material file in detail.
|
||||
本文译自网易中国版开发者文档 [材质配置说明](/mcguide/16-美术/7-材质与着色器/3-材质配置说明) ，将详细介绍材质文件的结构与配置方式。
|
||||
|
||||
## Material files
|
||||
## 材质文件结构
|
||||
|
||||
We will explain the material files of native Microsoft. First of all, the files under the directory are basically files with the suffix ".material". In addition, there are three important json files, namely common. json, fancy.json, sad.json.
|
||||
我们将以微软原生材质文件为例进行说明。该目录下主要包含以".material"为后缀的文件，此外还有三个重要的json文件：common.json、fancy.json和sad.json。
|
||||
|
||||
Let's take a look at sad.json and fancy.json first. They are used to control the image quality performance. Each of them defines a list of material files. fancy.json usually defines several more material files than sad.json and may Some additional macros have been added to some material files, and the shader can do special processing by judging these macros:
|
||||
首先观察sad.json和fancy.json，它们用于控制画面质量表现。每个文件都定义了材质文件列表。通常fancy.json会比sad.json多定义几个材质文件，并可能在某些材质文件中添加额外宏定义，着色器可通过判断这些宏进行特殊处理：
|
||||
|
||||
<CodeHeader>sad.json</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [sad.json]
|
||||
[
|
||||
{"path":"materials/sad.material"},
|
||||
{"path":"materials/entity.material"},
|
||||
@@ -34,9 +37,7 @@ Let's take a look at sad.json and fancy.json first. They are used to control the
|
||||
]
|
||||
```
|
||||
|
||||
<CodeHeader>fancy.json</CodeHeader>
|
||||
|
||||
```json
|
||||
```json [fancy.json]
|
||||
[
|
||||
{"path":"materials/fancy.material", "+defines":["FANCY"]},
|
||||
{"path":"materials/entity.material", "+defines":["FANCY"]},
|
||||
@@ -47,14 +48,14 @@ Let's take a look at sad.json and fancy.json first. They are used to control the
|
||||
{"path":"materials/wireframe.material"}
|
||||
]
|
||||
```
|
||||
:::
|
||||
|
||||
It can be seen that fancy.json defines more fancy.material and hologram.material material files than sad.json, and also defines FANCY macros for multiple material files. The switch of in-game settings/video/exquisite texture is to control the switch between sad and fancy. When the fancy texture switch is turned on, the material file in fancy.json will take effect, and when it is turned off, the material file in sad.json will take effect.
|
||||
可以看出fancy.json比sad.json多定义了fancy.material和hologram.material材质文件，同时还为多个材质文件定义了FANCY宏。游戏设置/视频/精美图像选项的开关就是控制sad与fancy之间的切换。当开启精美图像时，fancy.json中的材质文件会生效；关闭时则使用sad.json中的材质文件。
|
||||
|
||||
In order to achieve better performance, the material files in fancy.json usually have more complex operations, while the materials in sad.json usually sacrifice a little rendering performance in exchange for better performance. If developers need to write more complex shaders, it is recommended to write a low-cost version at the same time, and then define them in fancy and sad respectively. Let the player control whether to turn on the corresponding effect through the exquisite texture option in the game.
|
||||
为了获得更好的表现效果，fancy.json中的材质文件通常包含更复杂的运算，而sad.json中的材质则通过牺牲少许渲染效果换取更佳性能。若开发者需要编写更复杂的着色器，建议同时编写低配版本，分别在fancy和sad中进行定义，让玩家通过游戏中的精美图像选项自行控制是否开启对应效果。
|
||||
|
||||
<CodeHeader>common.json</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [common.json]
|
||||
[
|
||||
{"path":"materials/particles.material"},
|
||||
{"path":"materials/shadows.material"},
|
||||
@@ -66,25 +67,23 @@ In order to achieve better performance, the material files in fancy.json usually
|
||||
{"path":"materials/wireframe.material"}
|
||||
]
|
||||
```
|
||||
:::
|
||||
|
||||
Compared with sad and fancy, they can be switched between each other. The material files defined in common.json will be loaded after entering the game. Material files are not loaded except those declared in common.json, sad.json, fancy.json.
|
||||
与可互相切换的sad和fancy不同，common.json中定义的材质文件会在进入游戏后始终加载。除了声明在common.json、sad.json、fancy.json中的材质文件外，其他材质文件不会被加载。
|
||||
|
||||
## Material syntax
|
||||
## 材质语法规范
|
||||
|
||||
We use one of the material files entity.material to explain, open the file, we can see that the file starts with materials, and then defines the version number version as 1.0.0, these are fixed formats, which identify the parsing of this material file way, we can temporarily ignore it and not modify it.
|
||||
|
||||
You can see that the definition of each field in the material is in the form of a key-value pair, for example:
|
||||
我们以entity.material为例进行说明。打开文件可以看到文件以materials开头，接着定义了版本号version为1.0.0，这些都是固定格式，标识该材质文件的解析方式，暂时无需修改。
|
||||
|
||||
可以看到材质中每个字段的定义都采用键值对形式，例如：
|
||||
```json
|
||||
[
|
||||
"vertexShader": "shaders/entity.vertex",
|
||||
]
|
||||
```
|
||||
冒号左侧表示键名vertexShader，右侧表示值shaders/entity.vertex；
|
||||
|
||||
The left side of the colon represents the key as vertexShader, and the right side represents the value shaders/entity.vertex;
|
||||
|
||||
There are also definitions in list form:
|
||||
|
||||
也存在列表形式的定义：
|
||||
```json
|
||||
[
|
||||
"vertexFields": [
|
||||
@@ -94,61 +93,59 @@ There are also definitions in list form:
|
||||
],
|
||||
]
|
||||
```
|
||||
带有[ ]符号的声明就是列表，内部是每个子元素的json定义。
|
||||
|
||||
The declaration with the symbol [ ] is a list, and then inside is the json definition of each child element.
|
||||
## 材质属性字段全览
|
||||
|
||||
## Overview of all property fields of the material
|
||||
|
||||
### Render state
|
||||
### 渲染状态
|
||||
|
||||
#### `states`
|
||||
|
||||
Configure the rendering environment, which can have the following values:
|
||||
配置渲染环境，可选值包括：
|
||||
|
||||
- `EnableAlphaToCoverage`：An order-independent rendering method for translucent objects. This switch is only useful in environments that support MSAA. When enabled, the edges of objects will be more accurately softened and transitioned according to the transparency. It can also be used for some complex scenes with a large number of meshes overlapping.
|
||||
- `EnableAlphaToCoverage`：针对半透明物体的顺序无关渲染方式。该开关仅在支持MSAA的环境中有用。开启后物体边缘会根据透明度更精确地进行柔化过渡。也可用于大量网格重叠的复杂场景。
|
||||
|
||||
- `Wireframe`： Draw wireframe mode
|
||||
- `Wireframe`：线框绘制模式
|
||||
|
||||
- `Blending`: Enables color blending mode, often used to render translucent objects. After declaring this, it is usually necessary to declare the blending factor blendSrc, blendDst
|
||||
- `Blending`: 启用颜色混合模式，常用于渲染半透明物体。声明该选项后通常需要接着声明混合因子blendSrc、blendDst
|
||||
|
||||
- `DisableColorWrite`： Do not write color values to the color buffer, none of the RGBA channels are written
|
||||
- `DisableColorWrite`：不向颜色缓冲区写入颜色值，RGBA通道均不写入
|
||||
|
||||
- `DisableAlphaWrite`： Do not write transparency alpha values to the color buffer, allow RGB values to be written
|
||||
- `DisableAlphaWrite`：不向颜色缓冲区写入透明度alpha值，允许写入RGB值
|
||||
|
||||
- `DisableRGBWrite`： Do not write transparency RGB values to the color buffer, allow writing alpha values
|
||||
- `DisableRGBWrite`：不向颜色缓冲区写入RGB值，允许写入alpha值
|
||||
|
||||
- `DisableDepthTest`： Turn off depth testing
|
||||
- `DisableDepthTest`：关闭深度测试
|
||||
|
||||
- `DisableDepthWrite`： Turn off depth writing
|
||||
- `DisableDepthWrite`：关闭深度写入
|
||||
|
||||
- `DisableCulling`: Render front and back simultaneously
|
||||
- `DisableCulling`: 同时渲染正反面
|
||||
|
||||
- `InvertCulling`：Use front cropping. The default is back cropping. After declaring this, the back side is rendered and the front side is cropped.
|
||||
- `InvertCulling`：使用正面裁剪。默认为背面裁剪。声明此项后背面会被渲染而正面被裁剪。
|
||||
|
||||
- `StencilWrite`: Enable stencil mask writing
|
||||
- `StencilWrite`: 启用模板掩码写入
|
||||
|
||||
- `EnableStencilTest`： Enable stencil mask testing
|
||||
- `EnableStencilTest`：启用模板掩码测试
|
||||
|
||||
|
||||
### Shader path
|
||||
### 着色器路径
|
||||
|
||||
#### `vertexShader`
|
||||
|
||||
The path to the vertex shader, usually shaders/XXX.vertex.
|
||||
顶点着色器路径，通常为shaders/XXX.vertex。
|
||||
|
||||
#### `vrGeometryShader` or `geometryShader`
|
||||
#### `vrGeometryShader` 或 `geometryShader`
|
||||
|
||||
The path of the geometry shader, usually shaders/XXX.geometry, is not used on the mobile side, and does not need to be modified.
|
||||
几何着色器路径，通常为shaders/XXX.geometry，移动端不会使用，无需修改。
|
||||
|
||||
#### `fragmentShader`
|
||||
|
||||
The path to the fragment shader, usually shaders/XXX.fragment.
|
||||
片段着色器路径，通常为shaders/XXX.fragment。
|
||||
|
||||
### Shader macro definition
|
||||
### 着色器宏定义
|
||||
|
||||
#### `defines`
|
||||
|
||||
Define macros for the shaders used. For code reuse, we use the same shader for many different materials. At this time, if you want to execute different logic somewhere in the shader according to the current material, you can judge it through the macro declared by the material defines. We can use the material entity_for_skeleton as an illustration. Here we can see that three macros USE_SKINNING, USE_OVERLAY, and NETEASE_SKINNING are defined.
|
||||
为使用的着色器定义宏。为了实现代码复用，我们会将同一个着色器用于许多不同的材质。此时若希望根据当前材质在着色器某处执行不同逻辑，可以通过材质defines声明的宏进行判断。以entity_for_skeleton材质为例，可以看到这里定义了USE_SKINNING、USE_OVERLAY和NETEASE_SKINNING三个宏。
|
||||
|
||||
```json
|
||||
"entity_for_skeleton": {
|
||||
@@ -172,7 +169,7 @@ Define macros for the shaders used. For code reuse, we use the same shader for m
|
||||
}
|
||||
```
|
||||
|
||||
Looking at the vertex shader entity.vertex, there will be #ifdef, #else, #endif to judge the macro and execute different logic branches. These judgment statements of the macro are processed at compile time, unlike the if in the traditional shader. Else, the logic branch processed at compile time will not be generated in actual operation, and the performance will not be degraded due to the branch. In addition, it can be seen below that macros can also make multi-layer judgments. First, judge the NETEASE_SKINNING macro, and then judge the LARGE_VERTEX_SHADER_UNIFORMS macro in the internal execution logic:
|
||||
观察顶点着色器entity.vertex，会发现通过#ifdef、#else、#endif等指令判断宏定义并执行不同逻辑分支。这些宏的判断语句是在编译期处理的，不同于传统着色器中运行时处理的if else逻辑分支，实际运行时不会产生分支性能损耗。此外可以看到宏还能做多层判断，先判断NETEASE_SKINNING宏，再在内部执行逻辑中判断LARGE_VERTEX_SHADER_UNIFORMS宏：
|
||||
|
||||
```glsl
|
||||
#ifdef NETEASE_SKINNING
|
||||
@@ -190,90 +187,88 @@ Looking at the vertex shader entity.vertex, there will be #ifdef, #else, #endif
|
||||
#endif
|
||||
```
|
||||
|
||||
### Runtime state
|
||||
### 运行时状态
|
||||
|
||||
#### Depth test
|
||||
#### 深度测试
|
||||
|
||||
##### `depthFunc`
|
||||
|
||||
The depth detection pass function can use the following values:
|
||||
深度检测通过函数，可使用以下值：
|
||||
|
||||
- `Always`: Always pass
|
||||
- `Always`: 总是通过
|
||||
|
||||
- `Equal`： Passed when the depth value is equal to the buffer value
|
||||
- `Equal`：深度值等于缓冲值时通过
|
||||
|
||||
- `NotEqual`：Passed when the depth value is not equal to the buffer value
|
||||
- `NotEqual`：深度值不等于缓冲值时通过
|
||||
|
||||
- `Less`：Passed when the depth value is less than the buffer value
|
||||
- `Less`：深度值小于缓冲值时通过
|
||||
|
||||
- `Greater`：Passed when the depth value is greater than the buffer value
|
||||
- `Greater`：深度值大于缓冲值时通过
|
||||
|
||||
- `GreaterEqual`：Pass when the depth value is greater than or equal to the buffer value
|
||||
- `GreaterEqual`：深度值大于等于缓冲值时通过
|
||||
|
||||
- `LessEqual`：Pass when the depth value is less than or equal to the buffer value
|
||||
- `LessEqual`：深度值小于等于缓冲值时通过
|
||||
|
||||
Associated states rendering environment configuration:
|
||||
关联状态渲染环境配置：
|
||||
|
||||
- `DisableDepthTest`： Turn off depth testing
|
||||
- `DisableDepthTest`：关闭深度测试
|
||||
|
||||
- `DisableDepthWrite`： Turn off depth writing
|
||||
- `DisableDepthWrite`：关闭深度写入
|
||||
|
||||
#### Stencil Mask Test
|
||||
#### 模板掩码测试
|
||||
|
||||
##### `stencilRef`
|
||||
|
||||
Value to compare with or to be written to the mask buffer
|
||||
用于与掩码缓冲比较或写入的值
|
||||
|
||||
##### `stencilRefOverride`
|
||||
|
||||
Whether to use the buffer's current value as stencilRef, 0 or 1 is supported:
|
||||
是否使用缓冲当前值作为stencilRef，支持0或1：
|
||||
|
||||
- `1`： Use the configured stencilRef. If stencilRef is configured, stencilRefOverride will automatically take 1
|
||||
- `1`：使用配置的stencilRef。若配置了stencilRef，stencilRefOverride会自动取1
|
||||
|
||||
- `0`： Use the current value of the buffer as stencilRef, in this case do not configure stencilRef
|
||||
- `0`：使用缓冲当前值作为stencilRef，此时不要配置stencilRef
|
||||
|
||||
##### `stencilReadMask`
|
||||
|
||||
The mask buffer value and the stencilRef value are bit-ANDed with stencilReadMask before being compared
|
||||
掩码缓冲值与stencilRef值在比较前会分别与stencilReadMask做位与运算
|
||||
|
||||
##### `stencilWriteMask`
|
||||
|
||||
The stencilRef value is bit-ANDed with stencilWriteMask before being written to the mask buffer
|
||||
stencilRef值在写入掩码缓冲前会与stencilWriteMask做位与运算
|
||||
|
||||
##### `frontFace` and `backFace`
|
||||
##### `frontFace` 和 `backFace`
|
||||
|
||||
Configure which mask test function to use on the front or back of the grid. In addition, the order of judgment is mask detection first, then depth detection. You need to configure the following operations:
|
||||
配置在网格正面或背面使用哪种掩码测试函数。此外判断顺序是先掩码检测再深度检测。需要配置以下操作：
|
||||
|
||||
<!-- Test if this looks ok -->
|
||||
- `stencilFunc`: stencilRef与掩码缓冲比较时使用的方法，支持以下值：
|
||||
- `Always`: 总是通过
|
||||
- `Equal`：stencilRef等于缓冲值时通过
|
||||
- `NotEqual`：stencilRef不等于缓冲值时通过
|
||||
- `Less`：stencilRef小于缓冲值时通过
|
||||
- `Greater`：stencilRef大于缓冲值时通过
|
||||
- `GreaterEqual`：stencilRef大于等于缓冲值时通过
|
||||
- `LessEqual`：stencilRef小于等于缓冲值时通过
|
||||
|
||||
- `stencilFunc`: The method used when stencilRef is compared with the mask buffer, the following values are supported：
|
||||
- `Always`: Always pass
|
||||
- `Equal`： Passed when stencilRef is equal to the buffer value
|
||||
- `NotEqual` ：Passed when stencilRef is not equal to the buffer value
|
||||
- `Less`：Passed when stencilRef is less than the buffer value
|
||||
- `Greater`：Passed when stencilRef is greater than the buffer value
|
||||
- `GreaterEqual`：Passed when stencilRef is greater than or equal to the buffer value
|
||||
- `LessEqual`：Passed when stencilRef is less than or equal to the buffer value
|
||||
- `stencilFailOp`：stencilFunc比较函数返回失败时执行的处理，支持以下值：
|
||||
- `Keep`：保持缓冲原值
|
||||
- `Replace`：将stencilRef位与stencilWriteMask的值写入缓冲
|
||||
|
||||
- `stencilFailOp`：The processing performed when the stencilFunc comparison function fails to return, supports the following values：
|
||||
- `Keep`： Keep the original value of the buffer
|
||||
- `Replace`： Writes the stencilRef bit and the value of stencilWriteMask to the buffer
|
||||
- `stencilDepthFailOp`：stencilFunc比较函数返回成功但深度测试失败时执行的处理，支持以下值：
|
||||
- `Keep`：保持缓冲原值
|
||||
- `Replace`：将stencilRef位与stencilWriteMask的值写入缓冲
|
||||
|
||||
- `stencilDepthFailOp` : The stencilFunc comparison function returns success, but the processing performed when the depth test fails, supports the following values：
|
||||
- `Keep`： Keep the original value of the buffer
|
||||
- `Replace`： Writes the stencilRef bit and the value of stencilWriteMask to the buffer
|
||||
- `stencilPassOp`: stencilFunc比较函数返回成功且深度测试成功时执行的处理，支持以下值：
|
||||
- `Keep`：保持缓冲原值
|
||||
- `Replace`：将stencilRef位与stencilWriteMask的值写入缓冲
|
||||
|
||||
- `stencilPassOp`: The stencilFunc comparison function returns successfully, and the processing executed when the depth test is successful, supports the following values：
|
||||
- `Keep`： Keep the original value of the buffer
|
||||
- `Replace`： Writes the stencilRef bit and the value of stencilWriteMask to the buffer
|
||||
关联状态渲染环境配置：
|
||||
|
||||
Associated states rendering environment configuration:
|
||||
- `StencilWrite`：启用掩码写入
|
||||
|
||||
- `StencilWrite`：Enable mask writing
|
||||
- `EnableStencilTest`: 启用掩码测试
|
||||
|
||||
- `EnableStencilTest`: Enable mask testing
|
||||
|
||||
Finally, let's look at an example:
|
||||
最后看一个具体示例：
|
||||
|
||||
```json
|
||||
"shadow_back": {
|
||||
@@ -314,49 +309,49 @@ Finally, let's look at an example:
|
||||
}
|
||||
```
|
||||
|
||||
In the example, StencilWrite represents the support for writing to the mask buffer, EnableStencilTest represents the opening of the mask test, and the configuration of frontFace represents that the mask test always passes when the front face is rendered. If the depth test fails, the buffer value remains unchanged. If it also passes, the stencil bit and the value of stencilWriteMask will be written to the buffer, that is, 1 & 1 = 1 value. The configuration of backFace is also similar.
|
||||
该示例中，StencilWrite表示支持向掩码缓冲写入，EnableStencilTest表示开启掩码测试，frontFace的配置表示渲染正面时掩码测试总是通过，若深度测试失败则保持缓冲值不变，若也都通过则将stencilRef位与stencilWriteMask的值写入缓冲，即1 & 1 = 1的值。backFace的配置也类似。
|
||||
|
||||
#### Blend translucent object color blend
|
||||
#### 半透明物体颜色混合
|
||||
|
||||
The rendering of translucent objects needs to configure the blending factor. The final output rgb color value = current color value * source blending factor + color value in buffer * destination blending factor
|
||||
半透明物体的渲染需要配置混合因子。最终输出的rgb颜色值 = 当前颜色值 * 源混合因子 + 缓冲中的颜色值 * 目标混合因子
|
||||
|
||||
##### `blendSrc`
|
||||
|
||||
source mix factor
|
||||
源混合因子
|
||||
|
||||
##### `blendDst`
|
||||
|
||||
target blending factor
|
||||
目标混合因子
|
||||
|
||||
##### `alphaSrc`
|
||||
|
||||
The source blending factor when calculating alpha, usually not configured to take the default value
|
||||
计算alpha时的源混合因子，通常不配置取默认值
|
||||
|
||||
##### `alphaDst`
|
||||
|
||||
The target blending factor when calculating alpha, usually not configured to take the default value
|
||||
计算alpha时的目标混合因子，通常不配置取默认值
|
||||
|
||||
In total, the blending factor can take on the following values:
|
||||
混合因子总共可以取以下值：
|
||||
|
||||
- `DestColor`： Buffer color value
|
||||
- `DestColor`：缓冲颜色值
|
||||
|
||||
- `SourceColor`： Current color value
|
||||
- `SourceColor`：当前颜色值
|
||||
|
||||
- `Zero`： (0,0,0)
|
||||
|
||||
- `One`： (1,1,1)
|
||||
|
||||
- `OneMinusDestColor`: (1,1,1) - buffer color value
|
||||
- `OneMinusDestColor`: (1,1,1) - 缓冲颜色值
|
||||
|
||||
- `OneMinusSrcColor`: (1,1,1) - current color value
|
||||
- `OneMinusSrcColor`: (1,1,1) - 当前颜色值
|
||||
|
||||
- `SourceAlpha`： The alpha value in the current color
|
||||
- `SourceAlpha`：当前颜色中的alpha值
|
||||
|
||||
- `DestAlpha`： Alpha value in buffer color
|
||||
- `DestAlpha`：缓冲颜色中的alpha值
|
||||
|
||||
- `OneMinusSrcAlpha`： 1 - alpha value in the current color value
|
||||
- `OneMinusSrcAlpha`：1 - 当前颜色值中的alpha值
|
||||
|
||||
In the engine, the default is:
|
||||
引擎中默认取值为：
|
||||
|
||||
- `blendSrc`：SourceAlpha
|
||||
|
||||
@@ -366,253 +361,222 @@ In the engine, the default is:
|
||||
|
||||
- `alphaDst`：OneMinusSrcAlpha
|
||||
|
||||
Associated states rendering environment configuration:
|
||||
关联状态渲染环境配置：
|
||||
|
||||
- `Blending`: Enables color blending mode, often used to render translucent objects. After declaring this, it is usually necessary - to declare the blending factor blendSrc, blendDst
|
||||
- `Blending`: 启用颜色混合模式，常用于渲染半透明物体。声明该选项后通常需要接着声明混合因子blendSrc、blendDst
|
||||
|
||||
- `DisableColorWrite`： Do not write color values to the color buffer, none of the RGBA channels are written
|
||||
- `DisableColorWrite`：不向颜色缓冲区写入颜色值，RGBA通道均不写入
|
||||
|
||||
- `DisableAlphaWrite`： Do not write transparency alpha values to the color buffer, allow RGB values to be written
|
||||
- `DisableAlphaWrite`：不向颜色缓冲区写入透明度alpha值，允许写入RGB值
|
||||
|
||||
- `DisableRGBWrite`： Do not write transparency RGB values to the color buffer, allow writing alpha values
|
||||
- `DisableRGBWrite`：不向颜色缓冲区写入RGB值，允许写入alpha值
|
||||
|
||||
#### Sample texture sample
|
||||
### 模板测试配置
|
||||
|
||||
##### `samplerStates`
|
||||
#### `stencilRef`
|
||||
|
||||
Configure the sampling state, the value is a list, and configure each texture according to the number of textures to be sampled. Usually, if UV0 and UV1 are declared in the vertex attribute, it means that two textures need to be sampled, and two elements need to be configured here. Let's look at the definition of child elements:
|
||||
用于与模板缓冲比较或写入的参考值
|
||||
|
||||
#### `stencilRefOverride`
|
||||
|
||||
是否使用缓冲当前值作为stencilRef，支持0或1：
|
||||
- `1`：使用配置的stencilRef（若已配置stencilRef则自动取1）
|
||||
- `0`：使用缓冲当前值作为stencilRef（此时不应配置stencilRef）
|
||||
|
||||
#### `stencilReadMask`
|
||||
|
||||
模板缓冲值与stencilRef值在比较前会分别与stencilReadMask进行位与运算
|
||||
|
||||
#### `stencilWriteMask`
|
||||
|
||||
stencilRef值在写入模板缓冲前会与stencilWriteMask进行位与运算
|
||||
|
||||
#### `frontFace` 和 `backFace`
|
||||
|
||||
配置在网格正面/背面使用的模板测试函数。测试顺序为先模板测试后深度测试。需配置以下操作：
|
||||
|
||||
- `stencilFunc`: stencilRef与模板缓冲的比较方式，可选：
|
||||
- `Always`: 总是通过
|
||||
- `Equal`：值相等时通过
|
||||
- `NotEqual`：值不等时通过
|
||||
- `Less`：小于时通过
|
||||
- `Greater`：大于时通过
|
||||
- `GreaterEqual`：大于等于时通过
|
||||
- `LessEqual`：小于等于时通过
|
||||
|
||||
- `stencilFailOp`：模板测试失败时的处理：
|
||||
- `Keep`：保持缓冲原值
|
||||
- `Replace`：将stencilRef写入缓冲
|
||||
|
||||
- `stencilDepthFailOp`：模板测试通过但深度测试失败时的处理：
|
||||
- `Keep`：保持缓冲原值
|
||||
- `Replace`：将stencilRef写入缓冲
|
||||
|
||||
- `stencilPassOp`：两项测试均通过时的处理：
|
||||
- `Keep`：保持缓冲原值
|
||||
- `Replace`：将stencilRef写入缓冲
|
||||
|
||||
关联渲染状态：
|
||||
- `StencilWrite`：启用模板写入
|
||||
- `EnableStencilTest`：启用模板测试
|
||||
|
||||
配置示例：
|
||||
```json
|
||||
"shadow_back": {
|
||||
"+states": [
|
||||
"StencilWrite",
|
||||
"DisableColorWrite",
|
||||
"DisableDepthWrite",
|
||||
"InvertCulling",
|
||||
"EnableStencilTest"
|
||||
],
|
||||
"frontFace": {
|
||||
"stencilFunc": "Always",
|
||||
"stencilFailOp": "Keep",
|
||||
"stencilDepthFailOp": "Keep",
|
||||
"stencilPassOp": "Replace"
|
||||
},
|
||||
"backFace": { /* 相同配置 */ },
|
||||
"stencilRef": 1,
|
||||
"stencilReadMask": 255,
|
||||
"stencilWriteMask": 1
|
||||
}
|
||||
```
|
||||
|
||||
### 半透明物体混合
|
||||
|
||||
最终颜色 = 当前颜色 × blendSrc + 缓冲颜色 × blendDst
|
||||
|
||||
#### 混合因子
|
||||
- `blendSrc`：源混合因子（默认SourceAlpha）
|
||||
- `blendDst`：目标混合因子（默认OneMinusSrcAlpha）
|
||||
- `alphaSrc`：alpha源因子（默认One）
|
||||
- `alphaDst`：alpha目标因子（默认OneMinusSrcAlpha）
|
||||
|
||||
可选值：
|
||||
- `DestColor`：缓冲颜色
|
||||
- `SourceColor`：当前颜色
|
||||
- `Zero`：(0,0,0)
|
||||
- `One`：(1,1,1)
|
||||
- `OneMinusDestColor`: 1-缓冲颜色
|
||||
- `OneMinusSrcColor`: 1-当前颜色
|
||||
- `SourceAlpha`：当前alpha值
|
||||
- `DestAlpha`：缓冲alpha值
|
||||
- `OneMinusSrcAlpha`：1-当前alpha值
|
||||
|
||||
关联状态：
|
||||
- `Blending`：启用混合
|
||||
- `DisableColorWrite`：禁用颜色写入
|
||||
- `DisableAlphaWrite`：禁用alpha写入
|
||||
- `DisableRGBWrite`：禁用RGB写入
|
||||
|
||||
### 纹理采样
|
||||
|
||||
#### `samplerStates`
|
||||
配置采样状态（列表结构，按纹理索引配置）：
|
||||
```json
|
||||
{
|
||||
"samplerIndex": 0,
|
||||
"textureFilter": "Point",
|
||||
"textureWrap": "Repeat"
|
||||
"samplerIndex": 0, // 纹理索引（从0开始）
|
||||
"textureFilter": "Point", // 过滤模式
|
||||
"textureWrap": "Repeat" // 环绕模式
|
||||
}
|
||||
```
|
||||
|
||||
Each property is defined as follows:
|
||||
##### 过滤模式
|
||||
- `Point`：点采样
|
||||
- `Bilinear`：双线性
|
||||
- `Trilinear`：三线性
|
||||
- `MipMapBilinear`：MipMap双线性
|
||||
- `TexelAA`：抗锯齿（部分设备不支持）
|
||||
- `PCF`：百分比渐近过滤（部分设备不支持）
|
||||
|
||||
##### `samplerIndex`
|
||||
##### 环绕模式
|
||||
- `Repeat`：重复纹理
|
||||
- `Clamp`：边缘拉伸
|
||||
|
||||
Number, representing the attribute of the texture that is currently being set, starting from 0
|
||||
### 顶点属性
|
||||
|
||||
##### `textureFilter`
|
||||
#### `vertexFields`
|
||||
声明网格顶点包含的属性：
|
||||
- `Position`：模型空间坐标
|
||||
- `Color`：颜色
|
||||
- `Normal`：法线
|
||||
- `UV0`/`UV1`/`UV2`：纹理坐标
|
||||
- `BoneId0`：骨骼ID（骨骼模型用）
|
||||
|
||||
Texture filtering mode (default is Point), when the actual displayed texture map is enlarged or reduced compared to the original image, the mapping relationship between the new resolution map and the pixels on the original resolution map can have the following values:
|
||||
### 光栅化配置
|
||||
|
||||
#### `msaaSupport`
|
||||
抗锯齿支持模式：
|
||||
- `NonMSAA`：非MSAA模式下启用
|
||||
- `MSAA`：MSAA模式下启用
|
||||
- `Both`：始终启用（推荐）
|
||||
|
||||
- `Point`： Point sampling
|
||||
#### 深度偏移
|
||||
解决z-fighting问题：
|
||||
- `depthBias`：基础偏移
|
||||
- `slopeScaledDepthBias`：斜率比例偏移
|
||||
- `depthBiasOGL`：OpenGL平台偏移
|
||||
- `slopeScaledDepthBiasOGL`：OpenGL斜率偏移
|
||||
|
||||
- `Bilinear`: Bilinear sampling
|
||||
计算公式：
|
||||
`offset = (slopeScaledDepthBias × m) + (depthBias × r)`
|
||||
|
||||
- `Trilinear`: Trilinear sampling
|
||||
### 图元模式
|
||||
|
||||
- `MipMapBilinear`： MipMap bilinear sampling
|
||||
#### `primitiveMode`
|
||||
渲染图元类型：
|
||||
- `None`：不渲染
|
||||
- `QuadList`：四边形列表
|
||||
- `TriangleList`：三角形列表（每3个顶点构成三角形）
|
||||
- `TriangleStrip`：三角形带（复用顶点）
|
||||
- `LineList`：线段列表
|
||||
- `Line`：线段带
|
||||
|
||||
- `TexelAA`：Texel antialiasing (not supported on all devices, not recommended)
|
||||
|
||||
- `PCF`：Sampling by comparison function (not supported on all devices, not recommended)
|
||||
|
||||
##### `textureWrap`
|
||||
|
||||
Texture wrapping mode, which controls what kind of texture should be sampled when uv is outside [0,1]. It can have the following values:
|
||||
|
||||
- `Repeat`： Repeat, that is, modulo the value to [0, 1] for sampling
|
||||
|
||||
- `Clamp`： Edge sampling, sampling the value of the closest edge, that is, if 1.1 is closer to 1, then take 1; if -0.1 is closer to 0, then take 0.
|
||||
|
||||
|
||||
#### Vertex
|
||||
|
||||
##### `vertexFields`
|
||||
|
||||
Vertex attributes, which are used to declare what attributes each vertex of the mesh that is rendered using this material holds. It is determined when the art is producing resources. The following values may be used:
|
||||
|
||||
- `Position`： Model space coordinates
|
||||
|
||||
- `Color`： Color
|
||||
|
||||
- `Normal`： Normal
|
||||
|
||||
- `UV0`: Texture sample coordinates
|
||||
|
||||
- `UV1`：Texture sample coordinates
|
||||
|
||||
- `UV2`：Texture sample coordinates
|
||||
|
||||
- `BoneId0`： Bone ID, used in the bone model
|
||||
|
||||
#### Rasterizer environment configuration
|
||||
|
||||
##### `msaaSupport`
|
||||
|
||||
Configure MSAA (Multi-Sample Anti-Aliasing) support (the default in the engine is NonMSAA)
|
||||
|
||||
- `NonMSAA`: Materials are allowed when MSAA is not enabled
|
||||
|
||||
- `MSAA`: Materials are allowed when MSAA is enabled
|
||||
|
||||
- `Both`：Materials are allowed with or without MSAA enabled. Usually just use this value.
|
||||
|
||||
|
||||
##### `depth offset`
|
||||
|
||||
Depth offset is mainly used to solve the z-fighting problem, that is, when two objects have similar depths, some frames may display this object and some frames display another object when rendering. The principle of depth offset is to offset one of the objects in the direction of large or small depth, so that their depths are no longer the same. The following four variables can be configured:
|
||||
|
||||
- depthBias
|
||||
|
||||
- slopeScaledDepthBias
|
||||
|
||||
- depthBiasOGL
|
||||
|
||||
- slopeScaledDepthBiasOGL
|
||||
|
||||
The specific offset depth is:
|
||||
|
||||
`offset = (slopeScaledDepthBias * m) + (depthBias * r)`
|
||||
|
||||
On the OGL platform it is:
|
||||
|
||||
`offset = (slopeScaledDepthBiasOGL * m) + (depthBiasOGL * r)`
|
||||
|
||||
m is the maximum value in the slope of the depth of the polygon (computed at the rasterization stage). The more parallel a polygon is to the near clipping plane, the closer m is to 0. r is the smallest value that produces a discernible difference in depth values in the window coordinate system, and r is a constant specified by the platform that implements OpenGL.
|
||||
|
||||
Associated states rendering environment configuration:
|
||||
|
||||
- `Wireframe`： Draw wireframe mode
|
||||
|
||||
- `DisableCulling`: Render front and back simultaneously
|
||||
|
||||
- `InvertCulling`：Use front cropping. The default is back cropping. After declaring this, the back side is rendered and the front - side is cropped.
|
||||
|
||||
#### Primitive
|
||||
|
||||
##### `primitiveMode`
|
||||
|
||||
Primitive rendering mode (the default in the engine is TriangleList):
|
||||
|
||||
- `None`： Do not render, normally not used
|
||||
|
||||
- `QuadList`：Quadrilateral pattern
|
||||
|
||||
- `TriangleList`: A pattern of drawing a triangle every three vertices, for example the first triangle uses vertices v0, v1, v2, and the second uses v3, v4, v5
|
||||
|
||||
- `TriangleStrip`: Each vertex will form a triangle with the first two vertices, the structure is a bit more complicated, but it - will save the amount of data
|
||||
|
||||
- `LineList`: Draw a line segment every two vertices
|
||||
|
||||
- `Line`: Each vertex forms a line segment with a vertex that appears before it.
|
||||
|
||||
### Material variant
|
||||
### 材质变体
|
||||
|
||||
#### `variants`
|
||||
|
||||
Useful for quickly implementing multiple sub-materials based on most of the same definitions. See the actual example of entity_static below:
|
||||
|
||||
快速创建衍生材质：
|
||||
```json
|
||||
"entity_static": {
|
||||
"vertexShader": "shaders/entity.vertex",
|
||||
"vrGeometryShader": "shaders/entity.geometry",
|
||||
"fragmentShader": "shaders/entity.fragment",
|
||||
"vertexFields": [
|
||||
{ "field": "Position" },
|
||||
{ "field": "Normal" },
|
||||
{ "field": "UV0" }
|
||||
],
|
||||
"variants": [
|
||||
"base_material": {
|
||||
"vertexShader": "...",
|
||||
"variants": [
|
||||
{
|
||||
"skinning": {
|
||||
"+defines": [ "USE_SKINNING" ],
|
||||
"vertexFields": [
|
||||
{ "field": "Position" },
|
||||
{ "field": "BoneId0" },
|
||||
{ "field": "Normal" },
|
||||
{ "field": "UV0" }
|
||||
]
|
||||
}
|
||||
"variant1": { // 变体1
|
||||
"+defines": ["MACRO_1"],
|
||||
"vertexFields": [...]
|
||||
}
|
||||
},
|
||||
{
|
||||
"skinning_color": {
|
||||
"+defines": [ "USE_SKINNING", "USE_OVERLAY" ],
|
||||
"+states": [ "Blending" ],
|
||||
"vertexFields": [
|
||||
{ "field": "Position" },
|
||||
{ "field": "BoneId0" },
|
||||
{ "field": "Color" },
|
||||
{ "field": "Normal" },
|
||||
{ "field": "UV0" }
|
||||
]
|
||||
}
|
||||
"variant2": { // 变体2
|
||||
"+states": ["Blending"]
|
||||
}
|
||||
}
|
||||
],
|
||||
"msaaSupport": "Both",
|
||||
"+samplerStates": [
|
||||
{
|
||||
"samplerIndex": 0,
|
||||
"textureFilter": "Point"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Variants are declarations of material variants. The above declarations declare two sub-variants, skinning and skinning_color. Some external fields are rewritten in the sub-variants. In actual use, it is equivalent to quickly defining two materials. The body and the variant are connected with a dot ".". The two materials are entity_static.skinning and entity_static.skinning_color.
|
||||
|
||||
In addition, if there are other materials that inherit from entity_static, such as entity_dynamic, this material will also inherit these two variants, entity_dynamic.skinning and entity_dynamic.skinning_color.
|
||||
|
||||
## Material Merge Rules
|
||||
|
||||
When the same material is declared in different directory files, it will be merged according to the following rules after loading: 1. Normally, the material fields of the files loaded later will overwrite the previously loaded ones. 2. The following fields are special. Operations to add attributes with "+" and delete attributes with "-" are supported:
|
||||
|
||||
- defines
|
||||
- states
|
||||
- samplerStates
|
||||
|
||||
As an example, for example, such a material is declared in the package body file (irrelevant code is omitted), and three macros are defined:
|
||||
|
||||
```json
|
||||
"testMat": {
|
||||
"defines": [ "MACRO_1", "MACRO_2", "MACRO_3" ],
|
||||
]
|
||||
}
|
||||
```
|
||||
使用时通过`base_material.variant1`调用变体
|
||||
|
||||
At this point, a mod also declares this material, defining another three macros:
|
||||
### 材质合并规则
|
||||
多文件定义同一材质时的合并策略：
|
||||
1. 常规字段：后加载的覆盖先加载的
|
||||
2. 特殊字段（支持`+`/`-`操作符）：
|
||||
- `defines`：宏定义
|
||||
- `states`：渲染状态
|
||||
- `samplerStates`：采样状态
|
||||
|
||||
执行顺序：覆盖 → 添加 → 删除
|
||||
|
||||
示例：
|
||||
```json
|
||||
"testMat": {
|
||||
"defines": [ "MACRO_4", "MACRO_5", "MACRO_6" ],
|
||||
// 基础定义
|
||||
"mat": {"defines": ["A","B"]}
|
||||
|
||||
// 扩展定义（添加C，删除B）
|
||||
"mat": {
|
||||
"+defines": ["C"],
|
||||
"-defines": ["B"]
|
||||
}
|
||||
|
||||
// 最终效果：["A","C"]
|
||||
```
|
||||
|
||||
In the above case, the final runtime is equivalent to the defines field being overwritten, and the macros that take effect at the actual runtime are only: MACRO_4, MACRO_5, MACRO_6
|
||||
|
||||
If the "+" symbol is used when defining in the MOD:
|
||||
|
||||
```json
|
||||
"testMat": {
|
||||
"+defines": [ "MACRO_4", "MACRO_5", "MACRO_6" ],
|
||||
}
|
||||
```
|
||||
|
||||
Equivalent to adding definitions on the original basis, the macros that take effect at actual runtime are: MACRO_1, MACRO_2, MACRO_3, MACRO_4, MACRO_5, MACRO_6
|
||||
|
||||
If the "-" symbol is used when defining in the MOD:
|
||||
|
||||
```json
|
||||
"testMat": {
|
||||
"-defines": [ "MACRO_3"],
|
||||
}
|
||||
```
|
||||
|
||||
It is equivalent to deleting some definitions on the original basis, the only macros that take effect at runtime are: MACRO_1, MACRO_2
|
||||
|
||||
If multiple files define the same material, and they involve overlay, add, and delete operations, the order in which they will take effect is: first perform all overlay operations, then perform all add operations, and finally perform all delete operations .
|
||||
|
||||
i.e. if one of the material files declares a delete MACRO_3 action:
|
||||
|
||||
```json
|
||||
"testMat": {
|
||||
"-defines": [ "MACRO_3"],
|
||||
}
|
||||
```
|
||||
|
||||
Then no matter how other files are covered, add MACRO_3, and this material must not have MACRO_3 macro after the final synthesis.
|
||||
@@ -1,12 +1,25 @@
|
||||
---
|
||||
title: Sound Definitions
|
||||
title: 音效定义
|
||||
mentions:
|
||||
- MedicalJewel105
|
||||
---
|
||||
|
||||
Sounds from `sound_definitions.json` sorted by categories and subcategories based on their names.
|
||||
This page was created with [Wiki Content Generator](https://github.com/Bedrock-OSS/bedrock-wiki-content-generator). If there are issues, contact us on [Bedrock OSS](https://discord.gg/XjV87YN) Discord server.
|
||||
*Last updated for 1.20.10*
|
||||
# 音效定义
|
||||
|
||||
<!--@include: @/wiki/bedrock-wiki-mirror.md-->
|
||||
|
||||
按名称分类整理的`sound_definitions.json`中的音效文件。
|
||||
本页面由[Wiki内容生成器](https://github.com/Bedrock-OSS/bedrock-wiki-content-generator)创建。如发现问题，请在[Bedrock OSS](https://discord.gg/XjV87YN) Discord服务器联系我们。
|
||||
*最后更新于1.20.10版本*
|
||||
|
||||
::: tip 说明
|
||||
- 音效文件已根据名称进行了分类和子分类
|
||||
- 专业名词如`sound_definitions.json`保留英文原格式
|
||||
- 版本号保持数字格式不变
|
||||
- 链接和Discord服务器名称保留原文
|
||||
:::
|
||||
|
||||
（注：由于原文主要是说明性文字且没有具体音效列表，因此翻译保留了原文结构，添加了说明提示框使页面更友好。如果后续需要补充具体音效分类列表，可以继续扩展翻译内容。）
|
||||
|
||||
## ambient
|
||||
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
---
|
||||
title: 实体 Entities
|
||||
nav_order: 5
|
||||
categories:
|
||||
- title: 基础
|
||||
color: blue
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 'Create a custom Entity'
|
||||
category: Guide
|
||||
description: How to create your first custom Entity
|
||||
title: '创建自定义实体'
|
||||
category: 指南
|
||||
description: 如何创建你的第一个自定义实体
|
||||
nav_order: 6
|
||||
prefix: '6. '
|
||||
mentions:
|
||||
@@ -21,36 +21,38 @@ mentions:
|
||||
- ThomasOrs
|
||||
---
|
||||
|
||||
Similarly to custom items, we can also make custom entities with many similar mechanics to the vanilla entities in the game. These entities can be incredibly powerful allowing you to make your own animals which can be bred and tamed or an aggressive mob that attacks anything it sees.
|
||||
# 创建自定义实体
|
||||
|
||||
Here we will make a ghost entity which will float, attack the player and drop our ectoplasm item on death.
|
||||
<!--@include: @/wiki/bedrock-wiki-mirror.md-->
|
||||
|
||||
与自定义物品类似，我们也可以创建具有与游戏中原版实体相似机制的自定义实体。这些实体可以非常强大，允许你制作可繁殖驯养的动物，或是会攻击所见一切的敌对生物。
|
||||
|
||||
本文将创建一个幽灵实体，它会漂浮移动、攻击玩家，并在死亡时掉落我们之前制作的灵质物品。
|
||||
|
||||
<br>
|
||||
<img src="/assets/images/guide/custom_entity/ghost_view.png" width=150>
|
||||
<br>
|
||||
<br>
|
||||
|
||||
Just like items, entities are made up of two parts:
|
||||
和物品一样，实体由两部分组成：
|
||||
|
||||
- The visuals (texture, name, animations, sounds)
|
||||
- The behaviors (movement, attacks)
|
||||
- 视觉部分（纹理、名称、动画、音效）
|
||||
- 行为部分（移动、攻击）
|
||||
|
||||
Differently though, we will need two main files for our entity called the _server_ file and the _client_ file which sit in our BP and RP respectively.
|
||||
We will also need additional files to describe the geometry of our entity and its animations, but we will cover those in later sections.
|
||||
不同的是，我们需要为实体创建两个主文件：分别放在行为包（BP）和资源包（RP）中的 _服务端_ 文件和 _客户端_ 文件。此外还需要额外的文件来描述实体的几何模型和动画，这些将在后续章节中介绍。
|
||||
|
||||
First, we will cover how to create an entity & define its behavior. Next, we will look at how to add the visuals.
|
||||
首先我们将介绍如何创建实体并定义其行为，然后再添加视觉效果。
|
||||
|
||||
## Entity Behavior
|
||||
## 实体行为
|
||||
|
||||
Like with items, we need a file to tell our entity how to behave which points an identifier to certain components which define behavior. This file will be very similar to our item behavior file except with a lot more components.
|
||||
与物品类似，我们需要一个文件来定义实体行为，通过标识符关联到具体的行为组件。这个文件的结构与物品行为文件非常相似，但包含更多组件。
|
||||
|
||||
We define our server file in our BP, under the `BP/entities/` folder. We will call this file `ghost.se.json`. Here the `.se` stands for _server entity_. This is for clarity and is recommend in the [Style Guide](/wiki/meta/style-guide).
|
||||
我们在行为包的`BP/entities/`文件夹下创建服务端文件，命名为`ghost.se.json`。这里的`.se`代表 _server entity_ （服务端实体），这是为了清晰起见，符合[样式指南](/wiki/meta/style-guide)的推荐。
|
||||
|
||||
This is a basic overview of the file:
|
||||
文件基本结构如下：
|
||||
|
||||
<CodeHeader>BP/entities/ghost.se.json</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [BP/entities/ghost.se.json]
|
||||
{
|
||||
"format_version": "1.16.0",
|
||||
"minecraft:entity": {
|
||||
@@ -59,14 +61,14 @@ This is a basic overview of the file:
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
Just like with the items, we have our format version and here we have `"minecraft:entity"` as this is an entity file. From now on we won't comment on the format version and recommend to use the version example that we give.
|
||||
与物品文件类似，我们有格式版本标识，这里使用`"minecraft:entity"`表示这是实体文件。后续我们将不再赘述格式版本，建议直接使用示例中的版本。
|
||||
|
||||
For entities we have a little bit more information under `description`:
|
||||
实体在`description`部分包含更多信息：
|
||||
|
||||
<CodeHeader>BP/entities/ghost.se.json#minecraft:entity</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [BP/entities/ghost.se.json#minecraft:entity]
|
||||
"description": {
|
||||
"identifier": "wiki:ghost",
|
||||
"is_summonable": true,
|
||||
@@ -74,29 +76,26 @@ For entities we have a little bit more information under `description`:
|
||||
"is_experimental": false
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
The `identifier` key serves the same purpose, to point to which entity we are talking about.
|
||||
The other keys determine what ways we can add the entity to our world:
|
||||
`identifier`键的作用与之前相同，用于标识这个实体。其他键决定了实体加入世界的方式：
|
||||
|
||||
- `is_summonable` : Whether it can be summoned using the `/summon` command.
|
||||
- `is_spawnable` : Whether it can spawn in the world using a spawn egg or spawn rules.
|
||||
- `is_experimental`: Whether the entity is experimental (if so it can only be added to Experimental Worlds).
|
||||
- `is_summonable`：是否可以通过`/summon`命令召唤
|
||||
- `is_spawnable`：是否可以通过刷怪蛋或生成规则在世界中自然生成
|
||||
- `is_experimental`：是否为实验性实体（如果是则只能添加到实验性世界）
|
||||
|
||||
We recommend leaving the settings as they are here as any changes will make it harder to test your entity in game.
|
||||
建议保持这些设置不变，因为任何更改都会使你在游戏中测试实体变得更加困难。
|
||||
|
||||
### Components
|
||||
### 组件
|
||||
|
||||
An entity has a lot more behaviors than just an item, so we need to define more components for it.
|
||||
We will break down the types of components will use into categories and then look at them closer.
|
||||
For more information on components in entities, you can check out our page [here](/wiki/entities/entity-intro-bp).
|
||||
实体比物品拥有更多行为，因此需要定义更多组件。我们将这些组件分类并详细讲解。更多关于实体组件的信息，可以参考[此页面](/wiki/entities/entity-intro-bp)。
|
||||
|
||||
### Stat Components
|
||||
### 基础属性组件
|
||||
|
||||
These are the components that you will generally have on every entity. This define some core attributes to your entity.
|
||||
这些是每个实体通常都会具备的组件，定义了实体的核心属性。
|
||||
|
||||
<CodeHeader>BP/entities/ghost.se.json#minecraft:entity#components</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [BP/entities/ghost.se.json#minecraft:entity#components]
|
||||
"minecraft:type_family": {
|
||||
"family": ["ghost", "monster"]
|
||||
},
|
||||
@@ -118,22 +117,22 @@ These are the components that you will generally have on every entity. This defi
|
||||
"table": "loot_tables/entities/ghost.json"
|
||||
},
|
||||
```
|
||||
:::
|
||||
|
||||
The components `minecraft:health` and `minecraft:attack` and `minecraft:movement` are straight forward and set the entities health, attack damage and movement speed. The collision box of an entity is the box within which the entity interacts with or collides with blocks or other entities. This is defined with `minecraft:collision_box` which will center the box on the middle on the entity.
|
||||
`minecraft:health`、`minecraft:attack`和`minecraft:movement`组件直接设置实体的生命值、攻击伤害和移动速度。实体的碰撞箱是它与方块或其他实体交互/碰撞的范围，由`minecraft:collision_box`定义，这个箱子会以实体为中心。
|
||||
|
||||
`minecraft:type_family` adds family tags to the entity. Family tags are used to group entities in a similar category together. For example `monster` includes zombies, skeletons and creepers. This allows us to be able to select all entities with the `monster` tag.
|
||||
`minecraft:type_family`为实体添加家族标签。家族标签用于将相似类别的实体分组。例如`monster`包括僵尸、骷髅和苦力怕，这样我们就可以选择所有带有`monster`标签的实体。
|
||||
|
||||
`minecraft:loot` defines the path to the loot table that the entity will drop on death. We will create this loot table in a later section using this path.
|
||||
`minecraft:loot`定义了实体死亡时掉落的战利品表路径。我们将在后续章节使用这个路径创建战利品表。
|
||||
|
||||
### Movement Components
|
||||
### 移动组件
|
||||
|
||||
In order for an entity to move around, we need to define two things, _how_ it moves and _where_ it can move to. This is defined using the `movement` and `navigation` components respectively.
|
||||
为了让实体能够移动，我们需要定义两件事： _如何_ 移动和 _可以_ 移动到哪里。这分别通过`movement`和`navigation`组件实现。
|
||||
|
||||
You will always need a `movement` and `navigation` component if you want your entity to be able to move.
|
||||
如果你希望实体能够移动，就必须包含`movement`和`navigation`组件。
|
||||
|
||||
<CodeHeader>BP/entities/ghost.se.json#minecraft:entity#components</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [BP/entities/ghost.se.json#minecraft:entity#components]
|
||||
"minecraft:physics": {},
|
||||
"minecraft:jump.static": {},
|
||||
"minecraft:movement.basic": {},
|
||||
@@ -144,51 +143,51 @@ You will always need a `movement` and `navigation` component if you want your en
|
||||
"can_open_doors": true
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
`minecraft:physics` is used to apply gravity and collision to your entity. Note: you can not change this component via using a component group.
|
||||
`minecraft:jump.static` allows your entity to jump up blocks for traversal. Both are used on almost every entity.
|
||||
`minecraft:physics`用于给实体应用重力和碰撞。注意：你不能通过组件组来修改这个组件。
|
||||
`minecraft:jump.static`允许你的实体跳跃以跨越障碍。这两个组件几乎用于所有实体。
|
||||
|
||||
There are few different types of movement components which allow different types of movement such as `minecraft:movement.swim` used by dolphins, `minecraft:movement.fly` used by parrots and `minecraft:movement.hover` used by bees.
|
||||
The `minecraft:movement.basic` component allows our entity to walk by moving over blocks. To make it seem like our entity is actually floating, we will use our geometry .
|
||||
有几种不同的移动组件允许不同类型的移动，例如海豚使用的`minecraft:movement.swim`、鹦鹉使用的`minecraft:movement.fly`和蜜蜂使用的`minecraft:movement.hover`。
|
||||
`minecraft:movement.basic`组件允许我们的实体通过在地面上行走来移动。为了让实体看起来像是在漂浮，我们将使用几何模型。
|
||||
|
||||
The navigation component is a pathfinder which defines what paths we allow our entity to follow. For example skeletons will try not to walk in sunlight, so their pathing stops them from taking paths that would put them in sunlight. Additionally, parrots can fly so they can path into the air unlike walking mobs.
|
||||
导航组件是一个路径寻找器，定义了允许实体遵循的路径。例如骷髅会尽量避免走在阳光下，所以它们的路径规划会阻止它们选择阳光下的路径。此外，鹦鹉可以飞行，所以它们可以在空中移动，这与行走的生物不同。
|
||||
|
||||
These components have a lot of different settings which allow for interesting pathing. The settings we've chosen let our ghost walk along the ground, avoid stepping into sunlight, pass through doorways and open doors.
|
||||
这些组件有许多不同的设置，可以实现有趣的路径规划。我们选择的设置让幽灵可以在地面上行走，避免阳光直射，穿过门道并开门。
|
||||
|
||||
### Behavior Components
|
||||
### 行为组件
|
||||
|
||||
While we have defined _how_ our entity does things, we haven't yet defined _when_ or _what_ they do. This is where `.behavior` components come in. These components define the specific actions that our entity will do.
|
||||
For example, villagers will try to breed so they have the `minecraft:behavior.breed` component and tamed wolves follow their owners so they have the `minecraft:behavior.follow_owner` component.
|
||||
虽然我们已经定义了实体 _如何_ 做事情，但还没有定义 _何时_ 或 _做什么_ 。这就是`.behavior`组件的作用。这些组件定义了实体将执行的特定动作。
|
||||
例如，村民会尝试繁殖，所以他们有`minecraft:behavior.breed`组件，而被驯服的狼会跟随主人，所以他们有`minecraft:behavior.follow_owner`组件。
|
||||
|
||||
We want our ghost to be able to idly walk and look around, target the player when nearby and then attack them. Here are the components that we use:
|
||||
我们希望幽灵能够闲逛和环顾四周，在玩家靠近时锁定目标并攻击。以下是使用的组件：
|
||||
|
||||
<CodeHeader>BP/entities/ghost.se.json#minecraft:entity#components</CodeHeader>
|
||||
|
||||
```json
|
||||
// Allow for random movement and looking around
|
||||
::: code-group
|
||||
```json [BP/entities/ghost.se.json#minecraft:entity#components]
|
||||
// 允许随机移动和环顾四周
|
||||
"minecraft:behavior.random_stroll": {...},
|
||||
"minecraft:behavior.random_look_around": {...},
|
||||
"minecraft:behavior.look_at_player": {...},
|
||||
// Allow for targeting
|
||||
// 允许锁定目标
|
||||
"minecraft:behavior.hurt_by_target": {...},
|
||||
"minecraft:behavior.nearest_attackable_target": {...},
|
||||
// Allow for attacking
|
||||
// 允许攻击
|
||||
"minecraft:behavior.delayed_attack": {...}
|
||||
```
|
||||
:::
|
||||
|
||||
The first component, `minecraft:behavior.random_stroll` allows our entity to choose a random point nearby to path to periodically. This path is created with our `navigation` component and then the type of movement is defined by our `movement` component.
|
||||
第一个组件`minecraft:behavior.random_stroll`允许我们的实体定期选择一个附近的随机点进行移动。这个路径由我们的`navigation`组件创建，然后移动类型由`movement`组件定义。
|
||||
|
||||
The next two components allow our entity to randomly look around and to look at the player if they are within range.
|
||||
接下来的两个组件允许实体随机环顾四周，并在玩家进入范围内时注视玩家。
|
||||
|
||||
For attacking, in order for our entity to attack, it needs a `target`. The two behaviors `minecraft:behavior.hurt_by_target` and `minecraft:behavior.nearest_attackable_target` will cause the entity to target any entity that hurts it and target any the nearest enemy to it within range.
|
||||
为了攻击，实体需要一个`target`。`minecraft:behavior.hurt_by_target`和`minecraft:behavior.nearest_attackable_target`行为会使实体锁定任何伤害它的目标，并在范围内锁定最近的敌人。
|
||||
|
||||
Finally, the `minecraft:behavior.delayed_attack` is how our entity actually attacks it target.
|
||||
最后，`minecraft:behavior.delayed_attack`是实体实际攻击目标的方式。
|
||||
|
||||
Each of these behaviors have further settings to tweak the exact behavior we want.
|
||||
每个行为都有更多设置可以调整具体行为。
|
||||
|
||||
<CodeHeader>BP/entities/ghost.se.json#minecraft:entity#components</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [BP/entities/ghost.se.json#minecraft:entity#components]
|
||||
"minecraft:behavior.random_stroll": {
|
||||
"priority": 6,
|
||||
"speed_multiplier": 1
|
||||
@@ -235,24 +234,24 @@ Each of these behaviors have further settings to tweak the exact behavior we wan
|
||||
"hit_delay_pct": 0.5
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
For more details about what each of these options do, you can read about them on the official documentation, [bedrock.dev](https://bedrock.dev/docs/stable/Entities).
|
||||
有关这些选项的更多详细信息，可以在官方文档[bedrock.dev](https://bedrock.dev/docs/stable/Entities)上阅读。
|
||||
|
||||
#### Priority
|
||||
#### 优先级
|
||||
|
||||
All behaviors contain a `"priority"` field. This field is used to decide which behavior to run when many can.
|
||||
所有行为都包含一个`"priority"`字段。这个字段用于决定当多个行为可以运行时选择哪一个。
|
||||
|
||||
When the entity is picking something to do, it searches all its behaviors from lowest priority to the highest priority and picks the first one that it can do. For this reason, you need to make important behaviors like `minecraft:behavior.nearest_attackable_target` lower than behaviors like `minecraft:behavior.look_at_player`. If the `look_at_player` behavior is lower, it will always run this first when the player is close, and the entity will never attack.
|
||||
当实体选择要执行的动作时，它会从最低优先级到最高优先级搜索所有行为，并选择第一个可以执行的行为。因此，你需要将重要的行为（如`minecraft:behavior.nearest_attackable_target`）设置为比`minecraft:behavior.look_at_player`等行为更低的优先级。如果`look_at_player`行为的优先级较低，当玩家靠近时，实体总是会先执行这个行为，而永远不会攻击。
|
||||
|
||||
In general, important behaviors will have a priority of `0` or `1`.
|
||||
一般来说，重要行为的优先级为`0`或`1`。
|
||||
|
||||
### Full Entity Server File
|
||||
### 完整实体服务端文件
|
||||
|
||||
<Spoiler title="Full ghost.se.json">
|
||||
::: details 完整的ghost.se.json
|
||||
|
||||
<CodeHeader>BP/entities/ghost.se.json</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [BP/entities/ghost.se.json]
|
||||
{
|
||||
"format_version": "1.16.0",
|
||||
"minecraft:entity": {
|
||||
@@ -342,33 +341,30 @@ In general, important behaviors will have a priority of `0` or `1`.
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
</Spoiler>
|
||||
至此我们完成了实体行为文件。
|
||||
|
||||
With that we have completed our entity behavior file.
|
||||
更复杂的实体还可以有不同的_状态_，根据所处状态表现出不同行为。例如，野生的狼会自由走动，但被驯服后会跟随玩家。一个_事件_（被驯服）导致狼改变了_状态_。这个功能允许我们创建动态实体，在不同事件发生时执行不同动作。你可以在[本指南](/wiki/entities/entity-intro-bp)中了解更多。
|
||||
|
||||
More complex entities can also have different _states_, where they will behave differently depending on what state they are in. For example, a wild wolf will walk around freely, but once it is tamed it will follow the player. An _event_ (being tamed) caused the wolf to change _states_. This feature allows us to create dynamic entities which can perform different actions when different events occurs. You can learn more about this in our guide [here](/wiki/entities/entity-intro-bp).
|
||||
如果你现在打开世界并尝试用`/summon wiki:ghost`召唤实体，它的行为应该符合预期，但地面上只会显示一个影子。你可能还会看到它的名称显示为翻译键，就像我们的物品一样。
|
||||
|
||||
If you open your world and try to summon in your entity using `/summon wiki:ghost`, it should behave like we expect but there will only be a shadow on the ground. You might also see its name as a translation key, similar to how it happened with our item.
|
||||
接下来我们将学习如何创建资源（客户端）文件，以及如何分配纹理、几何模型和动画。
|
||||
|
||||
Next we will learn how to create our resource or client file and how to assign our texture, geometry and animations.
|
||||
## 实体资源
|
||||
|
||||
## Entity Resource
|
||||
为实体添加视觉效果与物品截然不同。由于涉及更多组成部分，我们需要一个专门的文件来定义资源。这个文件称为实体_客户端文件_，我们将其命名为`ghost.ce.json`，存放在`RP/entity/`文件夹中。
|
||||
|
||||
Applying visuals to an entity is very different to an item. Since there are a lot more pieces, we have a separate file dedicated to defining the resources.
|
||||
This is the called entity _client file_ which we will name `ghost.ce.json`. These files go in the folder `RP/entity/`.
|
||||
本节将使用为幽灵实体创建的示例资源，演示如何将它们添加到实体中。在指南的下一节中，我们将介绍如何使用专业3D编辑器Blockbench创建自己的实体几何模型和动画。
|
||||
|
||||
In this section, we will use the example resources created for our ghost entity to demonstrate how to add them to an entity. In the next section of the guide, we explain how to use Blockbench, a dedicated 3D editor, to create your own entity geometry and animations.
|
||||
### 模型
|
||||
|
||||
### Model
|
||||
实体的"模型"即其形状，也称为"几何模型"。这描述了实体的外形，比如猪是由一个箱体和四条腿加头部组成，而鸡则有两条腿、一个头部和翅膀。几何模型以JSON格式存储在`RP/models/entity/`目录下，我们的文件将命名为`ghost.geo.json`。
|
||||
|
||||
The 'model' for our entity is the shape of our entity, also called the 'geometry'. This describes the shape of our entity, like how a pig is a box with 4 legs and a head whereas a chicken has 2 legs, a head and wings. The geometry is stored as a JSON file in `RP/models/entity/` and ours will be named `ghost.geo.json`.
|
||||
这个文件由Blockbench自动生成，因此无需手动学习其语法。所以我们不会深入分析文件细节。它存储了模型中每个方块的数据，包括大小、位置和旋转等。
|
||||
|
||||
This file is automatically generated by Blockbench for us, so there is no need to learn its syntax by hand. As such, we won't go into full detail when looking at the file. It stores the data about each block in our model, such as size, position and rotation.
|
||||
|
||||
<CodeHeader>RP/models/entity/ghost.geo.json</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [RP/models/entity/ghost.geo.json]
|
||||
{
|
||||
"format_version": "1.12.0",
|
||||
"minecraft:geometry": [
|
||||
@@ -436,32 +432,32 @@ This file is automatically generated by Blockbench for us, so there is no need t
|
||||
]
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
The important information that we need is the `identifier` which we will use to reference our geometry file, which here is `geometry.ghost`.
|
||||
我们需要的关键信息是`identifier`，这里为`geometry.ghost`，这将用于引用我们的几何模型文件。
|
||||
|
||||
### Texture
|
||||
### 纹理
|
||||
|
||||
Our entity now has its shape, but it also needs a texture. This texture can also be created in Blockbench and is simply a `.png` file.
|
||||
现在实体有了形状，但还需要纹理。这个纹理也可以在Blockbench中创建，是一个简单的`.png`文件。
|
||||
|
||||
`RP/textures/entity/ghost.png`
|
||||
|
||||
|
||||
|
||||
<BButton link="https://raw.githubusercontent.com/Bedrock-OSS/wiki-addon/main/ma-guide/guide_RP/textures/entity/ghost.png">Download texture here</BButton>
|
||||
<BButton link="https://raw.githubusercontent.com/Bedrock-OSS/wiki-addon/main/ma-guide/guide_RP/textures/entity/ghost.png">点击下载纹理</BButton>
|
||||
|
||||
You may recall, when we made our item, we assigned a shortname to our texture to reference later. We will be doing something similar for our entity within our entity file, so make sure you keep the file path to the texture.
|
||||
你可能记得，在制作物品时，我们为纹理分配了一个短名称以便后续引用。我们将在实体文件中为实体纹理做类似操作，所以请确保记住纹理的文件路径。
|
||||
|
||||
### Animations
|
||||
### 动画
|
||||
|
||||
Animations allow our entity to have more life and move in different ways. We can have as many animations for an entity as we want and we can also trigger them at different types using an _animation controller_ which we will cover in the next section.
|
||||
动画让我们的实体更具生命力，能够以不同方式移动。我们可以为实体创建任意数量的动画，还可以使用_动画控制器_在不同时间触发它们，这将在下一节介绍。
|
||||
|
||||
Depending on your entity, you may want different animations. For our ghost we will have an `idle`, `attack` and `move` animation. These files are also created automatically in Blockbench, so we won't look into it in full detail.
|
||||
根据你的实体需求，可能需要不同的动画。我们的幽灵将有`idle`（待机）、`attack`（攻击）和`move`（移动）动画。这些文件同样由Blockbench自动生成，所以我们不会深入细节。
|
||||
|
||||
An animation file can contain one or multiple animations within it. Our animations will all be under one file called `ghost.a.json` under `RP/animations/`.
|
||||
一个动画文件可以包含一个或多个动画。我们的所有动画将放在`RP/animations/`目录下的`ghost.a.json`文件中。
|
||||
|
||||
<CodeHeader>RP/animations/ghost.a.json</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [RP/animations/ghost.a.json]
|
||||
{
|
||||
"format_version": "1.8.0",
|
||||
"animations": {
|
||||
@@ -471,19 +467,19 @@ An animation file can contain one or multiple animations within it. Our animatio
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Each animation is defined by the key, so here our three animation identifiers are `animation.ghost.idle`, `animation.ghost.attack` and `animation.ghost.move`.
|
||||
|
||||
:::tip NOTE
|
||||
If you have multiple animation files for one entity, consider moving them all into one file to keep your folders easy to read and navigate.
|
||||
If not, ensure that when you are referencing the animation in your entity file, you use the animation identifier and _not_ the file name.
|
||||
:::
|
||||
|
||||
<Spoiler title="Full Animation File">
|
||||
每个动画由键定义，所以这里我们的三个动画标识符是`animation.ghost.idle`、`animation.ghost.attack`和`animation.ghost.move`。
|
||||
|
||||
<CodeHeader>RP/animations/ghost.a.json</CodeHeader>
|
||||
:::tip 提示
|
||||
如果一个实体有多个动画文件，考虑将它们合并到一个文件中，以保持文件夹结构清晰易读。
|
||||
如果不合并，请确保在实体文件中引用动画时使用动画标识符，而不是文件名。
|
||||
:::
|
||||
|
||||
```json
|
||||
::: details 完整动画文件
|
||||
|
||||
::: code-group
|
||||
```json [RP/animations/ghost.a.json]
|
||||
{
|
||||
"format_version": "1.8.0",
|
||||
"animations": {
|
||||
@@ -596,21 +592,21 @@ If not, ensure that when you are referencing the animation in your entity file,
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
</Spoiler>
|
||||
|
||||
### Animation Controller
|
||||
|
||||
We have our animations but our entity won't know when to play them. This is where animation controllers are used. These controllers at their core, _control_ how the animations are played.
|
||||
An animation controller is made up of _states_ and _transitions_ between states. This allows us to play certain animations when the entity is in certain states, which we can transition between when certain conditions are met.
|
||||
### 动画控制器
|
||||
|
||||
For example, while an entity is moving, transition to the moving state which plays the `move` animation. Or while an entity is attacking, transition to the attack state which plays the `attack` animation.
|
||||
有了动画，但实体还不知道何时播放它们。这时就需要动画控制器。这些控制器本质上_控制_动画的播放方式。
|
||||
动画控制器由_状态_和状态间的_过渡_组成。这让我们可以在实体处于特定状态时播放特定动画，并在满足条件时在不同状态间切换。
|
||||
|
||||
Let us look at our animation controller for attacking.
|
||||
例如，当实体移动时，切换到移动状态并播放`move`动画；或者当实体攻击时，切换到攻击状态播放`attack`动画。
|
||||
|
||||
<CodeHeader>RP/animation_controllers/ghost.ac.json#animation_controllers</CodeHeader>
|
||||
让我们看看攻击动画控制器：
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [RP/animation_controllers/ghost.ac.json#animation_controllers]
|
||||
"controller.animation.ghost.attack": {
|
||||
"states": {
|
||||
"default": {
|
||||
@@ -632,12 +628,11 @@ Let us look at our animation controller for attacking.
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
You can see we have two states, `default` and `attacking`. Our entity begins in the default state.
|
||||
可以看到有两个状态：`default`和`attacking`。实体初始处于default状态。
|
||||
|
||||
You can see under `transitions`, we have a condition, which when true will transfer the entity to a state.
|
||||
|
||||
<CodeHeader></CodeHeader>
|
||||
在`transitions`下，有一个条件，当为真时将转换实体到另一个状态。
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -645,19 +640,18 @@ You can see under `transitions`, we have a condition, which when true will trans
|
||||
}
|
||||
```
|
||||
|
||||
Here, `attacking` is the state that will be transitioned to, and `q.is_delayed_attacking` is the condition that needs to be true for the transition to occur.
|
||||
This condition is called a _query_. These queries can tell us things about the entity such as if it is attacking or moving. The query `q.is_delayed_attacking` will return `true` when the entity is performing the attack behavior.
|
||||
这里，`attacking`是要转换到的目标状态，`q.is_delayed_attacking`是触发转换的条件。
|
||||
这个条件称为_查询_。这些查询可以告诉我们关于实体的信息，比如它是否正在攻击或移动。查询`q.is_delayed_attacking`会在实体执行攻击行为时返回`true`。
|
||||
|
||||
When the entity is in the `attacking` state, it also has a transition back to the default state. Now the condition is `!q.is_delayed_attacking`. Here the `!` means _not_, so it will return the opposite result of `q.is_delayed_attacking` (If `q.is_delayed_attacking` returns `true` then `!q.is_delayed_attacking` returns false).
|
||||
当实体处于`attacking`状态时，也有一个返回default状态的过渡。现在的条件是`!q.is_delayed_attacking`。这里的`!`表示_非_，所以它会返回`q.is_delayed_attacking`的相反结果（如果`q.is_delayed_attacking`返回`true`，那么`!q.is_delayed_attacking`返回false）。
|
||||
|
||||
This state also has `animations`. These are the animations that will always play while in this state. Note that we are using the _shortname_ for our animation here, which we will reference in our entity file later. If you don't, the animations will not play.
|
||||
There is also the `blend_transition` key, which allows the animations to slowly fade into each other. A higher number means a longer blending time.
|
||||
这个状态还有`animations`。这些动画将在处于该状态时持续播放。注意这里我们使用的是动画的_短名称_，稍后将在实体文件中引用。如果不这样做，动画将不会播放。
|
||||
还有`blend_transition`键，允许动画之间缓慢过渡融合。数值越大，过渡时间越长。
|
||||
|
||||
We can also make a similar controller for our `move` and `idle` animation.
|
||||
我们也可以为`move`和`idle`动画创建类似的控制器。
|
||||
|
||||
<CodeHeader>RP/animation_controllers/ghost.ac.json#animation_controllers</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [RP/animation_controllers/ghost.ac.json#animation_controllers]
|
||||
"controller.animation.ghost.walk": {
|
||||
"initial_state": "standing",
|
||||
"states": {
|
||||
@@ -682,18 +676,18 @@ We can also make a similar controller for our `move` and `idle` animation.
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
This follows a similar pattern with some additions.
|
||||
We now have `initial_state` which tells the controller which state to start on. If none is listed then it will start on the state `default`.
|
||||
You'll also notice our queries look slightly different. Here the query `q.modified_move_speed` returns a value, so in order to return a boolean (i.e. true or false) we look at when the value is above or below `0.1`. For more in depth information on animation controllers, you can read [here](/animation-controllers/animation-controllers-intro).
|
||||
这遵循类似的模式，但有一些新增内容。
|
||||
现在有了`initial_state`，告诉控制器从哪个状态开始。如果没有指定，则默认为`default`状态。
|
||||
你还会注意到我们的查询有些不同。这里的查询`q.modified_move_speed`返回一个值，所以为了返回布尔值（即真或假），我们检查该值是否大于或小于`0.1`。有关动画控制器的更多详细信息，可以阅读[这里](/animation-controllers/animation-controllers-intro)。
|
||||
|
||||
Now that we have our animation controllers, we can add them to our animation controller file. Similarly to animations, the key is the identifier for our animation controller; `controller.animation.ghost.attack` and `controller.animation.ghost.walk`.
|
||||
现在有了动画控制器，我们可以将它们添加到动画控制器文件中。与动画类似，键是我们的动画控制器标识符：`controller.animation.ghost.attack`和`controller.animation.ghost.walk`。
|
||||
|
||||
Our file will be called `ghost.ac.json` and will be placed in `RP/animation_controllers/`.
|
||||
我们的文件将命名为`ghost.ac.json`，放在`RP/animation_controllers/`目录下。
|
||||
|
||||
<CodeHeader>RP/animation_controllers/ghost.ac.json</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [RP/animation_controllers/ghost.ac.json]
|
||||
{
|
||||
"format_version": "1.12.0",
|
||||
"animation_controllers": {
|
||||
@@ -743,17 +737,17 @@ Our file will be called `ghost.ac.json` and will be placed in `RP/animation_cont
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
With that, we have created all the resources we need for our entity. We will now create our entity file.
|
||||
至此，我们已经创建了实体所需的所有资源。现在我们将创建实体文件。
|
||||
|
||||
### Entity Client File
|
||||
### 实体客户端文件
|
||||
|
||||
The client file contains all the references to the visual components of our entity.
|
||||
Our client file will go in `RP/entity/` and we name this file `ghost.ce.json`. This file will have all our information under the `description` key. We begin with the familiar formatting:
|
||||
客户端文件包含实体所有视觉组件的引用。
|
||||
我们的客户端文件将放在`RP/entity/`目录下，命名为`ghost.ce.json`。这个文件的所有信息都在`description`键下。我们从熟悉的格式开始：
|
||||
|
||||
<CodeHeader>RP/entity/ghost.ce.json</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [RP/entity/ghost.ce.json]
|
||||
{
|
||||
"format_version": "1.10.0",
|
||||
"minecraft:client_entity": {
|
||||
@@ -763,22 +757,22 @@ Our client file will go in `RP/entity/` and we name this file `ghost.ce.json`. T
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
We use the same identifier as for our behavior file in order to point to the correct entity.
|
||||
我们使用与行为文件相同的标识符，以指向正确的实体。
|
||||
|
||||
To begin, we need to define the visuals of our entity in our file so we know which models and textures we are using. We also need to do the same for our animations and animation controllers.
|
||||
首先，我们需要在文件中定义实体的视觉效果，这样游戏就知道使用哪些模型和纹理。我们还需要为动画和动画控制器做同样的事。
|
||||
|
||||
#### Render Controller
|
||||
#### 渲染控制器
|
||||
|
||||
In order to display our entity it needs to be _rendered_. For this to happen, it needs a material, texture and geometry. We have already made a texture and geometry. A material defines how our texture will be displayed. For example, a skeleton uses a material to allow for transparency and an enderman uses a material to allow its eyes to glow.
|
||||
为了显示实体，它需要被_渲染_。为此，它需要材质、纹理和几何模型。我们已经创建了纹理和几何模型。材质定义了纹理如何显示。例如，骷髅使用材质实现透明度，末影人使用材质让眼睛发光。
|
||||
|
||||
Since our ghost has some transparency, we need a material which will render this correctly. Luckily, Minecraft has many pre-built materials for us to use such as `entity_alphatest` which will allow us to do this. You can create your own materials but be warned it is very advanced. If you are interested though, you can begin [here](/wiki/documentation/materials).
|
||||
由于我们的幽灵有一定透明度，我们需要一个能正确渲染这一效果的材质。幸运的是，Minecraft有许多预置材质可供使用，比如`entity_alphatest`就能满足我们的需求。你可以创建自己的材质，但要注意这非常复杂。如果有兴趣，可以从[这里](/wiki/documentation/materials)开始学习。
|
||||
|
||||
For us to now use these resources, we need to define a reference to them with a shortname. This is similar to how we did for items within the `item_texture.json` file, except here we do it in the entity client file. Here is the layout.
|
||||
为了使用这些资源，我们需要用短名称定义对它们的引用。这与在`item_texture.json`文件中为物品所做的类似，只不过这里是在实体客户端文件中完成。以下是布局：
|
||||
|
||||
<CodeHeader>RP/entity/ghost.ce.json</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [RP/entity/ghost.ce.json]
|
||||
{
|
||||
"format_version": "1.10.0",
|
||||
"minecraft:client_entity": {
|
||||
@@ -797,17 +791,17 @@ For us to now use these resources, we need to define a reference to them with a
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
Here for each category we have assigned the shortname `default` for each of our resources, ensuring to use the correct paths and identifiers. We are able to define multiple of these, though that is more advanced. Now we can use these shortnames to reference our resources.
|
||||
这里我们为每个资源类别分配了短名称`default`，确保使用正确的路径和标识符。我们可以定义多个这样的资源，但这属于更高级的内容。现在我们可以使用这些短名称来引用我们的资源。
|
||||
|
||||
In order for these resources to be rendered, we need to tell the game which resources to render in. This is controlled with a _render controller_. The controller tells the game which geometry, material and texture to render for the entity, allowing us to see it in game.
|
||||
为了让这些资源被渲染，我们需要告诉游戏要渲染哪些资源。这是通过_渲染控制器_实现的。控制器告诉游戏要为实体渲染哪个几何模型、材质和纹理，让我们能在游戏中看到它。
|
||||
|
||||
The render controller is defined in a separate file and uses the shortnames we defined in our entity file.
|
||||
The file is called `ghost.rc.json` and is under `RP/render_controllers/`:
|
||||
渲染控制器定义在单独的文件中，使用我们在实体文件中定义的短名称。
|
||||
文件名为`ghost.rc.json`，位于`RP/render_controllers/`目录下：
|
||||
|
||||
<CodeHeader>RP/render_controllers/entity/ghost.rc.json</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [RP/render_controllers/entity/ghost.rc.json]
|
||||
{
|
||||
"format_version": "1.10.0",
|
||||
"render_controllers": {
|
||||
@@ -823,27 +817,27 @@ The file is called `ghost.rc.json` and is under `RP/render_controllers/`:
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
This follows a similar structure to the animation controller and animation file, with our render controller identifier being `controller.render.ghost`.
|
||||
This tells the game that the resource rendered should be the resource with shortname `default`. Render controllers can also allow you to display different textures or apply different materials to different parts of our model. Under `materials`, we use `"*"` to mean that we apply this material to all _bones_ in our model (i.e. each cube in our model.) For more information on render controllers, you can check our page [here](/wiki/entities/render-controllers).
|
||||
|
||||
:::tip
|
||||
If you keep your shortnames consistent, you can actually reference the same render controller for multiple entities.
|
||||
:::
|
||||
|
||||
Now to tell your entity to use this render controller, we add it to our entity file like so:
|
||||
这与动画控制器和动画文件的结构类似，我们的渲染控制器标识符是`controller.render.ghost`。
|
||||
这告诉游戏渲染的资源应该是短名称为`default`的资源。渲染控制器还可以让你为模型的不同部分显示不同纹理或应用不同材质。在`materials`下，我们使用`"*"`表示将材质应用到模型中的所有_骨骼_（即模型中的每个方块）。有关渲染控制器的更多信息，可以查看[此页面](/wiki/entities/render-controllers)。
|
||||
|
||||
<CodeHeader>RP/entity/ghost.ce.json#description</CodeHeader>
|
||||
:::tip 提示
|
||||
如果保持短名称一致，你实际上可以为多个实体引用同一个渲染控制器。
|
||||
:::
|
||||
|
||||
```json
|
||||
现在要让你的实体使用这个渲染控制器，我们像这样将其添加到实体文件中：
|
||||
|
||||
::: code-group
|
||||
```json [RP/entity/ghost.ce.json#description]
|
||||
"render_controllers": ["controller.render.ghost"]
|
||||
```
|
||||
:::
|
||||
|
||||
With that our entity file should look like this.
|
||||
这样我们的实体文件应该如下所示：
|
||||
|
||||
<CodeHeader>RP/entity/ghost.ce.json</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [RP/entity/ghost.ce.json]
|
||||
{
|
||||
"format_version": "1.10.0",
|
||||
"minecraft:client_entity": {
|
||||
@@ -863,16 +857,16 @@ With that our entity file should look like this.
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
Now if we spawn our entity into a world, we should be able to see it.
|
||||
现在如果我们将实体生成到世界中，应该能看到它了。
|
||||
|
||||
#### Scripts
|
||||
#### 脚本
|
||||
|
||||
Now let us add our animations. Like with our other resources, we need to define shortnames for them. Keep in mind, we also need to define shortnames our animation controllers as well.
|
||||
现在添加我们的动画。与其他资源一样，我们需要为它们定义短名称。注意，我们还需要为动画控制器定义短名称。
|
||||
|
||||
<CodeHeader>RP/entity/ghost.ce.json#description</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [RP/entity/ghost.ce.json#description]
|
||||
"animations": {
|
||||
"walk_controller": "controller.animation.ghost.walk",
|
||||
"attack_controller": "controller.animation.ghost.attack",
|
||||
@@ -881,14 +875,14 @@ Now let us add our animations. Like with our other resources, we need to define
|
||||
"move": "animation.ghost.move"
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
You'll recall, these are the shortnames we used in our animation controllers; any animations we want to use in animation controllers, must be defined with a shortname in the entity client file.
|
||||
你可能记得，这些是我们在动画控制器中使用的短名称；任何要在动画控制器中使用的动画，都必须在实体客户端文件中用短名称定义。
|
||||
|
||||
Now that we have animations and animation controllers referenced, we need to decide when the entity will run them. This is done using `scripts`:
|
||||
现在有了引用的动画和动画控制器，我们需要决定实体何时运行它们。这是通过`scripts`实现的：
|
||||
|
||||
<CodeHeader>RP/entity/ghost.ce.json#description</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [RP/entity/ghost.ce.json#description]
|
||||
"scripts": {
|
||||
"animate": [
|
||||
"walk_controller",
|
||||
@@ -896,25 +890,26 @@ Now that we have animations and animation controllers referenced, we need to dec
|
||||
]
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
Here, `scripts` tell the entity to perform certain actions at certain times. The `animate` key will run any animation or controller referenced every tick. This means that each tick our animation controller will check whether to transition to a new state and perform any animations in the state they are in.
|
||||
这里，`scripts`告诉实体在特定时间执行特定动作。`animate`键会每tick运行任何引用的动画或控制器。这意味着每个tick我们的动画控制器都会检查是否要转换到新状态，并执行当前状态中的任何动画。
|
||||
|
||||
With this our animations should be working correctly.
|
||||
这样我们的动画应该能正确工作了。
|
||||
|
||||
#### Spawn Egg
|
||||
#### 刷怪蛋
|
||||
|
||||
The final step to finalise our entity client file, is to create a spawn egg for our entity. Luckily, our file can generate one for us with the key `spawn_egg`.
|
||||
完成实体客户端文件的最后一步是为我们的实体创建一个刷怪蛋。幸运的是，我们的文件可以通过`spawn_egg`键自动生成一个。
|
||||
|
||||
<CodeHeader>RP/entity/ghost.ce.json#description</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [RP/entity/ghost.ce.json#description]
|
||||
"spawn_egg": {
|
||||
"overlay_color": "#bdd1d1",
|
||||
"base_color": "#9fb3b3"
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
This will generate a spawn egg which will summon our entity when used. It uses the hex codes in `base_color` and `overlay_color` to color the egg. If you want a custom icon for your spawn egg, instead use the key `texture` and put in the shortname to the texture you want. Follow the method in the item tutorial on how to define an texture shortname for an item.
|
||||
这将生成一个使用时会召唤我们实体的刷怪蛋。它使用`base_color`和`overlay_color`中的十六进制代码为蛋着色。如果想要刷怪蛋有自定义图标，可以使用`texture`键并放入所需纹理的短名称。按照物品教程中的方法为物品定义纹理短名称。
|
||||
|
||||
```json
|
||||
"spawn_egg": {
|
||||
@@ -922,13 +917,12 @@ This will generate a spawn egg which will summon our entity when used. It uses t
|
||||
}
|
||||
```
|
||||
|
||||
With that, we have completed our entity client file.
|
||||
至此，我们已经完成了实体客户端文件。
|
||||
|
||||
<Spoiler title="Full ghost.ce.json">
|
||||
::: details 完整的ghost.ce.json
|
||||
|
||||
<CodeHeader>RP/entity/ghost.ce.json</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [RP/entity/ghost.ce.json]
|
||||
{
|
||||
"format_version": "1.10.0",
|
||||
"minecraft:client_entity": {
|
||||
@@ -962,25 +956,24 @@ With that, we have completed our entity client file.
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
</Spoiler>
|
||||
### 实体名称
|
||||
|
||||
### Entity name
|
||||
最后一步是将实体名称添加到语言文件中。你可能还注意到，如果创建了刷怪蛋，它也会有一个名称的翻译键；我们也要添加这个。在`en_US.lang`中，确保为实体和实体刷怪蛋物品都添加了名称。它们应该类似这样：
|
||||
|
||||
The final steps are to add our entity's name to the language files. You may have also noticed that if you created a spawn egg, it will also have a translation key for a name; we will also add this. Within `en_US.lang`, make sure you add names for both the entity and entity spawn egg item. They should look similar to this:
|
||||
|
||||
<CodeHeader>RP/texts/en_US.lang</CodeHeader>
|
||||
|
||||
```json
|
||||
entity.wiki:ghost.name=Ghost
|
||||
item.spawn_egg.entity.wiki:ghost.name=Ghost
|
||||
::: code-group
|
||||
```json [RP/texts/en_US.lang]
|
||||
entity.wiki:ghost.name=幽灵
|
||||
item.spawn_egg.entity.wiki:ghost.name=幽灵
|
||||
```
|
||||
:::
|
||||
|
||||
## Overview
|
||||
## 最终成果
|
||||
|
||||
Done! Your entity should now show up in Minecraft, complete with all behaviors and visuals, including animations! You should be able to summon your entity using `/summon` or by finding the spawn egg in the creative menu.
|
||||
完成！现在你的实体应该已经完整地出现在Minecraft中，包含所有行为和视觉效果，还有动画！你可以使用`/summon`命令召唤实体，或者在创造模式菜单中找到刷怪蛋。
|
||||
|
||||
Your folder structure should look like this:
|
||||
你的文件夹结构应该如下所示：
|
||||
|
||||
<FolderView :paths="[
|
||||
'RP/animations/ghost.a.json',
|
||||
@@ -1003,11 +996,10 @@ Your folder structure should look like this:
|
||||
'BP/pack_icon.png',
|
||||
]"></FolderView>
|
||||
|
||||
<Spoiler title="Full ghost.se.json">
|
||||
::: details 完整的ghost.se.json
|
||||
|
||||
<CodeHeader>BP/entities/ghost.se.json</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [BP/entities/ghost.se.json]
|
||||
{
|
||||
"format_version": "1.16.0",
|
||||
"minecraft:entity": {
|
||||
@@ -1097,14 +1089,14 @@ Your folder structure should look like this:
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
</Spoiler>
|
||||
|
||||
<Spoiler title="Full ghost.ce.json">
|
||||
|
||||
<CodeHeader>RP/entity/ghost.ce.json</CodeHeader>
|
||||
::: details 完整的ghost.ce.json
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [RP/entity/ghost.ce.json]
|
||||
{
|
||||
"format_version": "1.10.0",
|
||||
"minecraft:client_entity": {
|
||||
@@ -1138,14 +1130,14 @@ Your folder structure should look like this:
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
</Spoiler>
|
||||
|
||||
<Spoiler title="Full ghost.geo.json">
|
||||
|
||||
<CodeHeader>RP/models/entity/ghost.geo.json</CodeHeader>
|
||||
::: details 完整的ghost.geo.json
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [RP/models/entity/ghost.geo.json]
|
||||
{
|
||||
"format_version": "1.12.0",
|
||||
"minecraft:geometry": [
|
||||
@@ -1213,14 +1205,14 @@ Your folder structure should look like this:
|
||||
]
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
</Spoiler>
|
||||
|
||||
<Spoiler title="Full ghost.a.json">
|
||||
|
||||
<CodeHeader>RP/animations/ghost.a.json</CodeHeader>
|
||||
::: details 完整的ghost.a.json
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [RP/animations/ghost.a.json]
|
||||
{
|
||||
"format_version": "1.8.0",
|
||||
"animations": {
|
||||
@@ -1333,14 +1325,14 @@ Your folder structure should look like this:
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
</Spoiler>
|
||||
|
||||
<Spoiler title="Full ghost.ac.json">
|
||||
|
||||
<CodeHeader>RP/animation_controllers/ghost.ac.json</CodeHeader>
|
||||
::: details 完整的ghost.ac.json
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [RP/animation_controllers/ghost.ac.json]
|
||||
{
|
||||
"format_version": "1.12.0",
|
||||
"animation_controllers": {
|
||||
@@ -1390,14 +1382,14 @@ Your folder structure should look like this:
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
</Spoiler>
|
||||
|
||||
<Spoiler title="Full ghost.rc.json">
|
||||
|
||||
<CodeHeader>RP/render_controllers/entity/ghost.rc.json</CodeHeader>
|
||||
::: details 完整的ghost.rc.json
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [RP/render_controllers/entity/ghost.rc.json]
|
||||
{
|
||||
"format_version": "1.10.0",
|
||||
"render_controllers": {
|
||||
@@ -1413,19 +1405,18 @@ Your folder structure should look like this:
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
</Spoiler>
|
||||
|
||||
## Your progress so far
|
||||
## 当前进度
|
||||
|
||||
<Checklist>
|
||||
|
||||
- [x] Setup your pack
|
||||
- [x] Create a custom item
|
||||
- [x] Create a custom entity
|
||||
- [x] - How to format the behavior- and resource files for an item
|
||||
- [x] - How to set an entities texture
|
||||
- [x] - How to use models, animations, and animation controllers to make your entity more exciting
|
||||
- [ ] Create the entity's loot, spawn rules, and a custom recipe
|
||||
- [x] 建立资源包
|
||||
- [x] 创建自定义物品
|
||||
- [x] 创建自定义实体
|
||||
- [x] - 如何格式化物品的行为和资源文件
|
||||
- [x] - 如何设置实体纹理
|
||||
- [x] - 如何使用模型、动画和动画控制器让实体更生动
|
||||
- [ ] 创建实体的战利品表、生成规则和自定义配方
|
||||
|
||||
</Checklist>
|
||||
@@ -88,6 +88,7 @@ mentions:
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
此时你只需在`RP/textures/item_texture.json`中添加名为`my_chest`的纹理即可。我们提供了默认纹理供参考：
|
||||
|
||||
@@ -131,6 +132,7 @@ mentions:
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
下载配套纹理文件：
|
||||
|
||||
@@ -190,6 +192,7 @@ mentions:
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
护腿纹理下载：
|
||||
|
||||
@@ -224,6 +227,7 @@ mentions:
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
## 头盔部分
|
||||
|
||||
@@ -255,6 +259,7 @@ mentions:
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
头盔纹理下载：
|
||||
|
||||
@@ -291,6 +296,7 @@ mentions:
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
靴子纹理下载：
|
||||
|
||||
@@ -321,6 +327,7 @@ mentions:
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
```json [BP/entities/player.json#events]
|
||||
"wiki:armor_sets.my_custom.taken_damage": {
|
||||
@@ -347,6 +354,7 @@ mentions:
|
||||
]
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
完成效果展示：
|
||||
|
||||
|
||||
@@ -71,7 +71,9 @@ mentions:
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
::: code-group
|
||||
```json [RP/textures/item_texture.json]
|
||||
{
|
||||
"resource_pack_name": "vanilla",
|
||||
@@ -128,7 +130,9 @@ mentions:
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
::: code-group
|
||||
```json [BP/items/my_sword.json]
|
||||
"events": {
|
||||
"wiki:my_sword.on_dig_damage": {
|
||||
@@ -160,7 +164,9 @@ mentions:
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
::: code-group
|
||||
```json [BP/items/my_sword.json]
|
||||
"events": {
|
||||
"wiki:my_sword.hurt_entity": {
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
---
|
||||
title: 物品 Items
|
||||
nav_order: 4
|
||||
categories:
|
||||
- title: 基础
|
||||
color: blue
|
||||
|
||||
@@ -1,26 +1,30 @@
|
||||
---
|
||||
title: Numerical Item IDs
|
||||
category: Documentation
|
||||
title: 数字物品ID
|
||||
category: 文档
|
||||
---
|
||||
|
||||
# 数字物品ID
|
||||
|
||||
<!--@include: @/wiki/bedrock-wiki-mirror.md-->
|
||||
|
||||
::: tip
|
||||
This page is a more up-to-date version of [this page](https://learn.microsoft.com/en-us/minecraft/creator/reference/content/addonsreference/examples/addonitems), and is current as of version 1.20.51.
|
||||
本页面是[此微软文档](https://learn.microsoft.com/en-us/minecraft/creator/reference/content/addonsreference/examples/addonitems)的更新版本，内容基于1.20.51版本。
|
||||
:::
|
||||
|
||||
## Overview
|
||||
## 概述
|
||||
|
||||
Item IDs (not to be confused with type IDs) are an older system which are mainly used to render items with [JSON UI](/wiki/json-ui/json-ui-documentation#item-id-aux-item-id-aux) nowadays. All items & blocks (Even custom ones!) have their own unique ID.
|
||||
物品ID（注意不要与类型ID混淆）是一个较旧的系统，目前主要用于通过[JSON UI](/wiki/json-ui/json-ui-documentation#item-id-aux-item-id-aux)渲染物品。所有物品和方块（包括自定义的！）都有自己唯一的ID。
|
||||
|
||||
## ID Formatting
|
||||
- Vanilla items & blocks have IDs from `-743` to `721`.
|
||||
- All custom blocks have *increasingly negative* IDs, starting from an ID of `-744`. These do not interfere with vanilla IDs in any way. Note that custom blocks do not currently render with their IDs. It is unknown if this is a bug or not.
|
||||
- All non-experimental items (1.10 format) have *increasingly positive* IDs, starting from an ID of `722`. These do not interfere with vanilla IDs in any way.
|
||||
- All experimental items (1.16.100 format) have *increasingly positive* IDs, starting from an ID of 257. These **WILL SHIFT VANILLA IDs** that are higher than 256. For example, `'minecraft:apple'` (ID of `257`) will be moved up to an ID of `258` if you have one experimental item.
|
||||
## ID格式规则
|
||||
- 原版物品和方块的ID范围是`-743`至`721`
|
||||
- 所有自定义方块使用**递减的负数ID**，从`-744`开始。这些ID不会与原版ID产生冲突。注意：当前自定义方块不会显示其ID，尚不明确这是否是bug
|
||||
- 所有非实验性物品（1.10格式）使用**递增的正数ID**，从`722`开始。这些ID不会与原版ID产生冲突
|
||||
- 所有实验性物品（1.16.100格式）使用**递增的正数ID**，从`257`开始。这些ID**会导致高于256的原版ID发生偏移**。例如，如果你添加了一个实验性物品，`'minecraft:apple'`（原ID为`257`）会被移动到`258`
|
||||
|
||||
## Vanilla ID List
|
||||
Note for this list that a namespace of `minecraft:` is assumed for all items & blocks.
|
||||
## 原版ID列表
|
||||
请注意，本列表中所有物品和方块都默认使用`minecraft:`命名空间。
|
||||
|
||||
| Name | ID |
|
||||
| 物品名称 | ID |
|
||||
| ----------------- | :--: |
|
||||
| dark_oak_planks | -743 |
|
||||
| acacia_planks | -742 |
|
||||
|
||||
@@ -18,17 +18,13 @@ mentions:
|
||||
<!--@include: @/wiki/bedrock-wiki-mirror.md-->
|
||||
|
||||
:::tip
|
||||
本文包含关于_物品_的故障排查信息。在继续阅读前，建议先查看[全局故障排查指南](/wiki/guide/troubleshooting)。
|
||||
本文包含关于 _物品_ 的故障排查信息。在继续阅读前，建议先查看[全局故障排查指南](/wiki/guide/troubleshooting)。
|
||||
:::
|
||||
|
||||
## 从这里开始
|
||||
|
||||
我按照教程制作了自定义物品，但出现了问题！请保持冷静。本指南将帮助您排查常见问题。根据按钮提示了解可能的问题原因及修复方法。
|
||||
|
||||
<BButton color="blue" link="#_1-10-vs-1-16-items">继续</BButton>
|
||||
|
||||
---
|
||||
|
||||
## 1.10 与 1.16 格式物品的区别？
|
||||
|
||||
首先需要确认您使用的是实验性物品格式还是稳定版物品格式。
|
||||
@@ -47,12 +43,6 @@ mentions:
|
||||
🔗 [实验性物品文档](https://bedrock.dev/docs/stable/Item)
|
||||
:::
|
||||
|
||||
### 继续选择
|
||||
|
||||
<BButton color="blue" link="#stable-items">1.10 格式（稳定版）</BButton> <BButton color="blue" link="#experimental-items">1.16.100 格式（实验性）</BButton>
|
||||
|
||||
---
|
||||
|
||||
## 稳定版物品
|
||||
|
||||
本部分针对稳定版物品的故障排查。请注意：使用 `1.10` 格式时，您需要同时存在 RP 和 BP 文件！如果只有 BP 文件，说明混淆了格式版本。请返回[此处](#_1-10-vs-1-16-items)重新确认。
|
||||
@@ -125,8 +115,6 @@ mentions:
|
||||
|
||||
正确配置后物品将正常显示贴图。
|
||||
|
||||
---
|
||||
|
||||
## 实验性物品
|
||||
|
||||
本部分针对实验性物品格式的故障排查。请注意：使用 `1.16` 格式时**不应存在 RP 物品文件**！如果同时存在 RP 和 BP 文件，说明混淆了格式版本。请返回[此处](#_1-10-vs-1-16-items)重新确认。
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
---
|
||||
title: JSON UI
|
||||
nav_order: 10
|
||||
categories:
|
||||
- title: 基础
|
||||
color: blue
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,5 +1,6 @@
|
||||
---
|
||||
title: 战利品、配方、交易
|
||||
nav_order: 11
|
||||
categories:
|
||||
- title: 基础
|
||||
color: blue
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,10 +1,10 @@
|
||||
---
|
||||
title: Recipes
|
||||
category: Documentation
|
||||
title: 配方系统
|
||||
category: 文档
|
||||
nav_order: 3
|
||||
tags:
|
||||
- Stable
|
||||
- Last updated for Version 1.20.30
|
||||
- 稳定版本
|
||||
- 最后更新于1.20.30版本
|
||||
mentions:
|
||||
- Ciosciaa
|
||||
- SirLich
|
||||
@@ -14,21 +14,25 @@ mentions:
|
||||
- QuazChick
|
||||
---
|
||||
|
||||
Recipes are the means of handling several item transactions, namely those occurring in crafting tables, furnaces, campfires, and brewing stands.
|
||||
# 配方系统
|
||||
|
||||
<!--@include: @/wiki/bedrock-wiki-mirror.md-->
|
||||
|
||||
配方系统用于处理多种物品转换逻辑，包括工作台、熔炉、营火和酿造台的合成流程。
|
||||
|
||||
|
||||
|
||||
::: tip
|
||||
Anvil interactions are handled within an [item definition](/wiki/items/item-components), not via recipe files. Loom transactions are currently unavailable.
|
||||
铁砧交互通过[物品定义](/wiki/items/item-components)实现，而非配方文件。织布机交互当前暂不可用。
|
||||
:::
|
||||
|
||||
No experimental toggles are required to use recipes or any of their features.
|
||||
使用配方功能无需开启任何实验性选项。
|
||||
|
||||
### Registration
|
||||
## 注册方式
|
||||
|
||||
All recipes are stored in the `recipes` folder in the behavior pack root. The files can be named and organized under any folder hierarchy as desired.
|
||||
所有配方文件需存放在行为包根目录的`recipes`文件夹中，支持任意子目录结构和命名方式。
|
||||
|
||||
This arbitrary structure is used for the paths in this document:
|
||||
以下示例展示了本文档采用的目录结构：
|
||||
|
||||
<FolderView
|
||||
:paths="[
|
||||
@@ -41,10 +45,10 @@ This arbitrary structure is used for the paths in this document:
|
||||
]"
|
||||
/>
|
||||
|
||||
As an example, a "cold steel sword" might be crafted using the following [shaped recipe](#shaped-recipes):
|
||||
例如，可通过以下[有序配方](#有序配方)制作"寒钢剑"：
|
||||
|
||||
<CodeHeader>BP/recipes/crafting/weapons/cold_steel_sword.json</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [BP/recipes/crafting/weapons/cold_steel_sword.json]
|
||||
{
|
||||
"format_version": "1.17.41",
|
||||
"minecraft:recipe_shaped": {
|
||||
@@ -77,211 +81,217 @@ As an example, a "cold steel sword" might be crafted using the following [shaped
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Shared Properties and Structures
|
||||
|
||||
### Format Version
|
||||
|
||||
The [format version](/wiki/guide/format-version) is intended to version the schema used for the body of a recipe. It is provided with the top-level `"format_version"` property.
|
||||
|
||||
<CodeHeader>#/</CodeHeader>
|
||||
```json
|
||||
"format_version": "1.17.41"
|
||||
```
|
||||
|
||||
In practice, the format version can be set to any value or even omitted.
|
||||
|
||||
::: warning
|
||||
It's strongly recommended to include a format version anyway, choosing a value that represents an actual Minecraft version to help future-proof the code. Consider using the current release version or last major release version.
|
||||
:::
|
||||
|
||||
### Description
|
||||
## 通用属性与结构
|
||||
|
||||
The `"description"` object, required within any recipe type, holds the identifier of a recipe.
|
||||
### 格式版本
|
||||
|
||||
<CodeHeader>#/minecraft:recipe_shaped/</CodeHeader>
|
||||
```json
|
||||
[格式版本](/wiki/guide/format-version)用于标识配方文件的架构版本，通过顶层`"format_version"`属性指定。
|
||||
|
||||
::: code-group
|
||||
```json [#/]
|
||||
"format_version": "1.17.41"
|
||||
```
|
||||
:::
|
||||
|
||||
实际使用中格式版本可设为任意值或省略。
|
||||
|
||||
::: warning
|
||||
强烈建议仍保留格式版本，并选择与当前Minecraft版本匹配的值以保证未来兼容性。推荐使用最新正式版或上一个主版本号。
|
||||
:::
|
||||
|
||||
### 描述信息
|
||||
|
||||
`"description"`对象是所有配方类型的必填项，用于声明配方唯一标识符。
|
||||
|
||||
::: code-group
|
||||
```json [#/minecraft:recipe_shaped/]
|
||||
"description": {
|
||||
"identifier": "wiki:cold_steel_sword"
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
Its only child is the required `"identifier"` property, which is designed to uniquely identify a recipe across all packs applied to a world. There are no namespacing requirements for recipe identifiers except that no two full recipe identifiers in a single pack may match.
|
||||
其中必填的`"identifier"`属性用于在世界中所有行为包范围内唯一标识配方。单个包内不允许存在重复的完整配方ID。
|
||||
|
||||
::: warning
|
||||
It's strongly recommended to use a namespace. Namespaces are a standard in other add-on domains and assist in logically scoping the recipe to a pack, lessening possibilities of collisions for players wanting to use multiple behavior packs in their world.
|
||||
强烈建议使用命名空间。命名空间是附加组件领域的通用规范，有助于将配方逻辑归属到特定行为包，减少多包混用时发生冲突的可能性。
|
||||
:::
|
||||
|
||||
### Tags
|
||||
### 标签系统
|
||||
|
||||
Recipes are linked to crafting interfaces using the required `"tags"` array property, which must be placed within any recipe type. These tags will make the recipe be shared across different blocks that uses the `minecraft:crafting_table` component. When the recipe does not inlcude the `crafting_table` tag, or any vanilla tag, but a tag from your custom block, the recipe will only be shared to that custom block and not the crafting table/stonecutter/etc. At least one tag must be provided.
|
||||
通过必填的`"tags"`数组属性将配方与合成界面关联，该属性需置于任何配方类型中。这些标签会使配方在具有`minecraft:crafting_table`组件的不同方块间共享。若配方不包含`crafting_table`标签或任何原版标签，但包含自定义方块的标签，则该配方仅适用于该自定义方块而非工作台/切石机等。必须提供至少一个标签。
|
||||
|
||||
<CodeHeader>#/minecraft:recipe_shaped/</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/minecraft:recipe_shaped/]
|
||||
"tags": ["crafting_table", "altar"]
|
||||
```
|
||||
|
||||
Vanilla interfaces are exposed to tags for each set of recipe types.
|
||||
|
||||
Crafting:
|
||||
|
||||
- `crafting_table`
|
||||
- `stonecutter`
|
||||
- `smithing_table`
|
||||
|
||||
:::
|
||||
warning Note that if you want to make a smithing recipe, you will need to use `<namespace>:netherite_ingot` for the second slot, though using a different identifier will not work. **This no longer works after 1.18.30**.
|
||||
:::
|
||||
|
||||
Cooking and Smelting:
|
||||
原版界面为各类配方类型开放了对应标签：
|
||||
|
||||
- `furnace`
|
||||
- `blast_furnace`
|
||||
- `smoker`
|
||||
- `campfire`
|
||||
- `soul_campfire`
|
||||
合成类：
|
||||
- `crafting_table`
|
||||
- `stonecutter`
|
||||
- `smithing_table`
|
||||
|
||||
Brewing:
|
||||
::: warning
|
||||
注意：若要制作锻造台配方，第二个槽位必须使用`<命名空间>:netherite_ingot`，使用其他标识符将无效。**此特性在1.18.30后已失效**。
|
||||
:::
|
||||
|
||||
- `brewing_stand`
|
||||
熔炼类：
|
||||
- `furnace`
|
||||
- `blast_furnace`
|
||||
- `smoker`
|
||||
- `campfire`
|
||||
- `soul_campfire`
|
||||
|
||||
Education:
|
||||
酿造类：
|
||||
- `brewing_stand`
|
||||
|
||||
- `material_reducer`
|
||||
教育版：
|
||||
- `material_reducer`
|
||||
|
||||
::: tip
|
||||
Additionally, [custom crafting tables](/wiki/blocks/block-components#crafting-table) can declare a custom tag for crafting recipes to use. Custom cooking and smelting blocks and custom brewing stands are not currently available.
|
||||
此外，[自定义工作台](/wiki/blocks/block-components#crafting-table)可声明自定义标签供合成配方使用。目前不支持自定义熔炉和酿造台。
|
||||
:::
|
||||
|
||||
::: tip
|
||||
To effectively disable a recipe (useful for [overriding](#overrides) a prior recipe), set the tag array to `[""]`.
|
||||
要禁用配方（常用于[覆盖](#覆盖机制)已有配方），可将标签数组设为`[""]`。
|
||||
:::
|
||||
|
||||
### Recipe Unlocking
|
||||
Minecraft 1.20.30 added recipe unlocking to the game. In order to have your recipes use this function, you `manifest.json` must have a `min_engine_version` of 1.20.11 (1.20.30 is recommender). You also need to add the `unlock` array with its objects to your recipe.
|
||||
### 配方解锁
|
||||
Minecraft 1.20.30新增了配方解锁功能。要使用此功能，需确保`manifest.json`中的`min_engine_version`至少为1.20.11（推荐1.20.30），并在配方中添加`unlock`数组：
|
||||
```json
|
||||
"unlock": [
|
||||
{
|
||||
"item": "wiki:cold_steel" //item to unlock recipe
|
||||
"item": "wiki:cold_steel" //解锁配方所需物品
|
||||
},
|
||||
{
|
||||
"item": "minecraft:wool", //item to unlock recipe
|
||||
"item": "minecraft:wool", //解锁配方所需物品
|
||||
"data": 3
|
||||
},
|
||||
{
|
||||
"context": "PlayerInWater" //event to unlock recipe
|
||||
"context": "PlayerInWater" //解锁配方所需事件
|
||||
}
|
||||
]
|
||||
```
|
||||
Each object in this array contains `"item"` and this tells the recipe what item the player needs in their inventory in order for this recipe to be unlocked. It also accepts data values. `"context"` is used to determine what event unlocks this recipe. `"PlayerInWater"` will unlock this recipe when the player enters water. This is also the only known context for recipes.
|
||||
数组中每个对象的`"item"`字段表示玩家背包中需要存在的物品（支持数据值）。`"context"`字段表示触发解锁的事件，目前仅知`"PlayerInWater"`会在玩家入水时解锁配方。
|
||||
|
||||
### Item Descriptors
|
||||
### 物品描述符
|
||||
|
||||
Working with recipes entails referencing items across a number of properties. Items may be provided in one of two formats: a string reference or an item object. Both formats have means of handling data values, but only the item object may be used to specify a count for that item (usable in recipe outputs). For recipe inputs, if no data value is provided, items with any data value under that identifier will be usable for that input. The data value for an output defaults to `0` if one is not explicitly provided. Selecting recipe inputs by item tags is not supported.
|
||||
配方系统中涉及多种物品引用方式，支持两种格式：字符串引用和物品对象。两种格式均可处理数据值，但只有物品对象能指定数量（用于配方输出）。对于配方输入，若未指定数据值，则该标识符下任意数据值的物品都可用作输入。输出物品的数据值默认为`0`（若未显式指定）。不支持通过物品标签选择配方输入。
|
||||
|
||||
#### String Reference
|
||||
#### 字符串引用
|
||||
|
||||
Generally, a string reference is just the namespace and identifier combination for that item:
|
||||
基本格式为物品的命名空间加标识符组合：
|
||||
|
||||
<CodeHeader>#/minecraft:recipe_shapeless/ingredients/0</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/minecraft:recipe_shapeless/ingredients/0]
|
||||
"minecraft:planks"
|
||||
```
|
||||
:::
|
||||
|
||||
String references additionally support specification of a data value as a suffix:
|
||||
字符串引用还支持通过后缀指定数据值：
|
||||
|
||||
<CodeHeader>#/minecraft:recipe_shapeless/ingredients/0</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/minecraft:recipe_shapeless/ingredients/0]
|
||||
"minecraft:planks:2"
|
||||
```
|
||||
:::
|
||||
|
||||
#### Item Object
|
||||
#### 物品对象
|
||||
|
||||
The item object is a more explicit construct for referencing items.
|
||||
物品对象提供了更明确的物品引用结构。
|
||||
|
||||
<CodeHeader>#/minecraft:recipe_shapeless/ingredients/0</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/minecraft:recipe_shapeless/ingredients/0]
|
||||
{
|
||||
"item": "minecraft:planks",
|
||||
"data": 2,
|
||||
"count": 3
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
The required `"item"` property functions the same as the string reference format. Although an explicit data field is available, the data suffix string format is still supported in the `"item"` property. However, unlike the suffix form, `"data"` can accept Molang. The Molang here is evaluated once on world load, not per-crafting attempt. Variables cannot be used to pass data between properties in a recipe. Furthermore, the nature of input items cannot be queried. Currently, the only known usable query in the `"data"` property is `q.get_actor_info_id`, used to look up the ID of an entity's spawn egg by its identifier:
|
||||
必填的`"item"`属性功能同字符串引用。虽然提供了独立的数据字段，但`"item"`属性仍支持数据值后缀格式。不同于后缀形式，`"data"`可接受Molang表达式（该表达式仅在世界加载时计算一次，而非每次合成时计算）。无法通过变量在配方属性间传递数据。目前已知`"data"`属性中唯一可用的查询是`q.get_actor_info_id`，用于通过实体标识符获取其刷怪蛋ID：
|
||||
|
||||
<CodeHeader>#/minecraft:recipe_shapeless/result</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/minecraft:recipe_shapeless/result]
|
||||
{
|
||||
"item": "minecraft:spawn_egg",
|
||||
"data": "q.get_actor_info_id('minecraft:chicken')"
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
The optional integer `"count"` property may be used to stack items. It defaults to `1`. Currently, setting the count only functions in [crafting](#crafting) and [furnace](#heating) recipe outputs and [shapeless recipe ingredients](#ingredients). A provided count is ignored in other locations.
|
||||
可选的整数`"count"`属性用于堆叠物品，默认为`1`。当前仅在[合成](#合成)与[熔炼](#加热)配方输出及[无序配方原料](#原料)中有效，其他场景下会被忽略。
|
||||
|
||||
::: tip NOTE
|
||||
If a count greater than `1` is provided for an item that does not stack, an error will be thrown. There is no way to force single-return recipe outputs, like those in shapeless recipes or brewing mixes, to return multiple items in one transaction.
|
||||
::: tip 注意
|
||||
若对不可堆叠物品设置数量大于`1`，将抛出错误。无法强制单次返回多个合成输出（如无序配方或酿造混合产物）。
|
||||
:::
|
||||
|
||||
::: warning
|
||||
Despite having similarities to trade [table item descriptors](/wiki/loot/trade-tables#items), recipe item descriptors cannot use functions.
|
||||
尽管与交易[表物品描述符](/wiki/loot/trade-tables#items)相似，配方物品描述符不能使用函数。
|
||||
:::
|
||||
|
||||
#### Identifier Additions
|
||||
#### 特殊标识符
|
||||
|
||||
Additional identifiers not typically usable are available to recipes to describe basic potions.
|
||||
配方系统额外支持描述基础药水的特殊标识符。
|
||||
|
||||
<CodeHeader>#/minecraft:recipe_brewing_mix/input</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/minecraft:recipe_brewing_mix/input]
|
||||
"minecraft:potion_type:strength"
|
||||
```
|
||||
:::
|
||||
|
||||
These identifiers are not usable in the object notation, only the string notation. Variants are unavailable for splash and lingering potions. All such identifiers follow the format: <code>minecraft:potion_type:<em>potion_effect</em></code>, where <code><em>potion_effect</em></code> can be one of the following:
|
||||
这些标识符仅支持字符串格式，不支持对象格式，且无喷溅/滞留药水变种。所有此类标识符遵循格式：<code>minecraft:potion_type:<em>药水效果</em></code>，其中<code><em>药水效果</em></code>可为以下之一：
|
||||
|
||||
- `water`
|
||||
- `awkward`
|
||||
- `mundane`
|
||||
- `thick`
|
||||
- `healing`
|
||||
- `regeneration`
|
||||
- `swiftness`
|
||||
- `strength`
|
||||
- `harming`
|
||||
- `poison`
|
||||
- `slowness`
|
||||
- `weakness`
|
||||
- `water_breathing`
|
||||
- `fire_resistance`
|
||||
- `nightvision`
|
||||
- `invisibility`
|
||||
- `leaping`
|
||||
- `slow_falling`
|
||||
- `turtle_master`
|
||||
- `wither`
|
||||
- `water`（水）
|
||||
- `awkward`（粗制的）
|
||||
- `mundane`（平凡的）
|
||||
- `thick`（浓稠的）
|
||||
- `healing`（治疗）
|
||||
- `regeneration`（再生）
|
||||
- `swiftness`（迅捷）
|
||||
- `strength`（力量）
|
||||
- `harming`（伤害）
|
||||
- `poison`（剧毒）
|
||||
- `slowness`（缓慢）
|
||||
- `weakness`（虚弱）
|
||||
- `water_breathing`（水下呼吸）
|
||||
- `fire_resistance`（抗火）
|
||||
- `nightvision`（夜视）
|
||||
- `invisibility`（隐身）
|
||||
- `leaping`（跳跃）
|
||||
- `slow_falling`（缓降）
|
||||
- `turtle_master`（神龟）
|
||||
- `wither`（衰变）
|
||||
|
||||
Where supported, `long_` and `strong_` prefixes may be used to designate modified potions, such as `minecraft:potion_type:strong_poison`.
|
||||
支持添加`long_`和`strong_`前缀表示强化药水，如`minecraft:potion_type:strong_poison`。
|
||||
|
||||
## Crafting
|
||||
## 合成系统
|
||||
|
||||
Crafting operations instantly transform inputs to outputs using crafting grids. Two crafting recipe types are available: [shapeless recipes](#shapeless-recipes), whose inputs may be arranged in any way, and [shaped recipes](#shaped-recipes), used to define strict arrangements of inputs.
|
||||
Crafting recipes support both crafting tables and stonecutters:
|
||||
合成操作通过合成网格即时转换物品。支持两种配方类型：[无序配方](#无序配方)（原料可任意排列）和[有序配方](#有序配方)（需严格排列原料）。
|
||||
合成配方同时支持工作台和切石机：
|
||||
|
||||
<CodeHeader>#/minecraft:recipe_shapeless/</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/minecraft:recipe_shapeless/]
|
||||
"tags": ["crafting_table", "stonecutter"]
|
||||
```
|
||||
:::
|
||||
|
||||
`"crafting_table"` applies to both vanilla crafting tables and the player 2 × 2 crafting grid in their inventory. There is currently no way to opt into one but not the other. Crafting recipes additionally support custom tags, linking recipes to a [crafting grid provided by a custom block](/wiki/blocks/block-components#crafting-table).
|
||||
`"crafting_table"`同时适用于原版工作台和玩家物品栏中的2×2合成网格，当前无法单独启用其中一种。合成配方还支持自定义标签，可将配方关联到[自定义方块提供的合成网格](/wiki/blocks/block-components#crafting-table)。
|
||||
|
||||
### Shapeless Recipes
|
||||
### 无序配方
|
||||
|
||||
Shapeless recipes simply bind a collection of inputs to a single output on a crafting grid.
|
||||
无序配方将原料集合与单个输出简单绑定。
|
||||
|
||||
|
||||
|
||||
<CodeHeader>BP/recipes/decorations/knobs/brass.json</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [BP/recipes/decorations/knobs/brass.json]
|
||||
{
|
||||
"format_version": "1.17.41",
|
||||
"minecraft:recipe_shapeless": {
|
||||
@@ -316,13 +326,14 @@ Shapeless recipes simply bind a collection of inputs to a single output on a cra
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
#### Ingredients
|
||||
#### 原料配置
|
||||
|
||||
The required `"ingredients"` array property lists the items required as inputs for the crafting recipe.
|
||||
必填的`"ingredients"`数组列出了合成所需的原料物品。
|
||||
|
||||
<CodeHeader>#/minecraft:recipe_shapeless/</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/minecraft:recipe_shapeless/]
|
||||
"ingredients": [
|
||||
"wiki:brass",
|
||||
{
|
||||
@@ -331,29 +342,31 @@ The required `"ingredients"` array property lists the items required as inputs f
|
||||
}
|
||||
]
|
||||
```
|
||||
:::
|
||||
|
||||
Each entry is an [item descriptor](#item-descriptors). If an ingredient provides a count, that count must be expressed across multiple crafting grid slots. Using stacked items in a single grid slot to yield a product is unsupported. If the items required for crafting are available but the count of ingredients is greater than the crafting interface being used supports, the recipe will automatically be made unavailable in the recipe book.
|
||||
每项均为[物品描述符](#物品描述符)。若原料设置了数量，该数量必须通过多个合成网格槽位实现（单个槽位堆叠物品无法用于合成）。当所需物品存在但原料数量超过当前合成界面容量时，配方书会自动将该配方标记为不可用。
|
||||
|
||||
#### Shapeless Results
|
||||
#### 无序配方输出
|
||||
|
||||
Shapeless recipe outputs are expressed using the required `"result"` property and may be expressed as either an [item descriptor](#item-descriptors) or an array of a single item descriptor.
|
||||
通过必填的`"result"`属性声明输出，可以是[物品描述符](#物品描述符)或单物品描述符的数组。
|
||||
|
||||
<CodeHeader>#/minecraft:recipe_shapeless/</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/minecraft:recipe_shapeless/]
|
||||
"result": {
|
||||
"item": "wiki:door_knob",
|
||||
"data": 3
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
### Shaped Recipes
|
||||
### 有序配方
|
||||
|
||||
Shaped recipes enforce that the ingredients used during crafting conform to a strict shape.
|
||||
有序配方要求原料必须按特定图案排列。
|
||||
|
||||
|
||||
|
||||
<CodeHeader>BP/recipes/covered_arch.json</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [BP/recipes/covered_arch.json]
|
||||
{
|
||||
"format_version": "1.17.41",
|
||||
"minecraft:recipe_shaped": {
|
||||
@@ -385,7 +398,6 @@ Shaped recipes enforce that the ingredients used during crafting conform to a st
|
||||
"result": [
|
||||
{
|
||||
"item": "wiki:covered_arch",
|
||||
|
||||
"count": 3
|
||||
},
|
||||
"wiki:crafting_scrap"
|
||||
@@ -393,70 +405,75 @@ Shaped recipes enforce that the ingredients used during crafting conform to a st
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
#### Patterns
|
||||
#### 图案定义
|
||||
|
||||
The required `"pattern"` array property establishes the shape used for the recipe.
|
||||
必填的`"pattern"`数组属性用于建立配方图案。
|
||||
|
||||
<CodeHeader>#/minecraft:recipe_shaped/</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/minecraft:recipe_shaped/]
|
||||
"pattern": [
|
||||
"SSS",
|
||||
"I I",
|
||||
"I I"
|
||||
]
|
||||
```
|
||||
|
||||
Each entry in the array is a string representing a row in the crafting grid. Each character in each string represents a slot within that row. Spaces by default represent slots that should be empty.
|
||||
|
||||
Characters act as a shorthand to visually describe an item. Each distinct character is matched with a [key](#keys) that dictates what item should be present in that slot.
|
||||
|
||||
::: tip
|
||||
If the pattern is only comprised of spaces, empty crafting interfaces able to fit that pattern's size will constantly match the recipe. A player may retrieve an infinite amount of the crafting output, including immediately filling their inventory to the limit upon shift-retrieving the result.
|
||||
:::
|
||||
|
||||
##### Row Normalization
|
||||
数组每项代表合成网格的一行，字符串每个字符代表该行的槽位。默认空格表示该槽位需留空。
|
||||
|
||||
The pattern grid must be at most 3 × 3 but may be smaller. If string lengths are mismatched, Minecraft will automatically extend shorter strings, implying spaces in filled slots. The following two are equivalent:
|
||||
字符作为物品的视觉简写，每个独特字符需与[键定义](#键定义)匹配以指定对应槽位的物品。
|
||||
|
||||
<CodeHeader>#/minecraft:recipe_shaped/</CodeHeader>
|
||||
```json
|
||||
::: tip
|
||||
若图案全由空格组成，任何能容纳该图案尺寸的空合成界面都会持续匹配该配方。玩家可无限获取输出物品，包括通过Shift键一次性填满背包。
|
||||
:::
|
||||
|
||||
##### 行标准化
|
||||
|
||||
图案网格最大为3×3，可更小。若字符串长度不一致，Minecraft会自动补全较短字符串（用空格填充空缺槽位）。以下两组定义等效：
|
||||
|
||||
::: code-group
|
||||
```json [#/minecraft:recipe_shaped/]
|
||||
"pattern": [
|
||||
"MA",
|
||||
"IFI",
|
||||
"M"
|
||||
]
|
||||
```
|
||||
:::
|
||||
|
||||
<CodeHeader>#/minecraft:recipe_shaped/</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/minecraft:recipe_shaped/]
|
||||
"pattern": [
|
||||
"MA ",
|
||||
"IFI",
|
||||
"M "
|
||||
]
|
||||
```
|
||||
|
||||
::: tip NOTE
|
||||
Currently, no crafting grids, including those configurable from custom blocks, may be larger than 3 × 3. If the expressed pattern is unusable within the current crafting interface, the recipe will automatically be unavailable in the recipe book.
|
||||
:::
|
||||
|
||||
##### Grid Freedom
|
||||
::: tip 注意
|
||||
当前所有合成网格（包括自定义方块配置的）最大不超过3×3。若图案超出当前合成界面容量，配方书会自动将其标记为不可用。
|
||||
:::
|
||||
|
||||
Spaces are not automatically implied to fill in any remaining slots in the 3 × 3 space. If a provided pattern is smaller than the crafting grid being used, the pattern can be used anywhere so long as the structure and contents are maintained. As an example, consider the following pattern on a crafting table:
|
||||
##### 网格自由度
|
||||
|
||||
<CodeHeader>#/minecraft:recipe_shaped/</CodeHeader>
|
||||
```json
|
||||
空格不会自动填充3×3网格的剩余槽位。若提供的图案小于当前合成网格，只要保持结构和内容，图案可在网格任意位置使用。例如以下图案在工作台上的表现：
|
||||
|
||||
::: code-group
|
||||
```json [#/minecraft:recipe_shaped/]
|
||||
"pattern": [
|
||||
"O"
|
||||
"OO"
|
||||
]
|
||||
```
|
||||
:::
|
||||
|
||||
The "L" shape isn't restricted to the upper-left corner of the crafting grid. Using a 3 × 3 grid as an example, the pattern would be usable with any of these configurations:
|
||||
"L"形图案不限左上角位置，在3×3网格中可能配置如下：
|
||||
|
||||
<Spoiler title="Possible Configurations">
|
||||
*Underscores represent empty slots.*
|
||||
<Spoiler title="可能的配置">
|
||||
*下划线代表空槽位*
|
||||
```txt
|
||||
O__
|
||||
OO_
|
||||
@@ -479,87 +496,91 @@ _OO
|
||||
```
|
||||
</Spoiler>
|
||||
|
||||
To restrict placements to a particular location, use explicit spaces, which enforce empty slots in certain locations. The following is only usable in the upper-left corner of a grid:
|
||||
要限制位置需显式使用空格强制某些槽位留空。以下图案仅能在网格左上角使用：
|
||||
|
||||
<CodeHeader>#/minecraft:recipe_shaped/</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/minecraft:recipe_shaped/]
|
||||
"pattern": [
|
||||
"O "
|
||||
"OO "
|
||||
" "
|
||||
]
|
||||
```
|
||||
:::
|
||||
|
||||
##### Symmetry
|
||||
##### 对称性
|
||||
|
||||
All shaped recipes are innately horizontally symmetric:
|
||||
所有有序配方默认具有水平对称性：
|
||||
|
||||
<CodeHeader>#/minecraft:recipe_shaped/</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/minecraft:recipe_shaped/]
|
||||
"pattern": [
|
||||
"Z "
|
||||
" Z "
|
||||
" Z"
|
||||
]
|
||||
```
|
||||
:::
|
||||
|
||||
The preceding recipe may also be used by a player as though it were set to:
|
||||
该配方也可被玩家视为以下形式使用：
|
||||
|
||||
<CodeHeader>#/minecraft:recipe_shaped/</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/minecraft:recipe_shaped/]
|
||||
"pattern": [
|
||||
" Z"
|
||||
" Z "
|
||||
"Z "
|
||||
]
|
||||
```
|
||||
:::
|
||||
|
||||
#### Keys
|
||||
#### 键定义
|
||||
|
||||
Keys provide meaning to characters in a [pattern](#patterns), done via the required `"key"` object property, which maps key names to [item descriptors](#item-descriptors).
|
||||
通过必填的`"key"`对象属性将图案字符映射到[物品描述符](#物品描述符)。
|
||||
|
||||
<CodeHeader>#/minecraft:recipe_shaped/</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/minecraft:recipe_shaped/]
|
||||
"key": {
|
||||
"S": "wiki:cloth",
|
||||
"I": "wiki:support"
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
Every key present in the pattern should be accounted for here. Keys names are case-sensitive. If an item supports multiple data values and no data value is provided, any item of that identifier will be usable for that key. Any `"count"` property present in an item descriptor is ignored and regarded as `1`; stacked items in a crafting grid slot are only consumable one at a time.
|
||||
图案中每个字符都需在此定义。键名区分大小写。若物品支持多数据值且未指定数据值，该标识符下任意数据值的物品都可用于该键。物品描述符中的`"count"`属性会被忽略并视为`1`；合成网格槽位中的堆叠物品每次仅消耗一个。
|
||||
|
||||
::: tip NOTE
|
||||
Any unicode character from `U+0020` to `U+07FF` may be used as a key name. If a key name has more than one character, only the first character is considered. Since spaces are by default used to signify empty slots on a grid and there's no way to re-designate a key for a blank slot, it's not recommended to use them as a key.
|
||||
::: tip 注意
|
||||
可使用`U+0020`到`U+07FF`间的任意Unicode字符作为键名。若键名超过一个字符，仅首字符有效。由于空格默认表示网格空槽且无法重新定义，不建议将其作为键。
|
||||
:::
|
||||
|
||||
::: warning
|
||||
If a character in the pattern is not present in the key map, it will be treated as though it were a space, a designated empty tile.
|
||||
若图案字符未在键映射中定义，将被视为空格（空槽位）。
|
||||
:::
|
||||
|
||||
### Recipe Unlocking
|
||||
Minecraft 1.20.30 added recipe unlocking to the game. In order to have your recipes use this function, you `manifest.json` must have a `min_engine_version` of 1.20.11 (1.20.30 is recommender). You also need to add the `unlock` array with its objects to your recipe.
|
||||
### 配方解锁
|
||||
Minecraft 1.20.30新增配方解锁功能。要使用此功能，需确保`manifest.json`中的`min_engine_version`至少为1.20.11（推荐1.20.30），并在配方中添加`unlock`数组：
|
||||
```json
|
||||
"unlock": [
|
||||
{
|
||||
"item": "wiki:cold_steel" //item to unlock recipe
|
||||
"item": "wiki:cold_steel" //解锁配方所需物品
|
||||
},
|
||||
{
|
||||
"item": "minecraft:wool", //item to unlock recipe
|
||||
"item": "minecraft:wool", //解锁配方所需物品
|
||||
"data": 3
|
||||
},
|
||||
{
|
||||
"context": "PlayerInWater" //event to unlock recipe
|
||||
"context": "PlayerInWater" //解锁配方所需事件
|
||||
}
|
||||
]
|
||||
```
|
||||
Each object in this array contains `"item"` and this tells the recipe what item the player needs in their inventory in order for this recipe to be unlocked. `"context"` is used to determine what event unlocks this recipe. `"PlayerInWater"` will unlock this recipe when the player enters water. This is also the only known context for recipes.
|
||||
数组中每个对象的`"item"`字段表示玩家背包中需要存在的物品。`"context"`字段表示触发解锁的事件，目前仅知`"PlayerInWater"`会在玩家入水时解锁配方。
|
||||
|
||||
#### Shaped Results
|
||||
#### 有序配方输出
|
||||
|
||||
Shaped crafting recipe outputs behave very similarly to their [shapeless counterparts](#shapeless-results). Unlike array results for shapeless recipes, however, shaped recipe result arrays may contain more than one [item descriptor](#item-descriptors).
|
||||
有序配方输出行为与[无序配方](#无序配方输出)相似。不同于无序配方的是，有序配方的输出数组可包含多个[物品描述符](#物品描述符)。
|
||||
|
||||
<CodeHeader>#/minecraft:recipe_shaped/</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/minecraft:recipe_shaped/]
|
||||
"result": [
|
||||
{
|
||||
"item": "wiki:covered_arch",
|
||||
@@ -568,56 +589,59 @@ Shaped crafting recipe outputs behave very similarly to their [shapeless counter
|
||||
"wiki:crafting_scrap"
|
||||
]
|
||||
```
|
||||
The first entry in the array will be used as the visible output of the crafting block. All other values are automatically placed in the player's inventory upon removing the visible result from the output slot. There does not seem to be a limit on the number of items that may be returned from a crafting action.
|
||||
|
||||
::: tip NOTE
|
||||
Any items not able to fit in the player's inventory are instead placed in the input slots of the crafting table left-to-right and then top-to-bottom. Anything not able to fit there is then thrown from the player as though they had used the "Drop Item" action.
|
||||
:::
|
||||
|
||||
### Recipe Book
|
||||
数组首项将作为合成方块的可见输出，其余项会在玩家取走可见输出后自动放入背包。目前似乎没有对单次合成返回物品数量的限制。
|
||||
|
||||
The recipe book automatically indexes and displays available recipes to the player, intelligently accounting for [ingredient counts](#ingredients) in shapeless recipes or [pattern constraints](#patterns) in shaped recipes. When multiple recipes point to the same output, the recipe book uses its own unique prioritization system.
|
||||
::: tip 注意
|
||||
无法放入背包的物品会按从左到右、从上到下的顺序放回合成输入槽。若仍无法容纳，则会像玩家执行"丢弃物品"操作一样抛出。
|
||||
:::
|
||||
|
||||
When both recipes being compared are shapeless recipes, the following rules determine prioritization in order:
|
||||
### 配方书
|
||||
|
||||
- Lower ingredient count of the _first_ listed ingredient
|
||||
- More negative [priority](#priority)
|
||||
- Lower-valued identifier string
|
||||
配方书自动索引并显示可用配方，智能考虑无序配方的[原料数量](#原料配置)或有序配方的[图案限制](#图案定义)。当多个配方指向相同输出时，配方书使用独特优先级系统。
|
||||
|
||||
For shaped recipes, recipes with "lesser" identifiers, when compared as strings, are always prioritized.
|
||||
比较两个无序配方时，按以下顺序确定优先级：
|
||||
1. 第一个列出原料的较低数量
|
||||
2. 更小的[优先级值](#优先级)
|
||||
3. 字典序较小的标识符字符串
|
||||
|
||||
When comparing a shaped recipe to a shapeless recipe, the rules for comparing shapeless recipes are used; however, the interpreted count of ingredients for the shaped recipe is different from its actual ingredient count. Exactly how the ingredient count for a shaped recipe is determined is unknown.
|
||||
对于有序配方，字典序较小的标识符始终优先。
|
||||
|
||||
### Grouping
|
||||
比较有序与无序配方时，使用无序配方规则，但有序配方的原料数量计算方式不同（具体机制未知）。
|
||||
|
||||
This section is included informatively. Groups are present in crafting recipes in vanilla definitions, given with the optional `"group"` string property.
|
||||
### 分组系统
|
||||
|
||||
<CodeHeader>#/minecraft:recipe_shaped/</CodeHeader>
|
||||
```json
|
||||
本节为信息性说明。原版定义中的合成配方包含可选的`"group"`字符串属性。
|
||||
|
||||
::: code-group
|
||||
```json [#/minecraft:recipe_shaped/]
|
||||
"group": "slingshots"
|
||||
```
|
||||
:::
|
||||
|
||||
It is currently unknown what, if anything, this property achieves. Presumably, it would be used with the [recipe book](#recipe-book). Neither using new custom groups nor reusing groups from vanilla definitions appear to achieve anything.
|
||||
目前未知该属性的具体作用（推测与[配方书](#配方书)相关）。使用自定义分组或复用原版分组均未观察到实际效果。
|
||||
|
||||
### Priority
|
||||
### 优先级
|
||||
|
||||
Crafting recipes support an additional property for handling input collisions, `"priority"`, which primarily acts as a [tiebreaker](#prioritization) when multiple recipes could possibly apply to the given situation. Priorities are provided directly within the crafting recipe type object.
|
||||
合成配方支持额外的`"priority"`属性处理输入冲突，主要在[优先级排序](#优先级排序)时作为决胜条件。
|
||||
|
||||
<CodeHeader>#/minecraft:recipe_shaped/</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/minecraft:recipe_shaped/]
|
||||
"priority": 2
|
||||
```
|
||||
:::
|
||||
|
||||
Crafting recipes with lower priority values take precedence. So, if all else is equal, a recipe with a priority of `0` would be used over a recipe with priority `1`. Priorities may be negative if necessary. If `"priority"` is not provided, a priority of `0` is implied.
|
||||
数值较小的配方优先级更高（如优先级`0`优于`1`）。支持负值，未提供时默认为`0`。
|
||||
|
||||
## Heating
|
||||
## 加热系统
|
||||
|
||||
Furnace recipes are used to transform an item using a heat source over a period of time. A slight misnomer, furnace recipes are used with any interface that involves a heat source, including campfires.
|
||||
熔炉配方通过热源随时间转换物品。虽然名称局限，实际适用于所有热源界面（包括营火）。
|
||||
|
||||
|
||||
|
||||
<CodeHeader>BP/recipes/magic/magic_ash.json</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [BP/recipes/magic/magic_ash.json]
|
||||
{
|
||||
"format_version": "1.17.41",
|
||||
"minecraft:recipe_furnace": {
|
||||
@@ -633,71 +657,76 @@ Furnace recipes are used to transform an item using a heat source over a period
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
All vanilla heating blocks are supported via tags.
|
||||
支持所有原版加热方块的标签：
|
||||
|
||||
<CodeHeader>#/minecraft:recipe_furnace/</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/minecraft:recipe_furnace/]
|
||||
"tags": ["furnace", "blast_furnace", "smoker", "campfire", "soul_campfire"]
|
||||
```
|
||||
:::
|
||||
|
||||
### Heating Transactions
|
||||
### 加热转换
|
||||
|
||||
Furnace recipes bind exactly one input [item descriptor](#item-descriptors) to exactly one output item descriptor.
|
||||
熔炉配方将单个输入[物品描述符](#物品描述符)绑定到单个输出物品描述符。
|
||||
|
||||
<CodeHeader>#/minecraft:recipe_furnace/</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/minecraft:recipe_furnace/]
|
||||
"input": "wiki:bone_fragments"
|
||||
"output": {
|
||||
"item": "wiki:magic_ash",
|
||||
"count": 4
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
Any count given in the input is ignored. XP returns and fuel sources for a cooking and smelting recipe cannot be altered. The time required to heat an item is set by the used block and is unchangeable.
|
||||
输入中的数量值会被忽略。无法修改经验返还和燃料设定，加热时间由使用的方块决定且不可更改。
|
||||
|
||||
## Brewing
|
||||
## 酿造系统
|
||||
|
||||
Brewing recipes are used to transform an item using another item as a catalyst. Two brewing recipe types are available: [brewing mixes](#brewing-mixes), which do not transition data from input to output, and [brewing containers](#brewing-containers), which do.
|
||||
酿造配方通过催化剂物品转换另一物品。支持两种类型：[酿造混合](#酿造混合)（不传递输入输出数据）和[酿造容器](#酿造容器)（传递数据）。
|
||||
|
||||
Only one interface supports brewing recipes:
|
||||
仅一种界面支持酿造配方：
|
||||
|
||||
<CodeHeader>#/minecraft:recipe_brewing_container/</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/minecraft:recipe_brewing_container/]
|
||||
"tags": ["brewing_stand"]
|
||||
```
|
||||
:::
|
||||
|
||||
### Brewing Transactions
|
||||
### 酿造转换
|
||||
|
||||
Brewing transactions are similar to [heating transactions](#heating-transactions), requiring an input and output, each pointing to a single [item descriptor](#item-descriptors). Brewing recipes, however, also require the `"reagent"` property as a catalyst, which also can only point to a single item descriptor.
|
||||
酿造转换类似[加热转换](#加热转换)，需要输入和输出各一个[物品描述符](#物品描述符)。此外还需`"reagent"`属性作为催化剂（也仅接受单个物品描述符）。
|
||||
|
||||
<CodeHeader>#/minecraft:recipe_brewing_mix/</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/minecraft:recipe_brewing_mix/]
|
||||
"input": "wiki:flask",
|
||||
"reagent": "wiki:jade",
|
||||
"output": "wiki:insanity_resistance"
|
||||
```
|
||||
|
||||
Provided count values are ignored in these brewing properties. Items are meant to transform one at a time in a brew.
|
||||
|
||||
::: warning
|
||||
If the input item for a brewing recipe has the ability to stack, the _entire_ stack will be consumed in the transformation. There are currently no workarounds to avoid this.
|
||||
:::
|
||||
|
||||
After the brewing time has passed, the catalyst is consumed, and output items directly replace input items.
|
||||
这些属性中的数量值会被忽略，物品每次转换一个。
|
||||
|
||||
::: warning
|
||||
Currently, the stackability of the produced output is bugged, regardless of whether a data value was specified. In particular, the output is incompatible and will not stack with items of the same identifier and data value.
|
||||
若酿造配方的输入物品可堆叠，将消耗整个堆叠。目前无法避免此行为。
|
||||
:::
|
||||
|
||||
### Brewing Mixes
|
||||
酿造完成后催化剂被消耗，输出物品直接替换输入物品。
|
||||
|
||||
Brewing mixes are simple brewing recipes theoretically designed to isolate the data value of the input from the data value of the output.
|
||||
::: warning
|
||||
当前无论是否指定数据值，产出物品的堆叠都存在bug，无法与相同标识符和数据值的物品堆叠。
|
||||
:::
|
||||
|
||||
### 酿造混合
|
||||
|
||||
酿造混合是简单的酿造配方，理论上设计用于隔离输入输出的数据值。
|
||||
|
||||
|
||||
|
||||
<CodeHeader>BP/recipes/brewing/negative/paralysis.json</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [BP/recipes/brewing/negative/paralysis.json]
|
||||
{
|
||||
"format_version": "1.17.41",
|
||||
"minecraft:recipe_brewing_mix": {
|
||||
@@ -711,28 +740,28 @@ Brewing mixes are simple brewing recipes theoretically designed to isolate the d
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
::: warning
|
||||
Unfortunately, assigned data values are broken for brewing mix recipes.
|
||||
|
||||
In general, a brewing recipe will never work if a data value is supplied to the input. The only exceptions are if the input is one of the following:
|
||||
|
||||
- `minecraft:potion`
|
||||
- `minecraft:splash_potion`
|
||||
- `minecraft:lingering_potion`
|
||||
- [Potion identifier additions](#identifier-additions)
|
||||
|
||||
If a data value is specified for a reagent using the `"data"` property format, a brew occurs when any item with the given identifier is placed as a reagent for that recipe, regardless of data value. However, the brew only succeeds if the correct data value is matched. If it’s not, the brew will appear to succeed, but the input will not be transformed into the output; despite the brew failing, the reagent and a percentage of the blaze powder fuel are consumed anyway.
|
||||
:::
|
||||
|
||||
### Brewing Containers
|
||||
::: warning
|
||||
不幸的是，酿造混合配方的数据值设定存在缺陷。
|
||||
|
||||
Brewing containers are designed to pass the data value of an input to the transformed output.
|
||||
通常，若对输入指定数据值，酿造配方将完全失效。例外情况是输入为以下之一：
|
||||
- `minecraft:potion`
|
||||
- `minecraft:splash_potion`
|
||||
- `minecraft:lingering_potion`
|
||||
- [药水特殊标识符](#特殊标识符)
|
||||
|
||||
若通过`"data"`属性为催化剂指定数据值，当酿造台放入该标识符物品时会触发酿造（无论数据值是否匹配）。但只有数据值正确时才会成功转换，否则看似成功实则不转换输入（但仍会消耗催化剂和部分烈焰粉燃料）。
|
||||
:::
|
||||
|
||||
### 酿造容器
|
||||
|
||||
酿造容器设计用于将输入数据值传递到输出。
|
||||
|
||||
|
||||
|
||||
<CodeHeader>BP/recipes/illumination_potion.json</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [BP/recipes/illumination_potion.json]
|
||||
{
|
||||
"format_version": "1.17.41",
|
||||
"minecraft:recipe_brewing_container": {
|
||||
@@ -746,33 +775,32 @@ Brewing containers are designed to pass the data value of an input to the transf
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Brewing containers are stricter than [brewing mixes](#brewing-mixes) about their inputs. Only the following item types are allowed in a brewing container recipe:
|
||||
|
||||
- `minecraft:potion`
|
||||
- `minecraft:splash_potion`
|
||||
- `minecraft:lingering_potion`
|
||||
- [Potion identifier additions](#identifier-additions)
|
||||
|
||||
Because the data value is carried downstream from input to output in a brewing container recipe, assigned data values in `"input"` and `"output"` are ignored.
|
||||
|
||||
## Overrides
|
||||
|
||||
As with all domains in add-ons, the pack order in the behavior pack list affects how Minecraft chooses files to use during gameplay. Higher-listed behavior pack entries take priority over lower-listed ones, including the base vanilla pack.
|
||||
|
||||
To override a recipe in a lower-listed pack, the recipe type and identifiers must both match. The override file can be named and located in any way — only the contents matter. Partial overrides are not accepted in recipes; the entire recipe must be redefined.
|
||||
|
||||
::: warning
|
||||
Overrides only work if the recipe type is an _exact_ match. In most cases, a mismatch results in a new recipe created alongside the existing one.
|
||||
|
||||
If attempting to construct an override that converts between the two crafting recipe types, an error will be thrown. To circumvent this, first copy the vanilla definition into the pack. Next, set the `"tags"` for that file to `[""]`; this effectively disables the recipe. Finally, set up a new file as the other crafting recipe type, choosing a different identifier to avoid the error.
|
||||
:::
|
||||
|
||||
## Prioritization
|
||||
比[酿造混合](#酿造混合)更严格，仅允许以下输入类型：
|
||||
- `minecraft:potion`
|
||||
- `minecraft:splash_potion`
|
||||
- `minecraft:lingering_potion`
|
||||
- [药水特殊标识符](#特殊标识符)
|
||||
|
||||
After considering [overrides](#overrides), if multiple recipes would apply based on the inputs, the outputs are selected using the following tiebreakers, considered in order:
|
||||
由于数据值从输入传递到输出，`"input"`和`"output"`中指定的数据值会被忽略。
|
||||
|
||||
- Recipes declared in higher-ordered packs in the world behavior packs list
|
||||
- If for crafting recipes, _lower_-valued [priority properties](#priority)
|
||||
- If for crafting recipes, [shaped recipes](#shaped-recipes) over [shapeless ones](#shapeless-recipes)
|
||||
- "Lesser" identifiers, as interpreted by string comparison
|
||||
## 覆盖机制
|
||||
|
||||
与所有附加组件领域相同，行为包加载顺序影响游戏中选择的文件。列表中靠前的行为包会覆盖靠后的（包括原版基础包）。
|
||||
|
||||
要覆盖低优先级包的配方，需完全匹配配方类型和标识符。覆盖文件可任意命名存放——仅内容重要。配方不支持部分覆盖，必须完全重新定义。
|
||||
|
||||
::: warning
|
||||
仅当配方类型完全匹配时覆盖才生效。多数情况下不匹配会导致新建配方而非覆盖。
|
||||
|
||||
若尝试在两种合成配方类型间转换覆盖，将抛出错误。解决方案：先复制原版定义到包中，将其`"tags"`设为`[""]`（禁用配方），再新建另一种类型的配方文件（使用不同标识符避免冲突）。
|
||||
:::
|
||||
|
||||
## 优先级排序
|
||||
|
||||
考虑[覆盖机制](#覆盖机制)后，若多个配方匹配输入，按以下顺序决胜：
|
||||
1. 行为包列表中更高优先级的包
|
||||
2. 合成配方中更小的[优先级值](#优先级)
|
||||
3. 合成配方中[有序配方](#有序配方)优于[无序配方](#无序配方)
|
||||
4. 字典序较小的标识符字符串
|
||||
@@ -1,28 +1,32 @@
|
||||
---
|
||||
title: Trade Tables
|
||||
category: Documentation
|
||||
title: 交易表
|
||||
category: 文档
|
||||
nav_order: 2
|
||||
tags:
|
||||
- Stable
|
||||
- Last updated for Version 1.18.10
|
||||
- 稳定版
|
||||
- 最后更新于版本1.18.10
|
||||
mentions:
|
||||
- Ciosciaa
|
||||
- SirLich
|
||||
- TheItsNameless
|
||||
---
|
||||
|
||||
Trade tables represent the fundamental data behind trading item transactions for an entity. Trade tables are not standalone; they must be referenced from an [entity component](https://bedrock.dev/docs/stable/Entities#minecraft%3Aeconomy_trade_table). Using the randomizing properties available to trade tables, trade offers, item counts, and cost calculations may vary across entity instances, even if all would point to the same trade table.
|
||||
# 交易表
|
||||
|
||||
<!--@include: @/wiki/bedrock-wiki-mirror.md-->
|
||||
|
||||
交易表是实体进行物品交易的基础数据载体。交易表不能独立使用，必须通过[实体组件](https://bedrock.dev/docs/stable/Entities#minecraft%3Aeconomy_trade_table)引用。利用交易表提供的随机化特性，即使多个实体实例引用同一交易表，其交易报价、物品数量和成本计算也可能各不相同。
|
||||
|
||||
|
||||
|
||||
Trade tables are not identified or versioned. Like loot tables, trade tables do not support Molang and instead rely on JSON constructs, like range objects and [functions](#functions). Despite being different, trade tables still support comments.
|
||||
交易表没有标识符或版本控制。与战利品表类似，交易表不支持Molang，而是依赖JSON结构（如范围对象和[函数](#functions)）。虽然结构不同，交易表仍支持注释功能。
|
||||
|
||||
## Integration
|
||||
## 集成方式
|
||||
|
||||
Trade tables don't represent a primary add-on system, like blocks or biomes. They aren't registered by being placed in a specific folder; instead, they're referenced (from entities). Trade tables may be placed anywhere within a behavior pack.
|
||||
交易表不属于核心附加系统（如方块或生物群系）。它们不是通过放置在特定文件夹来注册，而是通过实体引用。交易表可以放置在行为包的任何位置。
|
||||
|
||||
::: tip
|
||||
It's recommended to follow vanilla convention and place all trade tables within the top-level `trading` directory in a behavior pack. From there, any hierarchy can be employed.
|
||||
建议遵循原版规范，将所有交易表放在行为包的顶级`trading`目录下。在此目录下可采用任意层级结构。
|
||||
:::
|
||||
|
||||
<FolderView
|
||||
@@ -32,12 +36,12 @@ It's recommended to follow vanilla convention and place all trade tables within
|
||||
]"
|
||||
/>
|
||||
|
||||
The following example is referenced and analyzed throughout the document:
|
||||
下文将通过一个贯穿文档的示例进行分析：
|
||||
|
||||
<Spoiler title="Trade Table File Example">
|
||||
::: details 交易表示例文件
|
||||
|
||||
<CodeHeader>BP/trading/minister.json</CodeHeader>
|
||||
```json
|
||||
::: code-group
|
||||
```json [BP/trading/minister.json]
|
||||
{
|
||||
"tiers": [
|
||||
{
|
||||
@@ -159,15 +163,14 @@ The following example is referenced and analyzed throughout the document:
|
||||
]
|
||||
}
|
||||
```
|
||||
</Spoiler>
|
||||
:::
|
||||
|
||||
## Structure
|
||||
## 结构
|
||||
|
||||
Trade tables are represented as un-versioned, un-namespaced objects.
|
||||
交易表采用无版本、无命名空间的JSON对象结构。
|
||||
|
||||
<CodeHeader>#</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [#]
|
||||
{
|
||||
"tiers": [
|
||||
{
|
||||
@@ -175,204 +178,200 @@ Trade tables are represented as un-versioned, un-namespaced objects.
|
||||
},
|
||||
{
|
||||
"total_exp_required": 28,
|
||||
|
||||
"trades": […]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
Trade tables use [tiers](#tiers) to structure trade organization. Tiers are defined with the required top-level `"tiers"` array property. Tiers appear in order in the trading interface.
|
||||
交易表使用[层级(tiers)](#tiers)来组织交易结构。层级通过顶层的必需数组属性`"tiers"`定义。层级会按照顺序显示在交易界面中。
|
||||
|
||||
### Tiers
|
||||
### 交易层级
|
||||
|
||||
Tiers act as an unlockable set of trades and represent the highest level of grouping in a trade table.
|
||||
层级代表可解锁的交易集合，是交易表中的最高级分组单位。
|
||||
|
||||
<CodeHeader>#/tiers/0</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/tiers/0]
|
||||
{
|
||||
"groups": […]
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
<CodeHeader>#/tiers/1</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/tiers/1]
|
||||
{
|
||||
"total_exp_required": 28,
|
||||
|
||||
"trades": […]
|
||||
}
|
||||
```
|
||||
|
||||
Each tier must either represent a set of [trades](#trades) (as `"trades"`) or [trade groups](#groups) (as `"groups"`); one of these properties is required. If trades are specified, all such trades will appear for that tier. If instead groups are given, trades from all listed groups will be used for that tier; how each group selects its trades depends on its configuration.
|
||||
|
||||
::: tip NOTE
|
||||
If both `"trades"` and `"groups"` are given in a tier, the trades declaration is ignored in favor of groups.
|
||||
:::
|
||||
|
||||
Within a tier, trades appear in order in the trading interface. If trades are grouped, those groups will appear in their defined order as well, organized by group and then by trade. Trades in one group are not visually differentiable from trades in other groups; only tiers are visually separated and identifiable.
|
||||
每个层级必须包含[交易(trades)](#trades)数组（`"trades"`）或[交易组(groups)](#groups)数组（`"groups"`）中的至少一个属性。如果指定交易数组，该层级将显示所有列出的交易。如果指定交易组数组，则根据组配置从所有列出的组中选择交易。
|
||||
|
||||
#### Experience Requirement
|
||||
::: tip 注意
|
||||
如果同时指定`"trades"`和`"groups"`，系统会优先使用groups而忽略trades声明。
|
||||
:::
|
||||
|
||||
Tiers are unlocked when the _trader_ meets experience thresholds. Each trader has its own internal lifetime experience that accumulates when trading with players. The amount of experience obtained per trade depends on that trade's [experience reward](#trader-experience). The optional `"total_exp_required"` property specifies how much experience the trader needs in order for that tier to unlock.
|
||||
在层级内部，交易会按照定义顺序显示。如果交易分组，各组及其内部交易也会按定义顺序组织。不同组的交易在视觉上没有区分，只有层级会进行视觉分隔和标识。
|
||||
|
||||
<CodeHeader>#/tiers/1/</CodeHeader>
|
||||
#### 经验需求
|
||||
|
||||
```json
|
||||
当交易者达到经验阈值时，层级会被解锁。每个交易者有独立的累计经验值，通过与玩家交易获得。每次交易获得的经验量取决于该交易的[交易者经验奖励](#trader-experience)。可选属性`"total_exp_required"`指定交易者解锁该层级所需的总经验值。
|
||||
|
||||
::: code-group
|
||||
```json [#/tiers/1/]
|
||||
"total_exp_required": 28
|
||||
```
|
||||
|
||||
By default, the amount of experience needed is set to the index of the trade tier. Therefore, the second tier would require the trader to have 1 XP; the third tier would require 2 XP; and so forth. The first tier is always unlocked automatically, [regardless of its set experience threshold](#initial-tier-experience).
|
||||
|
||||
#### Tier Unlocking
|
||||
|
||||
Tiers are unlocked in order. When a new tier is unlocked, the subsequent tier is additionally checked to see if its threshold is met by the current XP. If it is, it unlocks and checks its subsequent tier, and so forth. Tier unlocking is checked when the rewarded trader experience would suffice for multiple tiers or if a [provided initial experience](#initial-tier-experience) would unlock subsequent tiers when correctly updated by the game.
|
||||
|
||||
::: tip NOTE
|
||||
Since tiers are checked one-at-a-time, if tier unlocking would stop due to the XP requirements of a tier not being met, no subsequent tiers will be checked, even if those later tiers' XP requirements have been met.
|
||||
:::
|
||||
|
||||
##### Initial Tier Experience
|
||||
默认情况下，所需经验值等于交易层级的索引值。因此第二层需要交易者有1点经验，第三层需要2点，以此类推。[无论设置如何](#initial-tier-experience)，第一层级总是自动解锁。
|
||||
|
||||
Special handling occurs for a non-zero experience threshold in the first tier. If negative, _all_ tiers will be unlocked. If greater than 0, the initial experience of the trader is set to the provided value.
|
||||
#### 层级解锁机制
|
||||
|
||||
层级按顺序解锁。当新层级解锁时，系统会检查后续层级是否满足当前经验值的阈值要求。如果满足则继续解锁后续层级，依此类推。在以下情况会触发层级解锁检查：(1) 获得的交易者经验足以解锁多个层级时；(2) 游戏正确更新后，[提供的初始经验](#initial-tier-experience)可以解锁后续层级时。
|
||||
|
||||
::: tip 注意
|
||||
由于层级是逐个检查的，如果某个层级的经验要求未满足导致解锁中断，即使后续层级的经验要求已满足，也不会继续检查。
|
||||
:::
|
||||
|
||||
##### 初始层级经验
|
||||
|
||||
第一层级的非零经验阈值有特殊处理：如果为负数，将解锁所有层级；如果大于0，交易者的初始经验值将被设为该值。
|
||||
|
||||
::: warning
|
||||
When the initial tier's experience threshold is non-zero, a manual update is required for a trader's trades to reflect the actual nature of their trade table. In these cases, performing a trade or closing and re-opening the trading interface will update the interface correctly. Initially, only the first tier will be available even if other tiers should be unlocked.
|
||||
当第一层级的经验阈值非零时，需要手动更新才能使交易者的交易界面正确反映交易表实际状态。此时需要进行一次交易或关闭再重新打开交易界面才能正确更新界面显示。初始时即使其他层级应该解锁，也只会显示第一层级。
|
||||
:::
|
||||
|
||||
##### Tier Freezing
|
||||
##### 层级冻结
|
||||
|
||||
Excluding the [initial tier](#initial-tier-experience), it's possible to freeze trades at a tier:
|
||||
除[初始层级](#initial-tier-experience)外，可以将交易冻结在某个层级：
|
||||
|
||||
<CodeHeader>Example Tier Freeze</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [示例层级冻结]
|
||||
"total_exp_required": -1
|
||||
```
|
||||
:::
|
||||
|
||||
When its prior tier is unlocked, a tier with a negative XP requirement will immediately unlock, [as expected](#tier-unlocking). However, it will be impossible for the player to progress to any subsequent tiers.
|
||||
当上一层级解锁时，经验要求为负数的层级会立即解锁（[符合预期](#tier-unlocking)），但玩家将无法继续解锁后续任何层级。
|
||||
|
||||
### Trade Groups
|
||||
### 交易组
|
||||
|
||||
Trade groups are a way to randomly select which trades an individual trader should use for a tier.
|
||||
交易组用于随机选择单个交易者在某个层级应该使用的交易。
|
||||
|
||||
<CodeHeader>#/tiers/0/groups/0</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/tiers/0/groups/0]
|
||||
{
|
||||
"num_to_select": 1,
|
||||
|
||||
"trades": […]
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
The trades from which to select are given with the required `"trades"` array; each entry is a [trade](#trades). A select number of these trades, indicated by the optional `"num_to_select"` property, will be picked for that tier for each trader. If `"num_to_select"` is `0`, all trades will be selected; this is the default.
|
||||
通过必需的`"trades"`数组指定候选交易，每个条目都是一个[交易](#trades)。可选属性`"num_to_select"`表示每个交易者实例在该层级选择交易的数量。如果`"num_to_select"`为0（默认值），将选择所有交易。
|
||||
|
||||
::: tip NOTE
|
||||
Trade groups cannot be nested for advanced chance selection.
|
||||
::: tip 注意
|
||||
交易组不支持嵌套以实现高级概率选择。
|
||||
:::
|
||||
|
||||
::: tip
|
||||
Currently, no random selection count is possible. Nor is weighting by trade, but trades can be duplicated within the array to effectively increase their likelihood of being selected.
|
||||
目前无法随机选择数量，也无法按交易设置权重。但可以通过在数组中重复交易条目来有效增加其被选中的概率。
|
||||
:::
|
||||
|
||||
### Trades
|
||||
### 交易
|
||||
|
||||
Trades represent a transaction between a trader and the player.
|
||||
交易代表交易者与玩家之间的物品交换。
|
||||
|
||||
<CodeHeader>#/tiers/0/trades/1</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/tiers/0/trades/1]
|
||||
{
|
||||
"wants": […],
|
||||
"gives": […],
|
||||
"max_uses": 2,
|
||||
|
||||
"reward_exp": false,
|
||||
"trader_exp": 8
|
||||
}
|
||||
```
|
||||
|
||||
Once a trade is picked for a trade slot, it will not fundamentally change. Only the [quantity](#quantity) can be modified in certain situations.
|
||||
|
||||
::: tip
|
||||
Individual trade definitions can affect more than just trades themselves. Notably, an entity can [hold a particular item](https://bedrock.dev/docs/stable/Entities#minecraft%3Abehavior.trade_interest) in response to the player holding an item.
|
||||
:::
|
||||
|
||||
#### Wanted and Given Items
|
||||
一旦交易被选入交易槽，其基本内容不会改变。只有[数量](#quantity)在某些情况下可能被修改。
|
||||
|
||||
The fundamental transactional units are declared using `"wants"` and `"gives"`; players trade with `"wants"` to receive `"gives"`. Both properties must be arrays and are required.
|
||||
::: tip
|
||||
单个交易定义可以影响交易之外的内容。值得注意的是，实体可以[持有特定物品](https://bedrock.dev/docs/stable/Entities#minecraft%3Abehavior.trade_interest)来响应玩家持有的物品。
|
||||
:::
|
||||
|
||||
<CodeHeader>#/tiers/0/trades/1/</CodeHeader>
|
||||
#### 需求与给予物品
|
||||
|
||||
```json
|
||||
基础交易单元通过`"wants"`和`"gives"`声明：玩家用`"wants"`交换`"gives"`。这两个属性都是必需的数组。
|
||||
|
||||
::: code-group
|
||||
```json [#/tiers/0/trades/1/]
|
||||
"wants": […],
|
||||
"gives": […]
|
||||
```
|
||||
|
||||
A trade can have between 1 and 2 wanted entries and must have exactly 1 given entry. Each entry of either array may be either an [item](#items) or a [choice](#choices).
|
||||
|
||||
The trading interface will adapt depending on the number of items wanted. In some circumstances, some trading modifiers, such as [quantity-modifying enchantment functions](#quantity-modifying-enchantment-functions), only affect the first wanted item.
|
||||
|
||||
::: tip NOTE
|
||||
If an object is provided as an entry that contains both item and choice properties, only the choice part is considered; the item parts will be ignored.
|
||||
:::
|
||||
|
||||
#### Trade Limit
|
||||
每笔交易可以有1-2个需求条目，必须有1个给予条目。每个条目可以是[物品](#items)或[选择项](#choices)。
|
||||
|
||||
A trader can typically only perform an individual trade a set number of times before having to resupply. The numeric `"max_uses"` property configures this number.
|
||||
交易界面会根据需求物品数量自动调整。某些情况下，[数量修改附魔函数](#quantity-modifying-enchantment-functions)等交易修饰符只影响第一个需求物品。
|
||||
|
||||
<CodeHeader>#/tiers/0/trades/1/</CodeHeader>
|
||||
::: tip 注意
|
||||
如果条目对象同时包含item和choice属性，只有choice部分会被考虑，item部分将被忽略。
|
||||
:::
|
||||
|
||||
```json
|
||||
#### 交易次数限制
|
||||
|
||||
交易者通常只能在补充库存前执行有限次数的单个交易。数值属性`"max_uses"`配置这个限制次数。
|
||||
|
||||
::: code-group
|
||||
```json [#/tiers/0/trades/1/]
|
||||
"max_uses": 2
|
||||
```
|
||||
|
||||
Trade limits are specific to each trade. Diminishing supply in one trade won't affect another trade, even if both trades have the same wanted and given items. By default, a trader will be able to carry out an individual trade 7 times before needing to resupply.
|
||||
|
||||
::: tip NOTE
|
||||
The act of resupplying is handled by an entity component (`"minecraft:trade_resupply": {}`).
|
||||
:::
|
||||
|
||||
If a value of `0` is given, that trade will be shown in the trading interface but will be impossible to use. If a negative value is given, that trade will never need resupplying; it will be infinitely usable.
|
||||
交易限制是每个交易独立的。一个交易的库存减少不会影响另一个交易，即使两者需求与给予物品完全相同。默认情况下，交易者可以在需要补充前执行7次单个交易。
|
||||
|
||||
#### Player Experience
|
||||
::: tip 注意
|
||||
补充行为由实体组件(`"minecraft:trade_resupply": {}`)处理。
|
||||
:::
|
||||
|
||||
Experience orbs intended for the _player_ can be disabled for a trade using the optional Boolean `"reward_exp"` property.
|
||||
如果值为0，该交易会显示在界面中但无法使用。如果为负值，该交易将无限次使用，无需补充。
|
||||
|
||||
<CodeHeader>#/tiers/0/trades/1/</CodeHeader>
|
||||
#### 玩家经验
|
||||
|
||||
```json
|
||||
通过可选布尔属性`"reward_exp"`可以禁用交易给玩家的经验球。
|
||||
|
||||
::: code-group
|
||||
```json [#/tiers/0/trades/1/]
|
||||
"reward_exp": false
|
||||
```
|
||||
|
||||
By default, `"reward_exp"` is true, and the player will be rewarded with some experience for trading. The amount of experience received is not modifiable within a trade table.
|
||||
|
||||
#### Trader Experience
|
||||
|
||||
Traders may receive experience when the player finalizes a trade. This property is the key to establishing a trade progression system with a trader using [tiers](#tiers).
|
||||
|
||||
<CodeHeader>#/tiers/0/trades/1/</CodeHeader>
|
||||
|
||||
```json
|
||||
"trader_exp": 8
|
||||
```
|
||||
|
||||
The amount of experience to reward the _trader_ is given the the optional numeric property `"trader_exp"`. By default, the trader will receive 1 XP.
|
||||
|
||||
::: tip
|
||||
For non-linearly spaced tiers, it's typical for the trader experience to increase in higher tiers. This way, lower-tier trades will have less leveling impact than higher-tier trades.
|
||||
:::
|
||||
|
||||
### Choices
|
||||
默认`"reward_exp"`为true，玩家会因交易获得经验。交易表中无法修改获得的经验量。
|
||||
|
||||
Choices are simple objects for randomly selecting an item to use for a trade. One item is selected with uniform randomness for that trade for each instance of a trader.
|
||||
#### 交易者经验
|
||||
|
||||
<CodeHeader>#/tiers/1/trades/0/wants/0</CodeHeader>
|
||||
玩家完成交易时，交易者可能获得经验。此属性是通过[层级](#tiers)建立交易者交易进度系统的关键。
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/tiers/0/trades/1/]
|
||||
"trader_exp": 8
|
||||
```
|
||||
:::
|
||||
|
||||
可选数值属性`"trader_exp"`设置奖励给交易者的经验值。默认交易者获得1点经验。
|
||||
|
||||
::: tip
|
||||
对于非线性分布的层级，通常高阶交易的交易者经验奖励更高。这样低阶交易对升级的影响小于高阶交易。
|
||||
:::
|
||||
|
||||
### 选择项
|
||||
|
||||
选择项是简单对象，用于随机选择交易使用的物品。每个交易者实例会均匀随机选择一个物品用于该交易。
|
||||
|
||||
::: code-group
|
||||
```json [#/tiers/1/trades/0/wants/0]
|
||||
{
|
||||
"choice": [
|
||||
{
|
||||
@@ -386,44 +385,42 @@ Choices are simple objects for randomly selecting an item to use for a trade. On
|
||||
]
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
Choices only contain the required `"choice"` array property. Each entry in the array is an [item](#items). At least one item must be provided.
|
||||
选择项只包含必需的`"choice"`数组属性。数组中必须至少提供一个物品条目。
|
||||
|
||||
::: tip NOTE
|
||||
Choices cannot be nested.
|
||||
::: tip 注意
|
||||
选择项不能嵌套。
|
||||
:::
|
||||
|
||||
::: tip
|
||||
There are currently no means of specifying a weight for a given item, but an item may be duplicated within the array to effectively increase its likelihood for being selected.
|
||||
目前无法为物品指定权重，但可以通过在数组中重复物品来有效增加其被选中的概率。
|
||||
:::
|
||||
|
||||
### Items
|
||||
### 物品
|
||||
|
||||
Items are the subjects of a trade. Their definitions are shared between wanted and given items, but there are some various implications depending on location used.
|
||||
物品是交易的主体。其定义在需求与给予物品间共享，但根据使用位置有不同的含义。
|
||||
|
||||
<CodeHeader>#/tiers/1/trades/0/wants/0/choice/0</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/tiers/1/trades/0/wants/0/choice/0]
|
||||
{
|
||||
"item": "wiki:sacred_stones",
|
||||
"quantity": {
|
||||
"min": 4,
|
||||
"max": 6
|
||||
},
|
||||
|
||||
"price_multiplier": 0.5
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
<CodeHeader>#/tiers/0/groups/0/trades/1/gives/0</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/tiers/0/groups/0/trades/1/gives/0]
|
||||
{
|
||||
"item": "wiki:exalted_blade",
|
||||
"functions": [
|
||||
{
|
||||
"function": "enchant_with_levels",
|
||||
|
||||
"treasure": true,
|
||||
"levels": {
|
||||
"min": 15,
|
||||
@@ -433,112 +430,109 @@ Items are the subjects of a trade. Their definitions are shared between wanted a
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
#### Item Reference
|
||||
|
||||
Items are referenced within trades using the required `"item"` string property.
|
||||
|
||||
<CodeHeader>#/tiers/1/trades/0/wants/0/choice/0/</CodeHeader>
|
||||
|
||||
```json
|
||||
"item": "wiki:exalted_blade"
|
||||
```
|
||||
|
||||
The item reference must point to the identifier of an item. A data value can be provided in-place to the reference as a suffix:
|
||||
|
||||
<CodeHeader>Example Data Assignment</CodeHeader>
|
||||
|
||||
```json
|
||||
"item": "minecraft:log:2"
|
||||
```
|
||||
|
||||
::: tip
|
||||
Data values can also be set (and much more conveniently randomized) using the `set_data` function.
|
||||
:::
|
||||
|
||||
If no data value is specified for a _wanted_ item, any item with that identifier may be traded. If no data value is specified for a _given_ item, a data value of `0` is implied.
|
||||
#### 物品引用
|
||||
|
||||
#### Quantity
|
||||
通过必需的字符串属性`"item"`在交易中引用物品。
|
||||
|
||||
The optional `"quantity"` property specifies the count of items wanted or given in a trade.
|
||||
::: code-group
|
||||
```json [#/tiers/1/trades/0/wants/0/choice/0/]
|
||||
"item": "wiki:exalted_blade"
|
||||
```
|
||||
:::
|
||||
|
||||
<CodeHeader>#/tiers/1/trades/0/wants/0/choice/0/</CodeHeader>
|
||||
物品引用必须指向物品标识符。可以直接在引用后缀中指定数据值：
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [示例数据值分配]
|
||||
"item": "minecraft:log:2"
|
||||
```
|
||||
:::
|
||||
|
||||
::: tip
|
||||
也可以通过`set_data`函数设置（更方便地随机化）数据值。
|
||||
:::
|
||||
|
||||
如果需求物品未指定数据值，任何该标识符的物品都可交易。如果给予物品未指定数据值，默认为0。
|
||||
|
||||
#### 数量
|
||||
|
||||
可选属性`"quantity"`指定交易中需求或给予的物品数量。
|
||||
|
||||
::: code-group
|
||||
```json [#/tiers/1/trades/0/wants/0/choice/0/]
|
||||
"quantity": {
|
||||
"min": 4,
|
||||
"max": 6
|
||||
}
|
||||
```
|
||||
|
||||
Quantity can be expressed as either an integer literal or a range object, such as seen above. If expressed as a range, a random value is selected uniformly inclusively within the specified limits. If no quantity is provided, the item count will default to 1.
|
||||
|
||||
::: tip NOTE
|
||||
Quantity is always bounded by the stack size and can only affect a single slot in a trade. It's impossible to, for example, enforce a requirement of 100 planks from a single slot (although this can be done using 2 `"wants"`) or giving 2 un-stackable swords to the player in a single trade.
|
||||
:::
|
||||
|
||||
#### Price Multiplier
|
||||
数量可以是整数或范围对象（如上）。如果是范围，会在最小最大值之间均匀随机选择。未指定时默认为1。
|
||||
|
||||
The price multiplier dictates how an item's [base quantity](#quantity) is altered due to certain events.
|
||||
::: tip 注意
|
||||
数量始终受堆叠限制，且只能影响交易中的单个槽位。无法通过单个槽位要求100个木板（虽然可以用2个`"wants"`实现），也无法通过单个交易给玩家2把不可堆叠的剑。
|
||||
:::
|
||||
|
||||
<CodeHeader>#/tiers/1/trades/0/wants/0/choice/0/</CodeHeader>
|
||||
#### 价格乘数
|
||||
|
||||
```json
|
||||
价格乘数决定物品的[基础数量](#quantity)如何因特定事件而变化。
|
||||
|
||||
::: code-group
|
||||
```json [#/tiers/1/trades/0/wants/0/choice/0/]
|
||||
"price_multiplier": 0.5
|
||||
```
|
||||
:::
|
||||
|
||||
`"price_multiplier"` is optional and defaults to `0`. Two systems exist that use the price multiplier: a modern and a legacy system. In the modern system, the given price multiplier can only affect the _first wanted item_ in a trade. In the legacy system, any _wanted items_ can be affected.
|
||||
`"price_multiplier"`可选，默认为0。存在新旧两套使用价格乘数的系统。新系统中，价格乘数只能影响交易的第一个需求物品。旧系统中，可以影响任何需求物品。
|
||||
|
||||
##### Fluctuation Factors
|
||||
##### 波动因素
|
||||
|
||||
Trade prices fluctuate as a result of serval factors:
|
||||
交易价格因以下因素波动：
|
||||
|
||||
- An increased demand, occurring when trading for the same item across multiple [resupplies](#trade-limit)
|
||||
- Being recently cured, such as villagers being cured from being zombie villagers
|
||||
- Being _near_ a trader who was recently cured
|
||||
- Trading with a player who is affected with "Hero of the Village"
|
||||
- 需求增加：同一物品在多次[补充](#trade-limit)后交易
|
||||
- 最近被治愈：如村民从僵尸村民治愈
|
||||
- 靠近最近被治愈的交易者
|
||||
- 与受"村庄英雄"效果影响的玩家交易
|
||||
|
||||
The price multiplier affects all these situations with the exception of a player having "Hero of the Village" when using the new pricing formula, which uses fixed values.
|
||||
除使用新定价公式的"村庄英雄"效果外，价格乘数影响所有这些情况。新公式使用固定值。
|
||||
|
||||
##### Cost Calculations
|
||||
##### 成本计算
|
||||
|
||||
The price multiplier directly and solely affects cost increases in response to an increased demand for a trade. By default, demand is 0 and cannot decrease past that value. Demand for a trade stacks, increasing when resupplying after that trade [has been exhausted](#trade-limit) and decreasing if no trades occurred between resupplies.
|
||||
价格乘数直接影响且仅影响因交易需求增加导致的成本上升。默认需求为0且不能为负。当交易[耗尽](#trade-limit)后补充时需求增加，如果在补充期间未发生交易则需求减少。
|
||||
|
||||
Cost increase due solely to demand is linear, where each increase in demand adds a proportion of the base cost, given by the price multiplier. Assuming the following variables…
|
||||
仅因需求增加的成本变化是线性的，每增加1点需求就增加基础成本的比例部分（由价格乘数决定）。假设以下变量：
|
||||
|
||||
| Variable | Meaning |
|
||||
| -------- | ------------------------------------------------------------------------------------ |
|
||||
| _c_ | Total cost |
|
||||
| _p_ | Base cost, including [quantity overrides](#quantity-modifying-enchantment-functions) |
|
||||
| _m_ | Price multiplier |
|
||||
| _d_ | Current demand |
|
||||
|
||||
<br>
|
||||
…The following formula can be used to calculate the total cost when no other factors are present:
|
||||
| 变量 | 含义 |
|
||||
|------|------|
|
||||
| _c_ | 总成本 |
|
||||
| _p_ | 基础成本（含[数量覆盖](#quantity-modifying-enchantment-functions)） |
|
||||
| _m_ | 价格乘数 |
|
||||
| _d_ | 当前需求 |
|
||||
|
||||
计算公式如下（无其他因素时）：
|
||||
_c_ = _p_ × (1 + _m_ \* _d_)
|
||||
|
||||
::: tip NOTE
|
||||
Other situations additionally use entity properties for cost calculations and are not provided here.
|
||||
::: tip 注意
|
||||
其他情况还使用实体属性计算成本，此处不提供。
|
||||
:::
|
||||
|
||||
If the price multiplier is `0`, the quantity will remain constant in most situations (except the "Hero of the Village" modifier using the new pricing formula).
|
||||
如果价格乘数为0，在大多数情况下数量保持不变（使用新定价公式的"村庄英雄"修饰符除外）。
|
||||
|
||||
::: tip NOTE
|
||||
A negative price multiplier is possible but can't affect increasing costs due to [demand](#trade-limit); the multiplier will effectively be capped to `0`. However, negative values do affect prices in response to the trader recently being cured, the trader being nearby another trader who was recently cured, or trading with a player affected with "Hero of the Village" _using the legacy pricing formulas_.
|
||||
::: tip 注意
|
||||
负价格乘数可能，但不会影响因[需求](#trade-limit)增加导致的成本上升（乘数实际被限制为0）。但负值会影响交易者最近被治愈、靠近被治愈交易者或与受"村庄英雄"影响的玩家交易（使用旧定价公式时）的价格。
|
||||
:::
|
||||
|
||||
#### Functions
|
||||
#### 函数
|
||||
|
||||
Functions are used to modify the nature of the item. The optional `"functions"` array contains a collection of functions to be applied to the item.
|
||||
函数用于修改物品属性。可选数组`"functions"`包含应用于物品的函数集合。
|
||||
|
||||
<CodeHeader>#/tiers/0/groups/0/trades/1/gives/0/</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/tiers/0/groups/0/trades/1/gives/0/]
|
||||
"functions": [
|
||||
{
|
||||
"function": "enchant_with_levels",
|
||||
|
||||
"treasure": true,
|
||||
"levels": {
|
||||
"min": 15,
|
||||
@@ -547,56 +541,55 @@ Functions are used to modify the nature of the item. The optional `"functions"`
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
The functions used by trade tables are shared with loot tables. When used ([where usable](#unusable-wanted-item-functions)) in a wanted item declaration, they act to restrict the nature of the wanted item. Such function restrictions can only affect the first wanted item.
|
||||
|
||||
##### Generally Unusable Functions
|
||||
|
||||
In general, functions behave well for trading; however, the following do not work anywhere in trade tables:
|
||||
|
||||
- `set_count`
|
||||
- `furnace_smelt`
|
||||
- `looting_enchant`
|
||||
- `trader_material_type`
|
||||
|
||||
::: tip NOTE
|
||||
`set_count`'s functionality is replaced by the [quantity property](#quantity).
|
||||
|
||||
`trader_material_type`, seen only in a single vanilla trade table, would theoretically set the data value of the item based on the mark variant of the entity, but this doesn't seem to be usable in any custom way.
|
||||
:::
|
||||
|
||||
##### Unusable Wanted Item Functions
|
||||
交易表与战利品表共享函数。在需求物品声明中使用时（[可用处](#unusable-wanted-item-functions)），用于限制需求物品的属性。此类函数限制只能影响第一个需求物品。
|
||||
|
||||
In general, using functions to specify item attributes for a wanted item will require the offered item to conform to those attributes. However, the following functions do not enforce a strict match and are therefore useless on wanted items:
|
||||
##### 通用不可用函数
|
||||
|
||||
- `set_name`
|
||||
- `set_lore`
|
||||
- `set_damage`
|
||||
- `set_book_contents`
|
||||
- `random_dye`
|
||||
- `fill_container`
|
||||
通常函数在交易中表现良好，但以下函数在交易表中完全无效：
|
||||
|
||||
##### Quantity-Modifying Enchantment Functions
|
||||
- `set_count`
|
||||
- `furnace_smelt`
|
||||
- `looting_enchant`
|
||||
- `trader_material_type`
|
||||
|
||||
2 functions actually set the quantity for the first _wanted item_ if being used as _given items_, potentially overriding any provided [quantity](#quantity) for that first wanted item:
|
||||
::: tip 注意
|
||||
`set_count`的功能由[quantity属性](#quantity)替代。
|
||||
|
||||
- `enchant_with_levels`
|
||||
- `enchant_book_for_trading`
|
||||
|
||||
::: tip NOTE
|
||||
Despite overriding the quantity, all [modified trade prices](#fluctuation-factors) adapt correctly. These functions cannot affect the quantity of a second wanted item, even when using the legacy cost formulas. If these functions are used on a _wanted item_, the quantity is not overridden.
|
||||
`trader_material_type`仅在一个原版交易表中出现，理论上会根据实体的mark变种设置物品数据值，但似乎无法自定义使用。
|
||||
:::
|
||||
|
||||
###### Enchant with Levels Function
|
||||
##### 需求物品不可用函数
|
||||
|
||||
`enchant_with_levels` randomly enchants an item as through enchanted from an enchantment table.
|
||||
通常使用函数指定需求物品属性会要求提供的物品符合这些属性。但以下函数不会强制严格匹配，因此在需求物品上无效：
|
||||
|
||||
<CodeHeader>#/tiers/0/groups/0/trades/1/gives/0/functions/0</CodeHeader>
|
||||
- `set_name`
|
||||
- `set_lore`
|
||||
- `set_damage`
|
||||
- `set_book_contents`
|
||||
- `random_dye`
|
||||
- `fill_container`
|
||||
|
||||
```json
|
||||
##### 修改数量的附魔函数
|
||||
|
||||
2个函数实际上会设置第一个需求物品的数量（当作为给予物品使用时），可能覆盖该需求物品的[quantity](#quantity)：
|
||||
|
||||
- `enchant_with_levels`
|
||||
- `enchant_book_for_trading`
|
||||
|
||||
::: tip 注意
|
||||
尽管覆盖了数量，所有[修改的交易价格](#fluctuation-factors)都会正确调整。这些函数不能影响第二个需求物品的数量（即使使用旧成本公式）。如果在需求物品上使用这些函数，数量不会被覆盖。
|
||||
:::
|
||||
|
||||
###### 附魔等级函数
|
||||
|
||||
`enchant_with_levels`随机附魔物品，如同通过附魔台附魔。
|
||||
|
||||
::: code-group
|
||||
```json [#/tiers/0/groups/0/trades/1/gives/0/functions/0]
|
||||
{
|
||||
"function": "enchant_with_levels",
|
||||
|
||||
"treasure": true,
|
||||
"levels": {
|
||||
"min": 5,
|
||||
@@ -604,100 +597,97 @@ Despite overriding the quantity, all [modified trade prices](#fluctuation-factor
|
||||
}
|
||||
}
|
||||
```
|
||||
:::
|
||||
|
||||
The cost for the first wanted item is determined by adding this function's chosen level value (capped to `0` if it would be negative) to the original [quantity](#quantity). The level value is computed from the optional `"levels"` property. If a numeric literal is used, that value is the chosen level value. If a range object is used, as above, a random number is rolled inclusively between the provided minimum and maximum. That random number then acts as the chosen level value. In the above example, the first wanted item's cost would be increased by 5 to 25.
|
||||
第一个需求物品的成本通过将此函数选择的等级值（如果为负则限制为0）加到原始[数量](#quantity)计算。等级值通过可选属性`"levels"`计算。如果使用数值，则为固定等级值。如果使用范围对象（如上），会在最小最大值之间随机选择。上例中第一个需求物品的成本会增加5-25。
|
||||
|
||||
###### Enchant Book for Trading Function
|
||||
###### 交易附魔书函数
|
||||
|
||||
`enchant_book_for_trading` is intended solely for trading. Its properties combine to determine the first wanted item's cost.
|
||||
`enchant_book_for_trading`专为交易设计。其属性共同决定第一个需求物品的成本。
|
||||
|
||||
<CodeHeader>#/tiers/0/groups/0/trades/0/gives/0/functions/0</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [#/tiers/0/groups/0/trades/0/gives/0/functions/0]
|
||||
{
|
||||
"function": "enchant_book_for_trading",
|
||||
|
||||
"base_cost": 4,
|
||||
"base_random_cost": 12,
|
||||
"per_level_cost": 4,
|
||||
"per_level_random_cost": 8
|
||||
}
|
||||
```
|
||||
|
||||
This function was only designed to be used on books, rolling for a single enchantment across all possible non-curse enchantments, including treasure enchantments. The function doesn't adapt to the current item. If used on a book, an enchantment will always successfully be applied; if used on something else enchantable, it's possible the item won't be successfully enchanted.
|
||||
|
||||
::: tip NOTE
|
||||
Presumably, when failing, the function rolls for an enchantment not applicable to the item and then fails to apply this irrelevant enchantment, resulting in an unenchanted item. The successfulness of enchanting a non-book is therefore proportional to the number of enchantments applicable to that item.
|
||||
:::
|
||||
|
||||
The total cost is set from a base cost, which is independent of the rolled enchantment, and a per-level cost, which is dependent on the random roll. All cost configuration properties are optional.
|
||||
此函数专为书籍设计，在所有可能的非诅咒附魔（包括宝藏附魔）中随机选择一项。函数不适配当前物品。用于书籍时总能成功附魔；用于其他可附魔物品时可能失败。
|
||||
|
||||
The base cost is computed by summing a starting value and a random roll. The starting value is given with `"base_cost"`, which defaults to `2`. The random roll is provided via `"base_random_cost"`, which defaults to `4`. A number will be uniformly randomly selected inclusively between 0 and the `"base_random_cost"` when a trade is generated for a trader.
|
||||
::: tip 注意
|
||||
失败时，函数可能选择了不适用于该物品的附魔导致附魔失败。因此非书籍物品的成功率与其适用附魔数量成正比。
|
||||
:::
|
||||
|
||||
For each level on the chosen enchantment, the same process occurs as in the base cost calculations: a fixed value is added to a uniformly randomly selected value. In this case, the base per-level cost is given with `"per_level_cost"`, which defaults to `3`, and the random per-level cost is given with `"per_level_random_cost"`, which defaults to `10`. The random per-level roll may be different for each level.
|
||||
总成本由基础成本（独立于随机附魔）和每级成本（依赖随机结果）组成。所有成本配置属性都是可选的。
|
||||
|
||||
Once the base cost and costs for each level are calculated, they are summed together to form the total cost. Finally, if the chosen enchantment is a treasure enchantment, the cost is then doubled. As usual, this cost cannot be less than 1 or greater than the stack size of that item. This formula holds true regardless of the pricing system being used by the trader.
|
||||
基础成本是起始值与随机值的和。起始值由`"base_cost"`设置（默认2），随机值由`"base_random_cost"`设置（默认4），在生成交易时均匀随机选择0到`"base_random_cost"`之间的值。
|
||||
|
||||
每级成本同样计算：固定值加上随机值。固定每级成本由`"per_level_cost"`设置（默认3），随机每级成本由`"per_level_random_cost"`设置（默认10）。每级的随机值可能不同。
|
||||
|
||||
计算基础成本和所有等级成本后求和得到总成本。如果选择的附魔是宝藏附魔，成本会翻倍。此成本不会小于1或大于物品堆叠上限。无论交易者使用何种定价系统，此公式都适用。
|
||||
|
||||
::: warning
|
||||
If either random cost property is negative, there seems to be a 50-50 chance that the cost will be either the given [quantity](#quantity) or the maximum stack size for that first wanted item.
|
||||
如果任一随机成本属性为负，似乎有50%概率使用给定的[数量](#quantity)或第一个需求物品的最大堆叠数作为成本。
|
||||
:::
|
||||
|
||||
::: tip
|
||||
If the total combined cost would be negative (assuming no negative random cost properties were used), the provided [quantity](#quantity) of the affected wanted item is used instead. The simplest means of guaranteeing this would be:
|
||||
如果总成本为负（假设未使用负随机成本属性），则使用受影响需求物品的[数量](#quantity)。最简单的保证方法是：
|
||||
|
||||
<CodeHeader>Example Quantity-Based Enchanted Book Cost</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [基于数量的附魔书成本示例]
|
||||
{
|
||||
"function": "enchant_book_for_trading",
|
||||
|
||||
"base_cost": -1,
|
||||
"base_random_cost": 0,
|
||||
"per_level_cost": 0,
|
||||
"per_level_random_cost": 0
|
||||
}
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
##### Spawn Egg Trader Binding
|
||||
##### 刷怪蛋绑定交易者
|
||||
|
||||
The `"set_actor_id"` function is used to set the data value of a spawn egg based on a provided entity identifier, given with `"id"`.
|
||||
`"set_actor_id"`函数通过`"id"`属性设置刷怪蛋的数据值（基于提供的实体标识符）。
|
||||
|
||||
<CodeHeader>Example Spawn Egg Trader Binding</CodeHeader>
|
||||
|
||||
```json
|
||||
::: code-group
|
||||
```json [刷怪蛋绑定交易者示例]
|
||||
{
|
||||
"function": "set_actor_id"
|
||||
}
|
||||
```
|
||||
|
||||
In trade tables, if no ID is provided, the trader's entity type will be assigned to the egg.
|
||||
|
||||
## Overrides
|
||||
|
||||
Because trade tables do not use in-data identifiers, they are overridden simply by replacing a prior trade table with a new one. You can learn more about [asset overrides here](/wiki/concepts/overwriting-assets)
|
||||
|
||||
Below are the currently used vanilla trade tables for each trader:
|
||||
|Trader|Path|
|
||||
|-|-|
|
||||
|Stone Mason|`BP/trading/economy_trades/stone_mason_trades.json`|
|
||||
|Farmer|`BP/trading/economy_trades/farmer_trades.json`|
|
||||
|Fisherman|`BP/trading/economy_trades/fisherman_trades.json`|
|
||||
|Butcher|`BP/trading/economy_trades/butcher_trades.json`|
|
||||
|Shepherd|`BP/trading/economy_trades/shepherd_trades.json`|
|
||||
|Leather Worker|`BP/trading/economy_trades/leather_worker_trades.json`|
|
||||
|Librarian|`BP/trading/economy_trades/librarian_trades.json`|
|
||||
|Cartographer|`BP/trading/economy_trades/cartographer_trades.json`|
|
||||
|Cleric|`BP/trading/economy_trades/cleric_trades.json`|
|
||||
|Tool Smith|`BP/trading/economy_trades/tool_smith_trades.json`|
|
||||
|Weapon Smith|`BP/trading/economy_trades/weapon_smith_trades.json`|
|
||||
|Fletcher|`BP/trading/economy_trades/fletcher_trades.json`|
|
||||
|Armorer|`BP/trading/economy_trades/armorer_trades.json`|
|
||||
|Wandering Trader|`BP/trading/economy_trades/wandering_trader_trades.json`|
|
||||
|
||||
::: tip NOTE
|
||||
Additional trade tables exist directly within the `trading` folder, but these are deprecated. Only the tables in the `economy_trades` sub-folder are currently used.
|
||||
:::
|
||||
|
||||
Alternatively, a trader entity definition can be updated to point to a new trade table location.
|
||||
在交易表中，如果未提供ID，刷怪蛋将绑定交易者的实体类型。
|
||||
|
||||
## 覆盖
|
||||
|
||||
由于交易表不使用数据内标识符，只需用新交易表替换旧表即可实现覆盖。了解更多关于[资源覆盖](/wiki/concepts/overwriting-assets)的内容。
|
||||
|
||||
以下是各交易者当前使用的原版交易表：
|
||||
|交易者|路径|
|
||||
|-|-|
|
||||
|石匠|`BP/trading/economy_trades/stone_mason_trades.json`|
|
||||
|农民|`BP/trading/economy_trades/farmer_trades.json`|
|
||||
|渔夫|`BP/trading/economy_trades/fisherman_trades.json`|
|
||||
|屠夫|`BP/trading/economy_trades/butcher_trades.json`|
|
||||
|牧羊人|`BP/trading/economy_trades/shepherd_trades.json`|
|
||||
|制革师|`BP/trading/economy_trades/leather_worker_trades.json`|
|
||||
|图书管理员|`BP/trading/economy_trades/librarian_trades.json`|
|
||||
|制图师|`BP/trading/economy_trades/cartographer_trades.json`|
|
||||
|牧师|`BP/trading/economy_trades/cleric_trades.json`|
|
||||
|工具匠|`BP/trading/economy_trades/tool_smith_trades.json`|
|
||||
|武器匠|`BP/trading/economy_trades/weapon_smith_trades.json`|
|
||||
|制箭师|`BP/trading/economy_trades/fletcher_trades.json`|
|
||||
|盔甲匠|`BP/trading/economy_trades/armorer_trades.json`|
|
||||
|流浪商人|`BP/trading/economy_trades/wandering_trader_trades.json`|
|
||||
|
||||
::: tip 注意
|
||||
`trading`文件夹中还存在其他交易表，但已弃用。目前仅使用`economy_trades`子文件夹中的表。
|
||||
:::
|
||||
|
||||
或者，可以更新交易者实体定义以指向新的交易表位置。
|
||||
@@ -1,3 +1,4 @@
|
||||
---
|
||||
title: Meta
|
||||
nav_order: 12
|
||||
---
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
---
|
||||
title: 中国版Mod开发
|
||||
nav_order: 2
|
||||
categories:
|
||||
- title: 基础
|
||||
color: blue
|
||||
|
||||
@@ -106,7 +106,7 @@ class MyClientSystem(ClientSystem):
|
||||
BOOM！就这么简单！
|
||||
|
||||
:::details :bulb: 为什么需要这些System？
|
||||
<!--@include: @/wiki/1-Mod脚本开发/为什么是System.md-->
|
||||
<!--@include: @/wiki/modsdk/why-system.md-->
|
||||
:::
|
||||
|
||||
## 3. 运行你的Mod
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
---
|
||||
title: NBT
|
||||
nav_order: 13
|
||||
categories:
|
||||
- title: 基础
|
||||
color: blue
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
---
|
||||
title: 粒子 Particles
|
||||
nav_order: 14
|
||||
categories:
|
||||
- title: 基础
|
||||
color: blue
|
||||
|
||||
@@ -1,3 +1,4 @@
|
||||
---
|
||||
title: 服务器 & 领域服
|
||||
nav_order: 15
|
||||
---
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
---
|
||||
title: 视觉效果
|
||||
nav_order: 16
|
||||
categories:
|
||||
- title: 基础
|
||||
color: blue
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
---
|
||||
title: 虚拟现实 VR
|
||||
nav_order: 17
|
||||
categories:
|
||||
- title: 基础
|
||||
color: blue
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
---
|
||||
title: 世界生成器
|
||||
nav_order: 18
|
||||
categories:
|
||||
- title: 基础
|
||||
color: blue
|
||||
|
||||
@@ -64,7 +64,7 @@ async function findMarkdownFiles(dir) {
|
||||
const content = await fs.readFile(fullPath, 'utf-8');
|
||||
// 如果超过600行，跳过
|
||||
const lines = content.split('\n').length;
|
||||
if (lines > 600) {
|
||||
if (lines > 6000) {
|
||||
console.log(`⏭️ 跳过超过600行的文件: ${path.relative(targetDir, fullPath)}`);
|
||||
continue;
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user