[FS]&[BBSWiki] 模块化机械-ModularMachinery 官方Wiki翻译 - Mod研讨

Citysands

本帖最后由 Eicy 于 2021-8-25 14:44 编辑

ModularMachinery

模块化机械官方Wiki翻译

原文地址

翻译地址

简介

模块化机械是一个专门为整合包制作者提供可自由定制机械的Mod，可通过修改JSON来实现对机械输出、输入、结构等参数的控制。

模块化机械本体已足够强大，同时还可搭配 Modular Diversity 等附属并使用 Crafttweaker 可实现更多玩法。

其中使用了ModularMachinery的国内著名整合包有 GreedyCraft贪婪整合包 EnigTech 2 等（不分先后）。

如果你想更熟悉地使用MM的话，我建议你去翻翻其他使用了此mod的整合内的crt脚本和json，如果你还有余力而且有一定的编程基础，那我建议你去看看它和crt的源代码。

链接

原文地址:https://github.com/HellFirePvP/ModularMachinery/wiki
翻译地址:https://mcbbs-wiki.cn/wiki/ModularMachinery_WikI
Curseforge:https://www.curseforge.com/minecraft/mc-mods/modular-machinery

统计

按删掉的作者的重复的废话翻译算的话翻译的汉字:7318个
翻译人员提供的代码样例:4462个字符
翻译人员提供的样例配图:3张
总字数:8014个未将附件内演示代码算入统计数据

2021.12 数据，可能有更多内容

ModularMachinery
模块化机械官方Wiki翻译

原文地址

翻译地址

简介

模块化机械是一个专门为整合包制作者提供可自由定制机械的Mod，可通过修改JSON来实现对机械输出、输入、结构等参数的控制。模块化机械本体已足够强大，同时还可搭配 Modular Diversity 等附属并使用 Crafttweaker 可实现更多玩法。其中使用了ModularMachinery的国内著名整合包有 GreedyCraft贪婪整合包 EnigTech 2 等（不分先后）。如果你想更熟悉地使用MM的话，我建议你去翻翻其他使用了此mod的整合内的crt脚本和json，如果你还有余力而且有一定的编程基础，那我建议你去看看它和crt的源代码。

链接

统计

Custom Machines: Important notes

自定义机械:重要提示

In order to make a custom machine, its "components" have to be defined. The machine is 1 controller block in the "center" and the rest of the machinery is placed around it in a specific pattern. If the pattern is valid, the controller will then recognize that said machine was correctly assembled and will then perform crafting/processing of whatever kind of recipes you've made up for it (explaining how to make those in another wiki page).为了制作一个自定义机械，它的 “组成部分” 就必须被定义。自定义机械的 “中心” 有 1 个控制方块，其他机械部件按多方块结构配方放置在它的周围。如果该多方块结构配方是合理有效的，控制方块就会识别出组装的多方块结构机械，然后它会执行你为它创建的任何种类的配方的合成 / 处理（在另一个wiki页面中会解释怎么去制作那些配方）。

A machine might need more than just its controller block and some specific blocks. Input and Output Buses for Items, Input and Output Hatches for fluids and an Energy Hatch to supply power are essential to interact with the machine as a whole in any way and are used to input items or fluids for specific recipes, provide power to run those recipes and then collect/drain items/fluids from the outputs after the recipe has been completed.一台自定义机械需要的可能不只是它的控制方块和一些特定的结构用方块。物品的输入和输出仓、流体的输入和输出仓，以及提供能量的能源仓对于自定义机械的相关交互配方的进程是必须的，它们被用来为特定的配方输入物品或输入流体，为运行那些配方提供能量，在配方运行完成后，又会从输出端收集/排出物品/流体。
Including possible positions in your machine-complex for said Input/Output Buses/Hatches and Energy Hatches is required if you want to register recipes that require said inputs/outputs. For example, you can hardly have a recipe for a machine that requires 1 item as input, but the machine doesn't have any position where you could place a input bus to actually input any items. Same goes for the output bus; If you have recipes that produce items and you don't have an output bus on your machine, it can't process it because it has no place to output the items to. Same goes if (all) output bus(es) are full.如果你想注册有上述输入/输出方式的配方，就必须在你的多方块机械结构中描述上述输入/输出仓和能源仓的大概位置。举个例子，你很难有一个只需要 1 个物品作为输入的机械配方，而该机械也没有位置给你输入任何物品。对于输出仓也是相同的；如果你有生产物品的配方，但没有输出仓在你的机械中，机械就不能处理这个配方，因为它没有地方可以输出物品。如果（所有）输出仓满了也一样。

Custom Machines: Machine format

自定义机械:机械文件格式

Machine jsons (and variable jsons for them) have to be in the /config/modularmachinery/machinery/ folder.机械的jsons（和变量jsons）必须保存在 /config/modularmachinery/machinery/ 文件夹下。
The format for defining a machine in json is as follows:在json文件中定义一个机械的格式如下：
{
"registryname": "yourmachinesregistryname", //注册名必须是独一无二的.
"localizedname": "however your machine is called when displaying its name", //只是用来显示
"requires-blueprint": true, //设为true使机器需要蓝图才能运行.
"color": "FF4900", //可选选项,当机械搭建成功后会将外壳更改为你设置的16进制颜色(不透明)
"parts": [ //位置和应用的方块的数组
{
"x": 1, //此坐标相对于控制器的坐标(0,0,0)
"y": 1, //不定义x，y，z表示偏移量为0
"z": 1,
"elements": [ //可能的方块状态数组
//在方块的注册名称后添加@<metadata>来定义带有元数据的特定方块的状态。
"minecraft:stone@1"

},
{
"y" 2,
//它也可以不是一个数组你也可以只设置一个方块状态
//你也可以使用变量来代替方块状态
"elements": "minecraft:stone@2"
}

}

机械的jsons（和变量jsons）必须保存在 /config/modularmachinery/machinery/ 文件夹下。
As an example for a proper machine definition, let's write up a JSON file for a centrifuge. The centrifuge should:举一个正确定义机械的例子，让我们为离心机写一个JSON文件。离心机应该是这样的：

Take in up 1 item and produce up to 4 items out of it and potentially a fluid.输入 1 物品，并产出最多 4 物品，也可能产出流体。
It should only generate those outputs with a certain chance. (example: Let's say output-item 1 only with 50% chance, output 2 only with 25% chance and output 3 and 4 only with 10%)它应该有一定几率才会输出物品。（举例，输出1件物品只有50%的几率，输出2件物品只有25%的几率，输出3件和4件物品只有10%的几率）
Need a certain amount of RF per processing-tick机械在处理时，每tick都需要一定量的RF

So what do we need for our machine? At least 1 available position for an input bus, At least 1 available position for an output bus, 1 available position for a output hatch and at least 1 position for an energy hatch. Along with that, we need a registry name for it (so the mod can identify it later) and we need a localized name (so it has a name the mod can display to the player).那我们需要为机械做什么呢？输入仓至少要有 1 个可用位置，输出仓至少要有 1 个可用位置，输出仓至少要有 1 个可用位置，而能源仓至少也要有 1 个位置。有了这些，我们还需要给它注册一个名称（这样mod以后就可以识别它了）并且我们需要一个本地化的名称（这样它就有一个可以让mod显示给玩家的名称）
From the absolutely necessary parts now to the 'optional' parts: The actual looks of the centrifuge and what blocks we want the player to place where in order to make it work. Let's say for this example we want to make a 3x3x3 sized machine. The bottom 3x3 layer will all be machine casings from Modular Machinery itself, which can either be machine casings OR input bus OR output bus OR output hatch OR energy hatch. The middle 3x3 layer should be iron bars in all corners, water in the center, iron blocks on the edge-sides and on one of these edge sides, we'll want the user to place the controller; so the controller will later be the 0, 0, 0 "center" of our machine and we'll design the other blocks around that block. The uppermost 3x3 layer will be again iron bars on all corners, iron blocks on the 4 edges and a glass block in the center.从绝对需要的部分到‘可选’的部分：离心机的实际外观，我们想让玩家在哪里放置什么方块来让它工作。比如说这个例子，我们想制作一个3x3大小的机械。最底层3x3的位置得全是模块化机械自己的机械外壳，这可以是机械外壳或输入仓或输出仓或输出仓或能源仓。中层3x3的位置，所有角落应该放铁栏杆，水在中间，铁块在边边上，在其中一个边上，我们想让使用者放置控制器；控制器之后会成为相当于我们机械中的原点0,0,0“中心”，我们会围绕该方块放置其他方块。最上层3x3的位置再在所有角落放置铁栏杆，在 4 个边上放置铁块，在中间放置玻璃。
Alright, now we got a solid idea of what our machine will look like: Bottom layer should be all kinds of input, output, energy buses/hatches or just machine casings however the player wants to arrange those, the middle layer and upper layer will be some sort of iron block funnel with iron bars reinforcing it, water as actual centrifuge solvent and glass above it so it doesn't splash out. The controller as central piece will be embedded in the middle layer instead of one of the iron blocks.好了，现在我们对我们的机械长什么样子有了明确的概念：最底层应该是各种输入、输出、能源仓，或只是机械外壳，不管玩家想怎样排列那些方块，中层和最上层都是用一些铁块组成漏斗的形状，用铁栏杆加固，水作为离心机的溶剂，上面有玻璃，这样水就不会出来。作为中心部件的控制器将会被嵌入中层，替换掉原来的一个铁块。
Additionally, you want to define your machine in positive Z direction since the controller is facing to negative Z. Rotate it and it'll look odd in preview and the controller will rotate oddly...另外，你要在正 Z 轴方向上定义你的机械，因为控制器的朝向是负 Z 轴。转动它，它会在预览中变得很奇怪，控制器也会奇怪地旋转起来...
From that now we write down the JSON for the machine: (Warning, might be long)我们现在开始为机械写JSON文件：（警告，可能会比较长）
{ "registryname": "centrifuge", "localizedname": "Iron Reinforced Centrifuge", "parts": [ { "x": 0, "y": 1, "z": 2, "elements": "minecraft:iron_block" }, { "x": 0, "y": 1, "z": 0, "elements": "minecraft:iron_block" }, { "x": -1, "y": 1, "z": 1, "elements": "minecraft:iron_block" }, { "x": 1, "y": 1, "z": 1, "elements": "minecraft:iron_block" }, { "x": 1, "y": 1, "z": 2, "elements": "minecraft:iron_bars" }, { "x": -1, "y": 1, "z": 2, "elements": "minecraft:iron_bars" }, { "x": 1, "y": 1, "z": 0, "elements": "minecraft:iron_bars" }, { "x": -1, "y": 1, "z": 0, "elements": "minecraft:iron_bars" }, { "x": 0, "y": 1, "z": 1, "elements": "minecraft:glass" },

{ "x": 0, "y": 0, "z": 2, "elements": "minecraft:iron_block" }, { "x": -1, "y": 0, "z": 1, "elements": "minecraft:iron_block" }, { "x": 1, "y": 0, "z": 1, "elements": "minecraft:iron_block" }, { "x": 1, "y": 0, "z": 2, "elements": "minecraft:iron_bars" }, { "x": -1, "y": 0, "z": 2, "elements": "minecraft:iron_bars" }, { "x": 1, "y": 0, "z": 0, "elements": "minecraft:iron_bars" }, { "x": -1, "y": 0, "z": 0, "elements": "minecraft:iron_bars" }, { "x": 0, "y": 0, "z": 1, "elements": "minecraft:water" },
{ "x": 1, "y": -1, "z": 2, "elements": [ "modularmachinery:blockcasing", "modularmachinery:blockinputitem", "modularmachinery:blockinputenergy", "modularmachinery:blockoutputitem", "modularmachinery:blockoutputfluid" }, { "x": 0, "y": -1, "z": 2, "elements": [ "modularmachinery:blockcasing", "modularmachinery:blockinputitem", "modularmachinery:blockinputenergy", "modularmachinery:blockoutputitem", "modularmachinery:blockoutputfluid" }, { "x": -1, "y": -1, "z": 2, "elements": [ "modularmachinery:blockcasing", "modularmachinery:blockinputitem", "modularmachinery:blockinputenergy", "modularmachinery:blockoutputitem", "modularmachinery:blockoutputfluid" }, { "x": 1, "y": -1, "z": 1, "elements": [ "modularmachinery:blockcasing", "modularmachinery:blockinputitem", "modularmachinery:blockinputenergy", "modularmachinery:blockoutputitem", "modularmachinery:blockoutputfluid" }, { "x": 0, "y": -1, "z": 1, "elements": [ "modularmachinery:blockcasing", "modularmachinery:blockinputitem", "modularmachinery:blockinputenergy", "modularmachinery:blockoutputitem", "modularmachinery:blockoutputfluid" }, { "x": -1, "y": -1, "z": 1, "elements": [ "modularmachinery:blockcasing", "modularmachinery:blockinputitem", "modularmachinery:blockinputenergy", "modularmachinery:blockoutputitem", "modularmachinery:blockoutputfluid" }, { "x": 1, "y": -1, "z": 0, "elements": [ "modularmachinery:blockcasing", "modularmachinery:blockinputitem", "modularmachinery:blockinputenergy", "modularmachinery:blockoutputitem", "modularmachinery:blockoutputfluid" }, { "x": 0, "y": -1, "z": 0, "elements": [ "modularmachinery:blockcasing", "modularmachinery:blockinputitem", "modularmachinery:blockinputenergy", "modularmachinery:blockoutputitem", "modularmachinery:blockoutputfluid" }, { "x": -1, "y": -1, "z": 0, "elements": [ "modularmachinery:blockcasing", "modularmachinery:blockinputitem", "modularmachinery:blockinputenergy", "modularmachinery:blockoutputitem", "modularmachinery:blockoutputfluid" }}

Custom Machines: Variables

自定义机械:变量

As shown at the end of the previous page of the wiki, machine definitions can be extremly long and especially when a lot of blockstates are potentially allowed for a specific position, it can get messy and contain a lot of cuplicates since most parts then only differ at their position, not at the blockstates that are allowed.正如Wiki的上一页末尾所示，机械的定义可能会十分臃肿，特别是当一个位置允许有多种方块（机械结构模块）状态时定义文件会变得很乱而且还会出现重复的内容，因为大多数的机械结构模块只是在位置上有差异，而不是在所允许的结构模块状态上有差异。
Variables help adress this at least a little bit. So instead of having to write all blockstates and copy and paste that over and over again in the final machine definition, you can define a variable that's equivalent to that specific set of blockstates and use the variable instead.变量（数组变量）在一定程度上能帮助解决这个问题，所以你可以定义一个变量，变量的值为那组的特定结构模块的状态。然后用变量就行了，cv这笨法子老蠢了。（无编程基础新人忽略掉括号的内容 print i）
Variables need to be defined in their own file(s). You can have multiple variable json files, defining 2 variables with the same names (even when in different files) will then cause one to overwrite the other - the order is not defined and may vary, so define your variables with a unique name. Variable files have to end with .var.json instead of just .json. They have to be in the same folder as the machine jsons and are loaded before any of the machines are.变量（并非每一个！！！）需要在一个单独的文件中定义. 你可以有多个变量json文件。用相同的名字定义两个变量（即使是在不同文件中）会导致后定义的变量覆盖先定义的变量。变量json文件必须以. var.json 结尾。变量json文件必须与机械的jsons在同一个文件夹，变量json加载优先级高于机械优先级。
Example of a variable: The centrifuge 'casings' on the bottom layer of the example of the previous page:变量的样例: 此为上一页的样例中离心机底部的"外壳":
{ "x": 1, "y": -1, "z": 2, "elements": [ "modularmachinery:blockcasing", "modularmachinery:blockinputitem", "modularmachinery:blockinputenergy", "modularmachinery:blockoutputitem", "modularmachinery:blockoutputfluid"}
A variable file (let's call it "variables.var.json") would look like this:变量文件 (假如它叫 "variables.var.json") 里面的内容应该是这样:{ "iron_centrifuge_casing": [ "modularmachinery:blockcasing", "modularmachinery:blockinputitem", "modularmachinery:blockinputenergy", "modularmachinery:blockoutputitem", "modularmachinery:blockoutputfluid" }}
You can of course define multiple variables in the same variable-json file just by separating them with a comma. Variables cannot contain other variables in their list of applicable blockstates.当然，你也可以在同一个变量json文件中定义多个变量，用逗号分开即可。变量的定义值不能有其他变量.（无编程基础新人忽略掉括号的内容 i不能+=j）使用变量之后的效果:
{ "x": 1, "y": -1, "z": 2, "elements": "iron_centrifuge_casing"}

Custom Machines: Recipes

自定义机械:配方

Now that you've set up one machine or multiple with potential input/output options for items/fluids/energy, you can now define recipes for those machines that the machine will then perform if the input items/fluids/energy necessary are present and space for output items/fluids/energy is available.现在，你应该已经为一台机械或多台机械设置了物品/流体/能量的输入/输出配置，现在你可以为这些机械定义配方，如果必须要输入的物品/流体/能量存在，并且用来输出物品/流体/能量的输出仓有足够空间，机械就会执行这些配方。
This system allows for any kind of potential recipes you might want the machine to perform. This can range from some sort of furnace that takes items and produces a set amount of 'energy' per tick, up to something like a Fusion Reactor that takes several fluids as input and outputs another fluid and a lot of energy per tick. It can also centrifuge items out of fluids for the cost of a set amount of energy per tick and so on and so forth. There is no bounds to this kind of definition.这个系统允许你让机械去执行的任何类型的配方。它的范围大可以是熔炉，接收物品，并每tick产出一定量的“能量”，再到类似于核聚变反应堆的东西，接受几种流体作为输入，并在输出仓产出另一种流体和大量能量。它还可以从流体中离心出物品，但每tick要消耗一定量的能量等等，这些定义是没有限制的。
However, there are certain things that have to be set so the recipe can function properly. Let's first look at the format and then at a few examples:然而，有些东西必须设置好，以便配方正常运作。让我们先看看格式，再看几个例子：
{ //机械registryname //在机械的json中定义 'registryname' "machine": "centrifuge", //每一个配方都要有独一无二的注册名 //以至于让mod可以安全地读写 //来自NBT的配方. "registryName": "centrifuge_lava_generic", //配方用时 "recipeTime": 20, //配方内容 "requirements": [ //定义内容的数组 { //输入输出成分类型 //可用的类型有: energy, fluid, item "type": "energy", //输入输出交互类型 //可用类型: input, output "io-type": "input", //组件中每份输入物品可以让机械输入/输出的能量（FE/Tick） "energyPerTick": 10 }, { "type": "item", "io-type": "output", //物品定义 //定义生产出的物品 //或是配方的消耗物品 "item": "minecraft:gold_nugget", //定义物品/流体消耗/生产的几率不定义默认为100% "chance": 0.01 }, { "type": "item", "io-type": "output", "item": "minecraft:fire_charge", "chance": 0.2 }, { "type": "fluid", "io-type": "input", //定义输入消耗/输出生产的流体 "fluid": "lava", //流体产出/消耗量(单位 mB 1000 mB (milliBucket) = 1 B (Bucket)) "amount": 10, //几率tag也能有 //定义流体产出/消耗几率 "chance": 0.8 }}
This defines a recipe for the 'centrifuge' which runs for 20 ticks - so 1 second ideally - uses up 10 'energy' per tick, so a total of 200 'energy' (RF, FE, ...), uses up 10mB of lava with a chance of 80% to produce a gold nugget with a chance of 1% or a fire charge with the chance of 20%.这里定义了一个‘离心机’的配方，它运行了 20 tick - 理想情况下是 1 秒 - 运行一tick消耗 10 ‘能量’，所以一共消耗 200 ‘能量’（RF,FE,......） ,消耗 10mb 的岩浆有80%的几率产出产物，且产物有1%的几率是金粒，20%的几率是火焰弹。
Also: instead of defining only 1 machine in 'machine' you can also define an array of machines in 'machine' and the recipe will be added to all of those machines. Example:另外：你也可以在‘machine’中定义一个机械阵列，而不是只定义单单一个机械，配方也会被添加到这些机械上。
例如："machine": [ "centrifuge", "some_other_machine", "another_machine"

Custom Machines: Recipe Adapters

自定义机械:配方适配器

While writing up new machines and recipes is fine and all, you might want to import recipes from furnaces or related - That's what adapters are for. They convert recipes from given/defined recipes/machines and convert them over into a format ModularMachinery understands and adds them to the recipe pool of a given machine.完成一个机械及其配方的自定义是一件很赞的事情，你可能还想把配方从熔炉之类的机械中导入。这就要通过配方适配器来做到了。它将会定义的配方或机械转化为”模块化机械“所理解的形式并将它们添加到所给定的机械的配方池中
At the moment, adapters are still pretty primitive and non-customizable, but that's going to change. (at least i have plans for that...)当前，适配器仍然相当原始且无法定制。但这会被改善的(至少我已经有了那方面的计划)
Currently available adapters:当前可用适配器：

(v1.0+)"minecraft:furnace" (Will convert all furnace recipes into ModularMachinery recipes, duration 120 ticks at 20 FE/t)(v1.0+)"minecraft:furnace" (将所有的熔炉配方转化为“模块化机械”模组可用的配方, 以20 FE/t的速度持续120ticks )

(v1.9.6+) Every defined machine (its registry name) can be specified as adapter, so you can import recipes from one machine into another (Recipes will be identical unless modified by recipe modifiers, explained down below). Machines created with modular machinery jsons will always be in the 'modularmachinery' namespace.(v1.9.6+)任何自定义机械(它的注册名)都能被适配器指定，所以你能把一个机械的配方导入到另一个机械中(配方都会是相同的，除非你用配方修改其将其进行了修改, 我会在下文进行解释)。通过多方快结构创建的机械都会存储在“modularmachinery”命名空间内。

The syntax for the moment (v. 1.0) is as follows:当前的语法 (v. 1.0)：
{ "machine": "machineregistryname", "adapter": "minecraft:furnace"}
Adapters must be defined in the same directory as recipes and have to have a file ending of .adapter.json !适配文件必须存储于配方所在目录并具有“.adapter.json”文件扩展名！
From version 1.9.6 and newer versions, modifiers can be applied to each recipe imported through the adapter. This can - as explained in 13. Recipe Modifiers [Advanced] - modify all potential requirements of a recipe, e.g. energy, item, duration, ...从1.9.6版本开始，修饰符可以应用任何适配过的配方。这也正是“配方修饰符 [进阶]”修改配方的潜在要求，其可以应用于能量，物品，工作时间……
{ "machine": "alloy_furnace", "adapter": "minecraft:furnace", "modifiers": [ { "io": "output", "target": "item", "operation": 1, "multiplier": 2.0 }, { "io": "input", "target": "duration", "operation": 1, "multiplier": 0.5 }}
In this example of an adapter.json, the adapter imports all recipes from 'minecraft:furnace' and will modify them so they will produce double the output (operation 1 = multiply; multiplier 2 = result amount * 2).在这个adapter.json例子中,适配器导入并修改"minecraft:furnace"中的配方，使该机器产生双倍输出。(operation 1 = multiply; multiplier 2 = result amount * 2)。
So one can optionally specify a "modifiers" tag in the .adapter.json, which is required to be a list/array of modifier objects. See the wiki page for recipe modifiers for further information.所以魔改作者可以在“.adapter.json”中指定修饰符Tag。修饰符Tag需要修改对象的list/array。详情请参考配方修饰符的wiki界面

Custom Machines: NBT Checking & Setting [Advanced]

自定义机械:NBT 检查 & 设置【进阶】

NBT Tags, if present, hold significant information about an item that you might need to check against when using an item as input OR set a specific NBT tag on an item output. NBT Tags can be insanely complex and recursive. Maybe you just need to check if a specific value is present or if a number in the NBT tag is inside a specific range. So most of the tag might be unnecessary to check at all.NBTTag会保存关于物品的属性信息，当定义一个物品作为配方的输入物品或者是在配方的物品输出上设置特定的NBTTag时你可能需要检查它。
Checking or setting the NBT-tag is not always visible to the user! So keep that in mind when thinking about complex checks that are not obvious.NBTTag可以是复杂且递归的。检查它的话你只需要检查一个特定的值是否存在，或者说也可以检查NBTTag中的被检查的数字是否在特定范围内。所以大部分的Tag可能根本就没必要检查。检查或者设置NBTTag不总是对玩家可用的。所以在你做出复杂的NBT行为检测时需要注意这点。
You can get the nbt-tag of the itemstack you're currently holding with /mm-hand. The message sent back to you in chat will also be copied to your clipboard (if possible) in the expected JSON format.你可以使用/mm-hand来获得你手上的itemstack的NBTTag。在信息栏中给你返回的信息也会以预设好的JSON格式复制到你的剪贴板上。（如果可以）
NBT checks are lazy-checks so the mod will only check if the NBT data you specified is at least present/acceptable. The mod ignores additional tags/entries on the itemstack. The NBT-tag to check is defined as JSON in an item input/output definition with the tag "nbt" (examples down below).NBT检查方法是懒检查（lazy-checks），所以mod只检测你指定的NBT数据是否存在/可用。该模组会忽略itemstack中的其他tag/entries。要被检查的NBTTag在带有Tag为"nbt"的物品输入/输出定义中要定义以JSON形式。（样例在下）
When defining a number in the NBT tag you can prefix that number directly with "<", "<=", "==", "=>" or ">" so you're not directly checking if the number specified is equal to the number on the itemstack, but is less, less & equal, equal, greater & equal or greater than the number on the itemstack.在NBTTag中定义字符串时，你也可以把它定义为一个正则表达式。（请留意你给字符串定义的内容，因为它不仅会用来与ItemStack上的字符串匹配，它还会被设置在ItemStack中用于在JEI中预览。）当在NBTTag中定义一个数字时，你可以直接使用"<","<=","==","=>",">"作为定义的数字的前缀，这样就可以不只可以检查定义数字是否等于ItemStack上的数字了呢。
When defining a String in the NBT tag you can also define it as a regular expression instead of just the plain string you want to match against. (Be careful what you define here, as it is not only used to match the string against the string on the itemstack, but also set on the itemstack for the preview in JEI!)即使只是为了检查/匹配NBTTag或它的值和可能的输入物品，在输入中定义的NBTTag也会在建立JEI的预览时直接应用到ItemStack中。为了在匹配字符串时使用正则表达式，并使JEI的预览不出错，你可以为物品添加定义一个"nbt-display"entries，同时在与"nbt"并列的地方你可以删除所有的NBT检查，比如正则表达式，因为在将NBTTag标签应用于JEI中的配方预览的ItemStack时NBTTag会优先"nbt"。
Example #1:样例 #1
[...]{ "type": "item", "io-type": "input", "item": "forge:bucketfilled", "amount": 1, "nbt": { "FluidName": "ic2uu_matter", "Amount": ">=1000" }},[...]
The input will only be successful if the item is a forge bucket with 1000 or more mb of 'ic2uu_matter' in it.此配方中只有输入物品是个盛装有大于等于1000mb的"ic2uu_matter"的Forge-Bucket物品时输入才会成功。
Example #2:样例 #2:
[...]{ "type": "item", "io-type": "input", "item": "forge:bucketfilled", "amount": 1, "nbt": { "FluidName": "^.*water.*$", "Amount": "1000" }},[...]
This will now only accept if the item in question is a forge-bucket with exactly 1000mb of some fluid that contains 'water' in its name. Defining neither one of the number-comparison methods (<, <=, ==, >=, >) means it'll always mean the same as an exact-match (==). However, Defining "^.water.$" as FluidName will also set that as FluidName for JEI recipe previews, which will (not surprisingly) mess up the rendering. See the last few sentences above the 1st example for more information on how to avoid that.现在此物品配方的输入只能接受恰好盛装有1000mb的名字带有"water"的液体的Forge-bucket物品。定义的任意的数字比较运算方法(<、<=、==、>=、>)的含义代表它总是和完全匹配(==)的使用含义相同。但是，将"^.water.$"定义为FluidName也同时会将其设置为JEI配方渲染的FluidName从而导致错误。至于怎么避免这种情况，可以看看第一个样例上的最后行代码。
Example #3:样例 #3:
[...]{ "type": "item", "io-type": "input", "item": "forge:bucketfilled", "amount": 1, "nbt": { "SomeWeirdTagName": { "SomeWeirdNumber": ">5000", "SomeWeirdList": [ "AListEntry" } }},[...]
This kind of NBT matching can be applied as deep and complex as it needs to be. For the item in Example #3 to be accepted, it needs to be a forge-bucket, has to have a NBTTagCompound at 'SomeWeirdTagName'. In that NBTTagCompound there needs to be a integer number at the key 'SomeWeirdNumber' which has to be bigger than 5000. Additionally, there needs to be a String-List at key 'SomeWeirdList' that has at least 1 entry which is called 'AListEntry'.此配方中这样的NBT匹配可以根据需要而应用地十分复杂，要让样例#3中的物品可以被输入的话，输入物品它就必须是个Forge-bucket物品且必须在"SomeWeirdTagName"内有一个 NBTTagCompound。在这个NBTTagCompound中的"SomeWeirdNumber"key上有一个整数型数字，且这个数字必须大于5000。另外，"SomeWeirdList"的key需要有一个字符串数组且至少要有一个叫做"AListEntry"的entry。
Example #4:样例 #4:
[...]{ "type": "item", "io-type": "output", "item": "forge:bucketfilled", "amount": 1, "nbt": { "FluidName": "ic2uu_matter", "Amount": "1000" }},[...]
The output is more straight-forward since there is no matching being done, only setting the NBT-tag. So whatever you define in the 'nbt' in the item output will be applied to the output stack.在此配方中因为没有进行nbt匹配只是设置了nbttag，物品输出是直接输出的。所以，不管物品的"nbt"到底定义了什么，它都会直接应用到output stack。
You can however not only apply NBT-checks to itemstack inputs, but also to TileEntities that are part of your structure, so you can ask for specifically a spider-spawner for example. The NBT-tag to check against has to be defined alongside the coordinates for a specific position. The NBT-Tag will be matched against the TileEntity's NBT-tag, equal to ** it'd save into a chunk when saving & loading the world. The NBT-tag follows the same syntax & options as the item-input's NBT-check.然而，你不只可以将NBT检查应用于配方中的ItemStack输入，你也可以把它应用为多方块结构的一部分的TileEntities。效果的话，你可以用它做个特别的蜘蛛刷怪箱。被检查的NBTTag必须与特定的位置坐标一起定义。若被检查NBTTag与TileEntity的NBTTag相匹配，相当于它在保存和加载世界时保存到了一个区块中的NBTTag中。此NBTTag语法和设置与Item-Input的NBT-check相同。
Example #1:样例 #1:
[...]{ "x": 1, "y": 1, "z": 1, "nbt": { ... }, "elements": [ ...}[...]
If something is unclear - since this indeed can be complex - you can also ask on AstralSorcery/ModularMachinery's discord: Discord-Invite-Link要是还不明白怎么回事的话（因为这可能确实复杂了"点"）你可以去作者discord询问.

Custom Machines: Recipe Sorting

自定义机械:配方排序

You might want to add a recipe for a machine that (for example) take 1 coal + energy and output 1 iron. Now you want to "reward" the user for providing lava as fluid input and you define 1 coal + 1 bucket of lava + energy outputs 4 iron.你也许想给一台机械添加一个配方。比如输入 1 coal + energy 输出 1 iron. 现在你想提高一下玩家的游戏体验，你就可以定义一个输入1 coal+ 1 bucket of lava + energy 输出4 iron的配方。
The problem arises that if the user provides coal + lava + energy, the machine checks the recipe that takes 1 coal + energy => 1 iron first and it of course all input components of that are present & useable, so it'll select that recipe and produce 1 iron instead of consuming the additional lava and produce 3 more iron of that piece of coal.但是这么整会出大问题如果玩家提供的泛输入物品是 coal + lava + energy, 那么机械就只会先检查 1 coal + energy => 1 iron 作为配方，当输入物品满足此配方时只会输出1 iron且不会将lava作为输入物品使用，也就是说配方之间会产生冲突。
By default, the mod will sort recipes by the amount & type of input-components needed. So for example a recipe-selection failure like ** explained above would not even happen by default, however you can still run into this problem occasionally.一般情况下，mod会根据配方需要的输入物品的数量和类型对配方进行排序。所以在上面描述的配方匹配失败一般不会发生，如果你碰到了上面描述的问题，我建议你去买**。
Now how to prevent this? Defining a priority for these kinds of recipes. That way you can give the mod a hint which recipes to select/check first and which afterwards. Higher priorities get checked first, lower priorities afterwards. (The order at which the mod checks the recipes is identical to the order they show up in JEI!)所以我们应该动动脑子想一下怎么避免这样的情况?。想必我们都知道优先级这个东西，那么给配方定义优先级就是. 这样，你就可以"告诉"mod哪些配方优先检查，哪些后检查. (JEI的配方预览显示顺序也会被改变!)
Example:
[...]"machine": "...","registryName": "...","recipeTime": 20,"priority": 2,"requirements": [[...]
As shown in the example, the sorting-priority can be defined as integer-number in 'priority'. The priority definition is optional. If no priority is defined, the priority is 0."priority"即为优先级（只接受整数型数字），如果不定义优先级那么"priority"为0.

Custom Machines: Machine Format Position Permutations [Advanced]

自定义机械:机械文件格式的坐标排列设置【进阶】

As described and shown at the end of the Machine Format wiki page, the block-pattern definition for the machine can be very clunky. To help combat that, you can define arrays of positions and the mod will build all permutations over those.和机械文件格式WikiPage末尾所描述的一样用块状机械结构方法定义多方块机械是有够蠢的. 至于怎么解决这个问题，定义位置数组即可，剩下的事mod都帮你干了。
Example from the Machine format page: One part of the block-pattern, the lowest layer, had the following positions:这里是来自机械文件格式的例子: 这是块状机械结构所构造的机械的最下层，每一个方块的位置如下（以中心块为判断点）:

[1, -1, 2], [0, -1, 2], [-1, -1, 2], [1, -1, 1], [0, -1, 1], [-1, -1, 1], [1, -1, 0], [0, -1, 0], [-1, -1, 0]
Now those describe essentially the 3x3 lower "floor" of the machine. y is always -1, x ranges from 1 to -1, z ranges from 2 to 0. Instead of writing entries for all those positions, you can also write:现在呢，这些坐标数组描述的是机械最下层3x3的每一个方块的坐标，y总是-1，x是1到-1，z是2到0.下面的文件描述了机械的3x3的最下层，y总是-1，x是1到-1，z是2到0:
[...]{ "x": [1, 0, -1], "y": -1, "z": [2, 1, 0], "elements": [ "modularmachinery:blockcasing", "modularmachinery:blockinputitem", "modularmachinery:blockinputenergy", "modularmachinery:blockoutputitem", "modularmachinery:blockoutputfluid"}[...]
The mod will build all possible combinations of all coordinates given. So instead of writing 9 entries, you can also just write 1 in this example.mod会建立所给定的坐标能够组成的所有多方块结构机械.因此在这个例子中你也能不写9个entries而只写1个
Let's have another example:来瞧瞧另一个样例:
[1, 0, 2], [-1, 0, 2], [1, 0, 0], [-1, 0, 0], [1, 1, 2], [-1, 1, 2], [1, 1, 0], [-1, 1, 0]
Now this follows a similiar pattern: x is either 1 or -1, z is either 0 or 2, and y is either 0 or 1. All possible combinations/permutations of those are listed above, so you can just write them as follows:现在，这依据以上的类似的模式:x是1或-1 z是0或2 y是0或1.所有可能的结构组合/排列方式在上面均已列出，你可以把它们写成下面的样子。
[...]{ "x": [1, -1], "y": [0, 1], "z": [0, 2], "elements": [ ...}[...]

Custom Machines: Machine Colors

自定义机械:机械颜色

In case orange totally doesn't fit the design of the machine you want to go for (so. like. 99% of the time), you can recolor the machine once the machine controller found the structure of said machine. It will then recolor casings or other blocks of ModularMachinery from orange to the color specified.要是你不喜欢你的机械的颜色设计, 机械控制器发现了机械结构组合了机械后你就可以给机械重新上色. 重新上色后机械结构内的其他模块也会被重新上色.
It can be specified in the machine specification at top level like this:颜色可以在机械结构范围的 top level 中设定例如下:
[...]"registryname": "...","localizedname": "...","color": "dddddd","parts": [[...]
The color specified is a hex color, ignoring the alpha channel. You can easily find the color you want with any hex color picker you prefer.指定的颜色必须用十六进制表达.且要忽略alpha通道（透明度

Custom Machines: Structure To JSON Tool [Advanced]

自定义机械:机械结构到 JSON 转换工具【进阶】

(Marked as "Advanced" because you should know how defining machines manually works, since post-processing after exporting it to JSON is strongly advised.)(将其定义为[进阶]，是因为您应该知晓如何去自定义机器。并且我们强烈建议您在导出的JSON上修改。）
Writing up the JSON for a complex machine manually is a massive time sink and even then it's littered with wrong positions or typos or other potential issues. In order to avoid that, ModularMachinery adds the "Construct Selection Tool", which allows a player (when opped and in creative) to select blocks with it and export them as JSON.为一台复杂的机械编写JSON将会花费许多时间。同时您还有可能会出现错位、字词拼写错误等问题。为了避免这种情况，ModularMachinery添加了“建造选择工具”，允许玩家（在创造模式或op时）用这个工具选择方块并将其导出为JSON。
While in hand, you can with rightlick (or shift-rightclick to avoid rightclick-interactions with certain blocks) on blocks to add them to the current selection, or to remove them from the selection. Once selected, these blocks will show up with a white cube-overlay, indicating that the position where the block is/was at, was added to your selection. You can break the block or place another one in it in order to add something like fluid-blocks (which are normally not right-clickable of course) to the machine-selection.手持“建造选择工具”，对准方块右键单击（或左键单击以避免与某些方块产生交互）来将方块添加到当前的选择项，或者从当前选择项中删除这个方块。当方块（机械结构模块）被选中后，方块将会有“白色覆盖层”的效果，表明您已经选择了这个方块的位置。您可以破坏这个方块，或者在原处放置另一个方块，以便在选择工具中添加类似流体之类不可选中的东西。(流体之类通常不能右键单击来选中）

Once you've selected all blocks you want to add to the structure/machine, you have to rightclick the Machine Controller to "confirm" your selection. The direction in which the controller is facing is very important! Wherever the controller faces towards will be considered the "front"-face of your machine. So be sure to have the controller face the proper direction before shift-rightclicking it with the selection tool.一旦你选择了你想添加到结构/机械上的方块，你必须右键单击“机械控制器”来确认你的选择。记住，控制器的朝向非常重要！控制器所朝向的方向将被视为“正面”。无论控制器朝向哪里，它所朝向的地方都是机器的“正面”。因此，在用选择工具右键单击控制器前，一定要确保控制器朝向正确的位置。
After that, if everything works out successfully, the machine is saved as "machine--.json" into your 'machinery' directory where the other machines are defined. Additionally, your current selection gets purged after that to avoid double-creation or accidentally forgetting to un-select all positions.之后，若一切顺利，机械将会以“machine--.json”的形式被保存在你的“machine”文件夹中，其他机械的文件也储存在这里。同时，保存之后，你之前的所有选择，将会被清除，以此来避免重复创建或不小心忘记取消选择。
Now, post-processing needs to be done, as the mod only saves that 1 specific block + its found state, serialized as metadata, into the json file per position. If the block at the positon had a tileentity, its data will be serialized and saved in the 'nbt'-tag of the position it would need to be at. Unless you want to match against certain entries in this NBT-tag, it's advised to remove the 'nbt'-specification entirely. Adjust the fitting elements per position appropiately to what's reasonable or appropiate for the given machine. (For example allow for stairs that are at corners the metadata for both potential rotations that'd form corner-stairs, so users don't run into the issue that it looks 100% fine, but it has the wrong metadata!)接下来，需要进行"post-processing"。因为模组只把选定的方块以及它的 blockstate 序列化为metadata，并且保存到相应的json文件中。如果这个位置的方块有 tileentity，它的数据将会被序列化，并保存在相应的json文件中。如果文件中的方块已经有了tileentity，它的数据将被序列化并保存在相应的'nbt'-tag中。除非你想与这个NBT-tag中的某些条目相适应，否则我们建议您完全删除'nbt'-specification。适当地调整每个位置的元素，这对于机器来说是合理的。
The JSON for that exported machine also only comes with the "parts"-tag, defining only the raw structure, so adding a "registryname" and "localizedname" and so on is required.该导出机器的JSON文件只有“parts”-tags，目前只定义了多方块结构，所以还需添加"registryname"和"localizedname"等。

Custom Machines: Furnace Fuel as Item Input

自定义机械:将输入物品作为熔炉型机械燃料

As described in the titel of this page: You can also require a certain amount of furnace-fuel burn-ticks as item input. So instead of defining a specific item as input you define it like this:正如标题所说，你也可以将燃烧所需要花费的燃料的燃烧时间来作为物品的输入。因此，你不需要定义一个特定的物品来作为输入，而是像下方这样：
[...]{ "type": "item", "io-type": "input", "item": "any:fuel","time": <burnTimeInTicks>},[...]
"time" must be specified if you specify "any:fuel" as item input. It describes how many burn-ticks the total amount of fuel-items found must provide in order for this to work.如果你指定“any:fuel”作为燃料输入，你必须定义“time”。它描述了物品在已知的燃料下燃烧时所需要的燃烧时间，以便其生效。
As an example, let's say you defined this with the burnTime of 3000. A piece of coal has a burntime of 1600. So in order for this recipe to work, you have to provide 2 pieces of coal in an item input bus. Excess burntime that is provided over the required amount is voided. For example a lava bucket has a burntime of 20000. The recipe only requires 3000 so the other 17000 will basically just disappear.例如，你需要定义物品的燃烧时间为3000。一个煤炭的燃烧时间是1600,。所以为了使这个配方能够生效，你必须提供两个煤炭，其中多余的时间将会作废。（如(1600*2）-3000=200,这个200就会被作废）例如，当一个装有岩浆的桶作为燃料时，它的燃烧时间为20000，因为这个配方只需要3000，所以剩下的17000都会作废。
In order to get the exact burntime of an itemstack, you can either install a mod that provides this information when hovering over the item in the item's tooltip, OR you can hold the item in your hand and execute /mm-hand. This will also display the item's BurnTime in case it has any.为了获得一个物品的准确燃烧时间，你可以安装一个模组，即那种当你鼠标光标放到工具上时会有提示出现的模组。你也可以手持物品，执行命令：/mm-hand如果物品有燃烧时间的话，这个命令也会显示它的燃烧时间。

Custom Machines: Crafttweaker Recipe definitions [Advanced]

自定义机械:Crafttweaker 配方定义【进阶】

So while writing up recipes in JSON is the 'default' way of adding recipes to machines in ModularMachinery, starting from Version 1.8.1 and newer, one can add recipes to machines using Crafttweaker. In the end, the same goals can be achieved, except some features, like defining matching & display NBT-tags for item requirements and the option to define range-checks in such checks (so it would 'pass' the test if some Integer value is >= 1000 or something), are not available.虽然用JSON文件编写配方是为“ModularMachinery”的机械添加配方的默认方式。但1.8.1版本之后，玩家可以用Crafttweaker来为机械编写配方。它同样能达到目的，除了一些功能它做不到，如定义匹配、NBT标签显示，以及在检测中定义检测范围的选项。（所以，如果某个整数值为>=1000或其他，它将通过检测。），这些功能都不可用。
Starting the recipe-add process can be done with the RecipeBuilder class:添加配方的过程中可以用RecipeBuilder类来完成：
mods.modularmachinery.RecipeBuilder.newBuilder("recipeName", "machineName", 100) ...
This returns a RecipePrimer object where further operations can be done on the recipe, such as adding required inputs and adding outputs. A list of available methods can be found in the RecipePrimer class.它将返回一个RecipePrimer对象，可以对配方进一步操作，如添加所需的输入和输出。可用的方法在RecipePrime类中可以找到。For a more detailed explanantion on this, please also check the Crafttweaker documentation on ModularMachinery.关于这个问题更详细的解释，也可以查看ModularMachinery的Crafttweaker文档。#样例（非官方）val vlava_liquid = mods.modularmachinery.RecipeBuilder.newBuilder("j_powermachine_lava_liquid", "j_power_machine", 2000);vlava_liquid.addEnergyPerTickOutput(100);vlava_liquid.addFluidInput(<liquid:lava>*100);vlava_liquid.build();

Custom Machines:Recipe Modifiers [Advanced]

自定义机械:配方修饰符

[Feature added in ModularMachinery version 1.9+][模块化机械于1.9版本之后添加的功能]
As it stands now, a machine can only be built, have its recipes be done and that's it. However, one might want to open up possibilities for the user to "upgrade" the machine to provide more "Secondary output", more energy output, lower chance of consuming input, take less time to do a recipe, [and so on].就目前而言，机械只能遵循机械多方块结构配方来建造。然而，如果魔改作者想给使用者提供“二次升级”的机会就需要用到“配方修饰符”功能了。例如更多的“次级输出”, 更多能源输出,更少的能源或物品消耗,更快的制造速度等升级.The core idea behind recipe modifiers is as follows: 'Instead of placing block "X" at position "x, y, z", you can instead place block "Y" there and gain to your recipes.'配方修饰符需要遵循如下规则：“通过方块“Y”放置于相对于其他方块某个位置来组成配方，而不是通过把方块“X”放在某个“x，y，z”坐标上。”In order for that to work as expected, be sure the blocks you want the user to place at a specific position are different from what the normal machine would require there. So if you allow "any stone variant" to be placed at position "1, 2, 1" BE SURE that the block you have to place at "1, 2, 1" to gain a specific modifier isn't any stone variant! Or in a more general sense: Be sure that the block you want the user to place in order to get a modifier isn't a subset of the block(s) normally placed on that position. The results if the user gets the modifier or not are not determined and can flip back and forth. This might lead to unstable system behavior and add overall load to the server.为了使工作达到预期，确保你想让使用者放置的方块被放置在一个特殊的位置且不同于一般机械所要求的摆放方式。所以，如果你要求任意一个“石头变种方块”被放置在坐标“1, 2, 1”上，请确保你放置在坐标“1, 2, 1”的方块是为了获取特殊修饰的方块而不是任意石头变种方块！更通俗的来说：确保你想让使用者为了获得一个特殊修饰而放置的方块没有放在一个通常放在那个位置的方块的subset（map 节点里面的一个子节点，这将会在地图上的一个特定的位置，查看自位置中心指定大小的圆形区域，而不是查看整张地图。）内。无法确定用户想要组成多方快机械的某个方块是否被修饰而使程序反复进行检测。这可能使系统运行不稳定并加大服务器负担With that in mind, let's have a look at how modifiers are specified and what they can do.考虑到这点，让我们看看如何指定修饰符并得知他们能做什么。Modifiers have to be defined in the machine definition. So as an example going forward, the machine "alloy_furnace", that is shipped as a default/example machine together with ModularMachinery, is used.修饰符必须在机械定义中明确定义。示例如下,机械"alloy_furnace"被运行时,该机械会作为默认或示例机械和模块化机械一同运行
{ "registryname": "alloy_furnace", "localizedname": "Alloy Smelter", "modifiers": [ { "elements": "modularmachinery:blockcasing@1", "x": 0, "y": 1, "z": 0 } ], "parts": [ { ... },[...] { "x": 0, "y": 1, "z": 0, "elements": "modularmachinery:blockcasing@2" },[...]So, as seen there, one part of a 'modifier' is just as the default elements in the "parts" array, just a block-definition which describes an offset and the block that needs to be placed there in order to "match". This can either be just a string defining one Blockstate, an array of blockstates or a blockstate-variable. How those definitions are supposed to be written should be clear by now. If not, please lookup the wiki pages on basic machine definitions.所以如你所见，"modifier"的一部分与"part"数组中的默认元素相同, 其用于定义放苗坐标偏移和匹配应放置的方块。它也可以用于定义方块状态字符串，方块状态数组和方块状态变量。现在这些定义的使用方法你已经很清楚了，如果还不是很明白，那请查阅wiki的基础机械定义页面。
However, now the user has no way of knowing which block(s) need to be placed where in order to get a modifier. So, a 'description' needs to be added so the user can know where to replace what. The mod can't do this on its own as a auto-generated description might be too long or too complex to understand for the player.然而，现在玩家仍然无法知道该在哪里放置方块来获得修饰符。因此，我们需要添加描述（"description"）来让使用者得知什么地方该换成什么方块。模组本身不能独自做到这点，因为自动生成的说明可能过长，复杂，令玩家难以理解。

[...]
"localizedname": "Alloy Smelter",
"modifiers": [
{
"elements": "modularmachinery:blockcasing@1",
"x": 0,
"y": 1,
"z": 0,
"description": "Replace block above controller with machine vent!"
}
],
"parts": [

A description can be added as shown in the example above. This should make it clear to the user what he has to do. The mod displays the description text below a preview of which block is needed to be placed to fulfill the modifier's conditions so as a pack maker you don't need to specifically name that block again. Additionally, this description should also include a short line as to what the modifier actually does, so the user knows about its effects! New-Lines are supported with '\n'. 可以通过以上示例的方法来添加描述。这可以让使用者明白他必须做什么来实现修饰符的。这个模组会在需要放置方块来满足修饰符条件的位置的方块预览下展示说明文字。此外，描述最好还包含一行短文来说明修饰符的实际作用来让使用者了解其功效。可以用“\n”来创建新行。

The description tag is optional (version 1.9.6 and newer) and if none is supplied, the replacement will not be explained/shown in the preview gui.描述Tag（"description"）为可选内容(1.9.6 版本之后)。若没有提供描述，预览界面则不会解释/展示修改内容。
Now with the "replacement" part in place, the actual modifier can be defined:现在”replacement“部分准备就绪，修饰符能真正被定义了：
[...]"localizedname": "Alloy Smelter","modifiers": [ { "elements": "modularmachinery:blockcasing@1", "x": 0, "y": 1, "z": 0, "description": "Replace block above controller with machine vent\nfor double item output!", "modifier": { "io": "output", "target": "item", "operation": 1, "multiplier": 2.0 } }],...That is done in the "modifier" tag. A modifier needs multiple things:这在"modifier"Tag中完成。一个修饰符需要很多部分内容

"io":

Defines the I/O-type of the recipe-component it should target. Can be either "input" or "output" and thus will target components handling input or output.定义它所针对的配方的 I/O类型。能作为“输入”或“输出”，因此将其用于处理“输入”或”输出“的组件

"target":

Defines the type of recipe-component it should target. This can be either "item", "energy", "fluid", "duration" (for recipe processing time) or (if you have mekanism installed and gas-components) "gas". Addons like "Modular Diversity" can add other 'targets' that might have different names, such as "mana" or whatever the addon provides.定义它所针对的配方的目标类型。目标类型可以是“物品”，“能量”，“液体”，“工作时间” （处理配方所需时间），“气体”(通用机械模组及其气体附属模组)。“模块多样性”这样的模组还能添加其他可能具有不同名字的目标类型。例如“魔法”或其他任意模组所添加的目标类型

"operation":

Defines the type of operation that should be applied. Possible operations: 0 = Addition, 1 = Multiplication. All "addition" modifiers will get added up before being applied to the actual value; All "multiplication" modifiers will be multiplied with each other before being applied to the actual value.定义操作类型。可能使用到的操作有：0 = 加法, 1 = 乘法。加法和乘法修改器都会在实际值被应用前运行。

"multiplier":

Defines the actual value that will be added or multiplied to the recipe-component's number.定义被应用于配方成分的加法，乘法的数字的实际值。

"affectChance": [可选]

This was not defined in the example above. Can be either "true" or "false". Defaults to "false" if not defined. Defines if the multiplier should be applied to the recipe-component's chance instead of the actual value. (So for example the multiplier 2 with operation "multiply" should be applied to an item output's chance instead of its actual itemstack-amount. So if an item that has stacksize 3 would be output'ted with a chance of 0.4 / 40%, instead of multiplying its stacksize with 2, the chance that it would be produced is multiplied with 2; So when the modifier is applied, the chance of producing the item with stacksize 3 is 0.8 / 80% instead of 0.4 / 40%)在以上示例中没有定义此项。其可以为“true”或 “false”。若没有定义，则默认为“false”。定义乘数是否被应用于配方成分的不是实际值(例如，乘数 2 应用于物品输出而不是其实际物品堆叠数量。该修饰符不是将其物品堆叠数量乘2，而是将它的输出概率概率将乘2。所以，如果一个物品的堆叠量为3，输出概率是0.4/40%，当修饰符被应用时，该生产堆积量为3的物品的生产概率为0.8/80%，而不是0.4/40%)EXAMPLES: That was a lot of information. Some things are easier to understand with examples, so here are a few "modifier" tags and explanations as to what they will do to recipes if the modifier-condition is fulfilled for the machine.举例：这都是很有用的信息。一些东西通过例子来理解会更加容易。所以这有一些"modifier" tags和解释，来说明若机械的修饰符条件被满足，他们能起到怎样的功效。
1."modifier": { "io": "output", "target": "item", "operation": 1, "multiplier": 2.0}The amount of item outputs that are produced by this machine is multiplied with 2.该机械的物品生产产出乘2。
2."modifier": { "io": "input", "target": "item", "operation": 0, "multiplier": -0.2, "affectChance": true
}The chance that an item is consumed as input is added with -0.2; So the chance gets lowered by 0.2 / 20%.输入物品被消耗的概率-0.2；所以物品被消耗的概率会降低0.2 / 20%。

3."modifier": { "io": "output", "target": "energy", "operation": 1, "multiplier": 1.5
}
The amount of energy that is produced gets multiplied by 1.5; In other words: is increased by 50%.能量生产产出乘1.5。换句话说就是能量生成量增加50%。4.
"modifier": {
"io": "output",
"target": "fluid",
"operation": 0,
"multiplier": 50
}
Any fluid that this machine produces/outputs is increased by 50mb. (Addition with 50)该机器生产/产出的任何液体都会增加50mb。（通过加法来加50）
5."modifier": { "io": "input", "target": "item", "operation": 1, "multiplier": 0, "affectChance": true}The chance that an item is consumed as input is multiplied by 0. In other words: No items are consumed as inputs for any recipe.输入物品被消耗的概率乘0.换句话说就是该配方不需要消耗任何输入物品。

更多的橡胶树

Eicy

本帖最后由 Eicy 于 2022-11-22 09:50 编辑

贡献名单:
Eicy:Home 6 7 8
垠儿:1 2 3 4
Citysands:9 10 11 12
喵鱿:5 13
MCBBS Wiki:https://mcbbs-wiki.cn/wiki/ModularMachinery_Wiki

沉默-无言

谢谢版主的分享

z177058_IkKhk

厉害啊版主，多谢分享

明月猫123

非常好用了

喵鱿

好耶！大家都好给力！

小黑与小白的事

谁能来救救我啊！！！
来个大佬帮帮我吧

23345shx

aaaaaaaaaaaaaaaaaaa

渔夫先生

感谢汉化贴

482747363

原文链接显示网页错误是什么原因

245786437

锁了呜呜呜

Eicy

245786437 发表于 2022-6-17 10:20
锁了呜呜呜

https://mcbbs-wiki.cn/wiki/ModularMachinery_Wiki
本来想润色但因为锁帖没办法编辑了，你可以去这里看润色后的。

qq1066742109

404了这个教程还有么

Eicy

qq1066742109 发表于 2022-7-29 13:57
404了这个教程还有么

https://mcbbs.wiki/wiki/ModularMachinery_Wiki(ZH)

hjc337467981

ae能源不就好了？

奥利奥i

这么好的帖子为什么要锁了还废我一张挖掘卡