后浪云Minecraft Wiki教程：总指南[ ]
此特性为基岩版独有。
目录
- 1 总指南
- 2 定义文件
- 3 函数
- 4 命令
- 5 模型
- 6 声音
- 7 UI
- 7.1 修改UI示例
- 7.1.1 示例1: 减少变量
- 7.1.2 示例2: 继承
- 7.1.3 示例3: 修改子控件
- 7.1.4 示例4: 修改数组
- 7.1 修改UI示例
- 8 世界
- 8.1 生物
- 8.2 红石
- 8.3 常加载区域
- 9 参见
此处提供的指南是为了使创作者得到为Minecraft创作内容时的较好体验的一种最佳操作。它将有助于确保作品可以工作，并且在应对游戏中的变化时具有高效性和弹性。
总指南[ ]
- 从世界和包的目录中移除所有与内容无关的文件。
- 不要在包中存放包，或存放Windows或Photoshop文件。它们中的任意一种都会在读取、导入或加载内容时导致出错。
- 在发布之前从内容中移除任何未使用的资源。
- 这能够保证在将内容缩减到最小的同时减少内容验证失败的可能性。
- 此外，如果原版文件被修改，这样做对你的内容来说不会造成意外的更改。
- 不同的平台有不同的路径长度限制。算上包或世界的路径，平台会计算导入到Minecraft里的目录长度。如果长度超出限制，包会导入失败并且会变成无效状态。正因如此，我们建议：
- 保持路径长度为70字符或更少，即从包或世界模板的根目录到一个文件的最长路径长度应该只能有70字符长。
- 路径中的每一部分（目录或文件名）必须小于60字符。否则，一些平台将无法识别这一部分。
- 资源包或行为包的目录名应该小于10字符长。这样可以使创作者可以写更长的文件或子目录名。例如，
bp_mw有如下目录：MyWorld/behavior_packs/bp_mw
定义文件[ ]
- 例如
blocks.json、mobs.json、sound_definitions.json以及其他位置的定义文件包含了原版中所有元素的定义。请确保你的包只包含那些需要更改的元素和字段。这意味着：不要直接复制/粘贴所有原来的定义，然后只更改需要更改的那一段，而是仅需要保留文件中需要更改的那一段。游戏会自动将这些更改与原版的文件合并。- 如果需要更改的之外的某些部分也被留在了文件中，而原版的方块或生物在游戏版本更新时发生了更改，那么那一段就会造成内容里不必要的变更。
以下文件不应该改写，除非你有意更改此内容。它们还没有获得官方的支持，但是如果你的修改可行，也可以在至少同版本正常运行。 因此无法保证所做的更改会正常工作或在未来依旧能工作。
credits/end.txtfont/emoticons.jsontexts/language_names.jsonitems_client.jsonitems_offsets_client.json- shaders目录里的任何文件
注:shaders文件夹内文件为HLSL或GLSL语言编写
函数[ ]
- 使用子目录来创建命名空间，以避免多个行为包的函数文件之间的冲突。如果一个函数的路径（以/functions/subdirectory开头）与另一个包一个函数的路径完全吻合，那么在包栈中靠近顶部的包会覆盖其他的包。
- 为了减少你的函数在特定平台上无法工作的概率，请用使用小写字母且不留空格的方式来命名你的目录和函数文件，例如/functions/awesome_pack/level1_function.mcfuntion。
- 请谨慎地使用递归。尽管递归是支持的，当递归很深的时候它依旧会导致一些性能问题。
- 在你行为包清单文件的“min_engine_version”之后输入你当前开发所处的游戏版本，例如"min_engine_version" : [1,8,0] 。
- 这样你就可以控制使用哪个版本的命令来保证向后兼容性。
- 如果你的命令方块只运行函数，那么修改他们就会变得简单很多。更重要的是，如果你发布了一个包含函数文件的新的行为包，那么使用那个行为包的世界也会在新包应用时立马得到更新。
- 最后一个关键点是说明性的：当前的基岩版尚未支持条件分支（例如execute (if unless)），但是它可能会在未来加入到游戏中。
命令[ ]
- 请避免每刻都执行命令。尤其重要的是不要每刻都执行大量的命令。
- 尽量不要在每刻执行超过30条命令。
- 如果需要频繁执行命令，可以考虑把它们放到一个时钟循环里，这样它们可以每5+刻执行一次。
- 如上面所说，如果你设置了偏置时钟使得命令在不同的刻上执行，那么就可以平衡你的工作并获得更佳的性能。
- 获知你内容的性能是否是由于命令过多而表现不佳的一个简单方法就是使用commandblocksenabled游戏规则来关闭所有命令方块的执行。
- 请尽可能地不要使用长时命令（例如覆盖区域很大的/clone或/fill）。如果可以的话，请把它分开并在不同的刻执行。
- 不要在目标选择器中使用物品的本地化名字，例如/testfor @e[name=beacon]。
- 如果玩家来自不同语言区，那么物品的名字可能会改变而后命令将无法工作。
模型[ ]
- 具有许多微小部件的模型在低端设备和某些GPU上性能可能会很差。请在细节与性能之间推敲出适当的平衡。
声音[ ]
- 在流上只播放长时声音，例如背景音乐。
- 可以获得游戏内更佳的性能。
- 一些平台在同一时间只能打开一定数目的文件，在流上播放所有的声音可能会因内容过多而导致游戏崩溃。
- 短时声音（例如音效）在内存上加载会有最佳性能。
- 使用一些小技巧来缩小你的文件，例如从开头和结尾移出所有的静音部分
- 有一个标识load_on_low_memory可以用于声音的定义里。这个标识默认设为false，这意味着如果此时计算机内存较低，它就不会再载入任何声音。如果对于某个特定的声音来说，它必须得到载入，那么就把这个标识设为true。请权衡利用这一特性。
- 基岩版音效文件为FSB格式，如果条件有限，可以转码成OGG格式后直接重命名成FSB文件。
UI[ ]
- 所有UI的修改都是有风险的。如果原版的界面以某种形式被修改，那么使用这个界面的内容就有可能崩溃。UI系统是以一种有助于我们能灵活地通过JSON文件修改界面的方式设计的。任何对UI的JSON文件的更改（在一个自定义的资源包里）都会和原版的文件合并。如果合并过程不正确则游戏可能会进入一种不佳状态。
- 重新绘制UI贴图，即修改他们所使用的纹理，这样风险就会小很多，并且能做出一些更漂亮的元素。
- 重新编辑元素的尺寸以及移动它们风险更大，但是在大多数情况下还是可行的。
- 改变一个界面中的元素本身具有破坏性的高度风险。
修改UI示例[ ]
下面是一些示例，它们介绍了如何在不完全复制整个界面的前提下修改一个UI定义文件。下面以附魔台界面文件（enchanting_screen_pocket.json）的一部分为例。
示例1: 减少变量[ ]
不要包含那些无需更改的变量。例如，如果"color"和"shadow"是要更改的，那么就不要把其他的变量复制/粘贴到这里。只需要声明那些需要替换的变量就可以完成简单的所需要的更改。
不佳的复制/粘贴法：
"generic_label": { "type": "label", "color": "$pocket_title_text_color", "anchor_from": "center", "anchor_to": "center", "shadow": false },
更好的例子：
"generic_label": { "color": "$pocket_title_text_color", "shadow": false },
示例2: 继承[ ]
无需重新声明正在修改的控件所继承自的控件。仅声明正在修改的控件名即可。在下面的代码中，"common.button"就可以跳过不写：
不佳的例子：
"[email protected]": {
较好的例子：
"enchanting_confirm_button": {
示例3: 修改子控件[ ]
以同一个按钮为例，如果只需要修改该控件的子控件中的一些特定的变量，例如，default控件。仅修改一个控件的子控件请使用control_name/child_name语法。所以与之这样写：
"[email protected]": { "controls": [ { "default@enchanting_pocket.confirm_default_control": { "type": "image", "texture": "textures/ui/button_borderless_light" //Added fancy button texture to default control } } ] },
不如这样写：
"enchanting_confirm_button/default": { "texture": "textures/ui/button_borderless_light" //Added fancy button texture to default control },
示例4: 修改数组[ ]
这个示例将展示如何修改一个控件中的数组。例如：添加一个新的控件作为子控件或从一个控件的绑定中移除一个绑定。就该例来说，有一个叫"modifications"特殊的变量。对modifications数组里的每一条记录，可以指定一个特定的数组去修改、操作并输出结果。
以"enchanting_book_panel"为例，如果需要在"controls"数组里添加一个控件，就可以添加一个modifications数组，数组中指定了"array_name": "controls"、"operation": "insert_front"和"value"，其中最后一个中可以填入新的控件，新控件就会如同被放到了controls 数组里一样。下面的例子展示了上面所说的内容以及偏移量的更改。
"enchanting_book_panel": { "offset": [ -4, 1], "modifications": [ { "array_name": "controls", "operation": "insert_front", "value": [ "panel_outline@beacon_pocket.panel_outline": { "layer": 0 } ] } ] }
要从"player_level_label"子控件中移除"#player_level_color"绑定，可以进行如下操作：
"enchanting_book_panel/player_level_label": { "offset": [ 0, 10 ], "layer": 3, "color": "$experience_text_color" "modifications": [ { "array_name": "bindings", "operation": "remove", "where": { "binding_name": "#player_level_color" } } ] }
世界[ ]
生物[ ]
- 不要一次生成过多的实体。根据设备的不同，如果在同一时间有过多的实体更新，性能可能会很差。
红石[ ]
只要有可能，就一定不要让红石元件在区块边界处交互。
- 游戏是有能力处理大部分这种情况的，然而，的确有些例子表明当区块的加载和红石元件更新发生矛盾时，的确会引起一些元件失去它们状态并破坏电路直到它们被重新放置。
- 红石元件包括所有可以产生、传递或消耗红石信号的方块，例如：
- 按钮
- 命令方块
- 比较器
- 发射器
- 漏斗
- 拉杆
- 侦测器
- 活塞
- 铁轨：激活型、探测型和充能型
- 红石线
- 中继器
- 以及其他
常加载区域[ ]
- 不要过度使用常加载区域。
- 这对低内存设备尤其重要。
- 如果可以，在不使用常加载区域时请卸载它们。
- 这可以使得设备回收一些内存，也可以为所需要的新的常加载区域腾出空间。
参见[ ]
- 附加包
- 基岩版附加包文档
- 基岩版实体文档
- 基岩版动画文档
- 基岩版粒子文档
- 基岩版Molang文档
- 基岩版模式文档
教程（作下划线标记的教程为中文独有教程） |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
版权声明：
作者：后浪云
链接：https://www.idc.net/help/186991/
文章版权归作者所有，未经允许请勿转载。
THE END