Add pipe block

[Gu-ZT]

• [TODO] 流体管道 #3209

[github-actions]

Reasoning Details

我们收到了一个巨大的diff，包含大量文件更改。作为代码审查助理，需要识别潜在问题并提供改进建议。主要变更包括：

1. 新增管道（pipe）和泵（pump）相关的内容：语言文件、模型、配方、进度、标签等。

2. 批量更改package-info.java：将导入从 net.minecraft.MethodsReturnNonnullByDefault 改为 com.mojang.logging.annotations.MethodsReturnNonnullByDefault，并添加 @FieldsAreNonnullByDefault 注解。

3. 代码格式化：HudTooltipManager.java 等文件的代码格式调整（if语句加括号）。

4. 在 CapabilitiesEventListener.java 中注册了 PIPE_NODE 的流体能力。

5. 在 RegistrumItemRecipeLoader.java 中添加了 pipe 和 pump 配方方法。

6. 在 ModItems.java 中添加了 PIPE 物品定义，以及调整了一些代码格式化（例如换行、缩进）。

7. 添加了 pump.json 的配方？但 diff 中并没有看到 pump 物品的注册，只有 pipe 物品的注册。但注意 pump 的配方被添加了，但 pump 物品似乎没有在 ModItems.java 中注册，只看到 pipe 注册。这可能是一个问题：pump 配方存在，但对应的物品可能尚未注册或遗漏？检查 ModItems.java 中只添加了 PIPE 的注册，没有 PUMP。而在 RegistrumItemRecipeLoader.java 中有 pump 方法，但可能没有对应的物品。这可能是个错误。

8. 语言文件中有 block.anvilcraft.pipe_corner, pipe_node, pipe_straight, block.anvilcraft.pump 等，但 pump 的 block 对应可能存在，但 pump 在物品中未出现。可能存在 ModBlocks 中注册了泵方块，但此处没有显示。需要评估是否遗漏注册。

9. pipe 作为物品被添加，并注册了配方（16个 pipe 对应于 5 个黄铜压力板？），但 pipe 物品是 PipeBlockItem，它通常用于放置管道方块。但语言文件中出现了 pipe_corner, pipe_node, pipe_straight 这些方块，猜测管道有多个变种方块，而物品 pipe 可能是通用管道物品。需要确认 PipeBlockItem 的行为是否处理了放置不同方向/类型的管道方块。可能没有已知问题。

10. 大量 package-info.java 的批量更改，从 net.minecraft.MethodsReturnNonnullByDefault 改为 com.mojang.logging.annotations.MethodsReturnNonnullByDefault。这似乎是一个错误的导入？因为 com.mojang.logging.annotations 可能不是一个公共 API 包，通常应该使用 net.minecraft.MethodsReturnNonnullByDefault。这个更改可能导致编译错误或运行时的注解处理错误。这是严重问题。

11. ICustomDataComponent.java 中移除了一行空行，没有实质变化。

12. HudTooltipManager.java 中只是格式化代码（加括号），没有逻辑变更，但可以接受。

13. CapabilitiesEventListener.java 中增加了 PIPE_NODE 的流体能力注册，这可能正确。

14. ModItems.java 中做了大量格式化，以及重新排序了 MELT_GEM_BUCKET 的位置，添加了 PIPE，但在 static 块中设置了默认创造选项卡为 ANVILCRAFT_FUNCTION_BLOCK，但只注册了 PIPE，没有 PUMP。另外，PIPE 的模型生成使用了 AnvilCraft.of("block/pipe")，但之前添加了 pipe.json 模型文件，所以没问题。

15. RegistrumItemRecipeLoader.java 中 pipe 配方使用 ModBlocks.BRASS_PRESSURE_PLATE.asItem()，这是否与 brass_pressure_plate 一致？检查配方 JSON 中使用了 anvilcraft:brass_pressure_plate，正确。pump 配方使用了 Blocks.PISTON 和 Items.IRON_BLOCK，但注意 pump 物品尚未注册。

主要问题：

• 大量 package-info.java 使用了错误的注解导入，可能破坏构建或产生警告。
• pump 配方存在但缺少对应物品注册（或 pump 方块/物品在其他地方注册了？但 diff 中没有看到）。需要确认是否遗漏。
• 管道相关方块（pipe_node, pipe_corner, pipe_straight）的注册未在 diff 中出现，但语言文件中有，所以可能在其他地方注册了，但当前 diff 不完整。这不是问题，但需要注意这些方块是否被正确注册。
• pipe 物品的配方中，group 设置为 ctx.getId().toString()，这可能导致组名与预期不符？但可能是正确的。

此外，注意 en_ud.json 文件末尾换行符被移除（\ No newline at end of file），可能导致文件格式差异，但通常不是大问题。

其他问题：检查 RegistrumItemRecipeLoader.java 中 pipe 和 pump 方法：它们被声明为 public static <T extends Item> void pipe(...)，但使用时似乎通过方法引用 RegistrumItemRecipeLoader::pipe 传递，这要求方法签名正确匹配 NonNullBiConsumer<DataGenContext<Item, T>, RegistrumRecipeProvider>，看起来没问题。pump 方法也是类似。

但是，pump 配方中使用了 AnvilCraftDatagen.hasItem(MOD_BLOCK)，但在代码中并没有定义 AnvilCraftDatagen.hasItem？实际上它调用了 AnvilCraftDatagen.hasItem(ModBlocks.BRASS_PRESSURE_PLATE) 和 AnvilCraftDatagen.hasItem(Items.PISTON)。AnvilCraftDatagen.hasItem 可能是一个静态方法，应该存在。但确认一下是否被导入？在 RegistrumItemRecipeLoader.java 中没有看到 AnvilCraftDatagen 的导入，但可能其他的方法已经使用了，所以没问题。

建议：

• 检查 package-info.java 的更改是否必要，还原为 net.minecraft.MethodsReturnNonnullByDefault，或者确认新导入是否正确（但 com.mojang.logging.annotations 是 Mojang 的内部注解，可能不推荐在 mod 中使用，除非有特殊理由）。
• 确保 pump 物品或方块被正确定义（如果它们是计划中的，但当前未完成，应移除配方或补齐注册）。
• 检查 pipe 物品的 group 设置，使用简单字符串如 "anvilcraft:pipe" 可能更好？现有代码 ctx.getId().toString() 会产生类似 anvilcraft:pipe，但 group 通常是一个简单的分类字符串，可能不需要带命名空间，但这样也可以。没有明确问题。
• 对于 en_ud.json 的末尾换行符丢失，虽然不是大问题，但建议保持原样以符合 JSON 规范（有换行符更标准）。但既然之前有结尾换行符，现在被移除，可能是误操作。建议保留换行。

总结：主要问题是 package-info.java 的批量错误导入和 pump 物品的缺失。此外还有一些细微风格问题。

代码审查报告

1. 严重问题：package-info.java 中错误导入注解类

文件：大量 package-info.java（约50个文件）

问题：将 import net.minecraft.MethodsReturnNonnullByDefault 替换为 import com.mojang.logging.annotations.MethodsReturnNonnullByDefault，并新增 @FieldsAreNonnullByDefault 注解。

原因：

• com.mojang.logging.annotations 是 Mojang 内部使用的注解包，并非公开 API，在 mod 开发中直接使用可能导致编译错误或运行时注解处理失败。
• Minecraft 官方推荐使用 net.minecraft.MethodsReturnNonnullByDefault 和 net.minecraft.FieldsAreNonnullByDefault（但 FieldsAreNonnullByDefault 在 Minecraft 中可能不存在，需确认）。
• 即使编译通过，在发布或使用 IDE 注解处理器时可能会产生异常。

建议：

• 恢复为 net.minecraft.MethodsReturnNonnullByDefault。
• 如需 @FieldsAreNonnullByDefault，可参考 Minecraft 源码中使用 @net.minecraft.FieldsAreNonnullByDefault（但需要验证该注解是否存在），或者使用 javax.annotation.ParametersAreNonnullByDefault 的变体，但更推荐使用 NullMarked 注解。
• 如果确需添加字段非空注解，建议使用 @org.jetbrains.annotations.NotNull 或 @javax.annotation.Nonnull 配合 @DefaultQualifier，但应统一风格并确保与项目一致。

修改建议：撤销对所有 package-info.java 的更改，或改用正确的公开注解。

---

2. 缺失物品注册：pump 配方存在但对应物品未定义

文件：

• src/main/java/dev/dubhe/anvilcraft/data/recipe/RegistrumItemRecipeLoader.java（添加了 pump 方法）
• src/main/java/dev/dubhe/anvilcraft/init/item/ModItems.java（未注册 PUMP 物品）

问题：配方加载器定义了 pump 配方（产出2个泵物品），但 ModItems 中并未注册名为 pump 的物品或方块物品。这会导致：

• 游戏加载时因找不到 pump 物品而崩溃（如果配方被引用）。
• 数据生成阶段也可能报错，因为配方生成尝试引用不存在的物品。

建议：

• 在 ModItems.java 中注册 PUMP 条目（参考 PIPE 的注册方式），并确保对应的方块或物品类已存在。
• 或者，如果 pump 配方是临时添加但未完成，则应暂时移除该配方方法及其调用，直至物品准备就绪。

---

3. JSON 文件换行符丢失

文件：

• src/generated/resources/assets/anvilcraft/lang/en_ud.json
• src/generated/resources/assets/anvilcraft/lang/en_us.json
• 以及其他生成的 JSON 文件（如 pipe.json、pump.json 等）

问题：文件末尾的换行符被移除（\ No newline at end of file）。虽然 JSON 解析器一般容忍，但：

• 在 Unix 系统下可能不符合 POSIX 标准。
• 与项目中其他文件的风格不一致（原始文件末尾有换行符）。

建议：在生成文件时确保末尾包含换行符，或手动恢复。

---

4. 配方组（group）设置可优化

文件：src/main/java/dev/dubhe/anvilcraft/data/recipe/RegistrumItemRecipeLoader.java

问题：

.group(ctx.getId().toString())

ctx.getId() 返回 ResourceLocation（如 anvilcraft:pipe），转换为字符串后作为组名。虽然可行，但组名通常使用无命名空间的短名称（如 "pipe" 或 "anvilcraft_pipe"），以便在配方书中更好地分组。使用完整 ID 可能导致组名过长且包含冒号，降低可读性。

建议：改用 ctx.getId().getPath() 或直接使用常量字符串，例如 "anvilcraft:pipe" 或 "pipe"。

---

5. PIPE 物品的模型路径可能重叠

文件：src/main/java/dev/dubhe/anvilcraft/init/item/ModItems.java

public static final ItemEntry<PipeBlockItem> PIPE = REGISTRUM.item("pipe", PipeBlockItem::new)
    .model((ctx, provider) -> provider
        .withExistingParent(ctx.getId().toString(), AnvilCraft.of("block/pipe"))
    )
    ...

问题：物品模型直接指向 block/pipe，但新生成的模型文件 src/generated/resources/assets/anvilcraft/models/item/pipe.json 也指定了相同的父级。这样没问题，但自动生成的 item/pipe.json 是必要的吗？因为 withExistingParent 会生成一个物品模型文件，而 pipe.json 已经存在（通过 .model 方式），可能会导致冲突。实际上，上面的代码会创建一个名为 item/pipe.json 的模型（通过 withExistingParent），但 pipe.json 本身就已经存在（作为物品模型），所以生成结果可能覆盖或重复。需要确认是否真的需要显式调用 withExistingParent，或者可以直接省略，让数据生成器自动处理。

建议：如果希望所有管道物品都使用统一的 block/pipe 模型，可以直接使用 .model(DataGenUtil::noExtraModelOrState) 或依赖默认行为。当前写法可能会生成两份 pipe.json（一个来自 pipe.json 文件，一个来自生成器）。建议统一采用自动生成方式，并删除已添加的静态 pipe.json 文件，或者保持现状但确保生成器不会覆盖静态文件（生成器通常不会覆盖手动修改的文件？但这里文件在 generated 目录，应视为自动生成内容，不建议手动添加静态文件）。建议移除静态的 pipe.json，完全由数据生成器生成。

---

6. HudTooltipManager.java 代码格式化

文件：src/main/java/dev/dubhe/anvilcraft/api/tooltip/HudTooltipManager.java

问题：在 renderTooltip 方法中添加了大括号和换行，改进了可读性，但可能导致与现有代码风格不一致（原有混合了无大括号的写法）。虽然格式调整本身无害，但在一个 PR 中混入大量格式修改会干扰功能变更的审查。建议将此类纯格式修改分离到单独的 commit 或 PR 中。

建议：无功能问题，但建议团队统一代码风格。

---

7. ICustomDataComponent.java 空行移除

文件：src/main/java/dev/dubhe/anvilcraft/api/recipe/data/ICustomDataComponent.java

问题：移除了 import dev.anvilcraft.lib.v2.util.ISerializer; 后的一行空行，属于微小风格调整，不影响功能。

建议：无障碍。

---

8. CapabilitiesEventListener.java 注册 PIPE_NODE 流体能力

文件：src/main/java/dev/dubhe/anvilcraft/event/CapabilitiesEventListener.java

问题：在 registerCapabilities 中增加了 ModBlockEntities.PIPE_NODE.get() 的流体能力注册。看起来合理，前提是 PIPE_NODE 方块实体确实需要流体处理。

建议：确认 PIPE_NODE 的实体类正确实现了流体处理逻辑。

---

9. en_ud.json 的语言条目顺序

文件：src/generated/resources/assets/anvilcraft/lang/en_ud.json

问题：新增的条目按字母顺序排列在中间，但文件中其他条目是严格按照字母顺序的，这里新增条目位置正确，没有问题。但注意 en_ud.json 是倒置字符串，确保翻转正确。

建议：已验证条目翻转正确（如 "block.anvilcraft.pipe_corner": "ɹǝuɹoƆ ǝdᴉԀ" 对应英文 "Pipe Corner"）。

---

总结与优先级

问题	严重性	建议操作
1. package-info.java 错误导入	严重	立即修复，恢复原始导入
2. pump 物品缺失	严重	补充注册或移除配方
3. JSON 换行符	低	可选修复以保持一致性
4. 配方组命名	低	可优化，非必须
5. 模型文件重复	中等	建议清理静态模型文件，统一由生成器生成
6. 格式化变动	低	建议分离到单独 PR
7-9	无/低	可忽略

重点建议：优先处理问题1和问题2，它们可能导致编译失败或运行时错误。