企业官网建设流程全解析

• 低代码
• 代码生成
• 桌面应用
• 游戏开发

导读

本文围绕 MCreator 生物实体（Living Entity）编辑器中的"可在水下呼吸"逻辑条件（entry 键entity/condition_can_breathe_underwater，中文界面显示为"可在水下呼吸"）展开，说明它在实体编辑器中的位置、配置方式、与"水生实体"参数的联动关系，并结合仓库源码剖析它最终如何被编译进 Minecraft 实体 Java 代码（canDrownInFluidType/canBreatheUnderwater）。读完本文，你将掌握如何为一个自定义生物开启/关闭无限水下呼吸能力，并理解其底层生成逻辑与版本差异。

一、这个条件是什么

MCreator 本地化帮助文档（德语版）对condition_can_breathe_underwater的原始描述为：

Wenn diese Bedingung wahr ist, kann die Entität auf unbestimmte Zeit wie Fisch oder Tintenfisch atmen.

即：当此条件为真时，该实体可以像鱼或鱿鱼一样无限制地在水下呼吸。英文版帮助文件 condition_can_breathe_underwater.md 给出了相同的定义："When this condition is true, the entity will be able to breathe underwater indefinitely like fish or squids."

这是一个"逻辑条件"（Logic Procedure）类型的设置，而不是一个简单的布尔开关——它既可以勾选一个固定值，也可以绑定一段完整的程序（Procedure），用任意复杂的判断逻辑（例如"仅当实体处于特定生物群系、持有某物品、或世界处于白天时才可呼吸"）来决定结果。与之对应，各语言文件中的界面文案如下：

注：本篇所依据的关联文档位于德语帮助目录 plugins/mcreator-localization/help/de_DE/entity/condition_can_breathe_underwater.md，该目录下的全部帮助页与英文版内容一一对应，共同构成 MCreator 内置的界面帮助体系。

二、在实体编辑器中的位置与配置方式

在 MCreator 中，打开任意"生物实体"（Living Entity）类型的模组元素编辑器，向下滚动到"行为设置"区域，即可看到该条件控件。其 UI 定义位于编辑器实现类 LivingEntityGUI.java：

breatheUnderwater = new LogicProcedureSelector(this.withEntry("entity/condition_can_breathe_underwater"), mcreator, L10N.t("elementgui.living_entity.condition_can_breathe_underwater"), AbstractProcedureSelector.Side.BOTH, L10N.checkbox("elementgui.common.enable"), 0, Dependency.fromString("x:number/y:number/z:number/world:world/entity:entity"));

从这段源码可以提取出该条件的四个关键特征：

1. 类型为LogicProcedureSelector：它是一个"逻辑程序选择器"，用户既可以给一个布尔常量（勾选框），也可以挂接一个返回逻辑值的程序块。
2. 生效侧为Side.BOTH：该条件同时在服务端（Server）与客户端（Client）逻辑中生效。
3. 默认固定值为0（false）：新建实体默认不可在水下呼吸。
4. 可用依赖参数：x:number / y:number / z:number / world:world / entity:entity——即实体所在位置坐标、所在世界以及实体本身，这些变量会作为程序块的输入供条件逻辑使用。

实体模型中对应的数据字段为 LivingEntity.java 中的public LogicProcedure breatheUnderwater;，与waterMob（水生实体）、pushedByFluids（流体可否推动）相邻定义，三者共同描述生物与水的交互行为。

三、配置步骤速览

1. 在 MCreator 工作区中新建或打开一个"生物实体"模组元素；
2. 在"行为设置"中找到"可在水下呼吸"选项；
3. 直接勾选（固定为true），或点击程序选择器挂接一个返回逻辑值（true/false）的程序；
4. 若挂接程序，可使用x、y、z、world、entity依赖构造动态判断；
5. 保存并生成代码，编译后进入游戏验证：条件为真时实体浸入水中不会消耗氧气值，也不会溺水窒息。

典型的挂接程序场景示例：制作"进入特定维度才可在水下呼吸的鱼人"、"只有持有呼吸药水效果才不溺水的生物"，或在条件中使用 entity_get_oxygen 等程序块做更精细的呼吸模拟。

四、与"水生实体（waterMob）"参数的联动

该条件与编辑器中的"水生实体"复选框（help/en_GB/entity/water_entity.md）存在自动联动关系。勾选"水生实体"后，MCreator 会自动把"可在水下呼吸"固定为真，同时把"流体可否推动"固定为假，见 LivingEntityGUI.java：

waterMob.addChangeListener(_ -> { if (!isEditingMode()) { breatheUnderwater.setFixedValue(waterMob.isSelected()); pushedByFluids.setFixedValue(!waterMob.isSelected()); } });

需要区分两个概念：

• 水生实体（waterMob）：使实体拥有水生导航器与水运动控制器，并允许世界生成器在流体中生成它（参见 water_entity.md），但它本身不会让实体"不会溺水"；
• 可在水下呼吸（breatheUnderwater）：专门控制实体能否无限期在水下呼吸，防止溺水。

因此，对于鱼、鱿鱼这类完全水生的生物，二者通常同时开启；而对于只在潜水时想免除氧气消耗的陆地生物，可以只开启"可在水下呼吸"而不勾选"水生实体"。

五、底层生成原理：条件如何进入实体代码

"可在水下呼吸"最终由代码生成器（FreeMarker 模板）编译进实体的 Java 源文件。以 NeoForge 1.21.1 生成器为例，模板 livingentity.java.ftl 中：

<#if data.breatheUnderwater?? && (hasProcedure(data.breatheUnderwater) || data.breatheUnderwater.getFixedValue())> @Override public boolean canDrownInFluidType(FluidType type) { double x = this.getX(); double y = this.getY(); double z = this.getZ(); Level world = this.level(); Entity entity = this; return <@procedureOBJToConditionCode data.breatheUnderwater false true/>; } </#if>

其逻辑是：只有当该条件被设置（非空）且最终结果为真（挂接了程序，或固定值为 true）时，才生成canDrownInFluidType的重写方法；方法内部把x/y/z/world/entity依赖注入条件程序，并将程序返回值作为方法返回值。Minecraft 原版通过该钩子判断实体是否会在对应流体类型中溺水——返回false即不溺水，实体可无限水下呼吸。

NeoForge 26.3（较新版本）的额外处理

在 NeoForge 26.3 生成器模板 livingentity.java.ftl 中，除了同样的canDrownInFluidType生成逻辑外，还额外生成canBreatheUnderwater方法，并带有明确的注释：

<#-- Fix #6456 - NeoForge did not patch canDrownInFluidType yet, so we also need use canBreatheUnderwater --> @Override public boolean canBreatheUnderwater() { return !this.canDrownInFluidType(NeoForgeMod.WATER_TYPE.value()); }

这是对上游问题 #6456 的兼容性修复：较新版本的 NeoForge 尚未完整打通canDrownInFluidType的补丁链路，因此 MCreator 额外重写canBreatheUnderwater()，通过"是否在水中可溺水"的取反来间接表达"能否在水下呼吸"，保证生成代码在目标版本上行为一致。这提醒读者：同一条件在不同 Minecraft 版本生成器下的落地方式可能不同，但最终语义（条件为真 → 无限水下呼吸）保持一致。

六、历史转换与旧作品兼容

该条件字段并非自始存在。仓库中的转换器 WaterEntitiesConverter.java 记录了 2023.4 版本（workspace 版本号 55）引入该字段时的迁移策略：

if (entity.waterMob) entity.breatheUnderwater = new LogicProcedure(null, true); else entity.pushedByFluids = new LogicProcedure(null, true);

即：旧版作品中勾选了"水生实体"的生物，在升级工作区后会自动获得"可在水下呼吸 = true"；而未勾选"水生实体"的生物则自动获得"流体可否推动 = true"。这一自动迁移保证了旧作品的生成代码行为与升级前一致，也印证了"可在水下呼吸"在 2023.4 之后是独立于 waterMob 的正式配置项。

七、常见问题与注意点

• 为什么勾选了水生实体，实体仍然溺水？请检查"可在水下呼吸"是否被后续手工改回了 false。由于联动仅在"非编辑模式"下触发（!isEditingMode()），编辑已有实体时不会覆盖你已经手动设置的值。
• 条件程序返回什么才生效？生成器要求程序结果为逻辑值（true/false）。返回true→ 不溺水、可无限呼吸；返回false→ 正常溺水机制生效。
• 该条件与"流体可否推动"的区别？"可在水下呼吸"控制的是氧气与溺水；"流体可否推动"（isPushedByFluid，见 livingentity.java.ftl）控制的是水流是否推动实体。二者在水生生物身上通常分别设为 true / false，但用途完全不同。
• 水生生物标签：若实体的mobCreatureType设为 WATER，生成器会自动为其添加minecraft:aquatic实体标签（见 livingentity.definition.yaml），这会影响游戏内相关机制对该实体的识别，但与"水下呼吸"条件是两条独立路径。

八、总结

"可在水下呼吸"是 MCreator 生物实体编辑器中一个以"逻辑条件"形式存在的行为开关：固定值为 true 时实体像鱼与鱿鱼一样无限期水下呼吸，挂接程序时则可用x/y/z/world/entity依赖构造动态判定。它由 LivingEntityGUI.java 提供界面、由 livingentity.java.ftl（及 26.3 版本的 增强实现）编译为实体方法，并通过 WaterEntitiesConverter 与旧版工作区无缝衔接。理解这一条件的界面配置与代码生成路径，即可为你的自定义生物精确设计水下生存行为。

• 低代码
• 代码生成
• 桌面应用
• 游戏开发