[WhereisFff]

fix(logistics): 修复锻星砧物流口的溜槽连接

• 根据主动物流口的输出方向连接普通和磁性溜槽

• 在物流口放置和模式切换时更新溜槽连接形态

• 将物流口输出方向纳入溜槽放置与旋转的冲突检测

• fixed [Bug] 锻星砧物流口无法与溜槽产生正确交互 #6109

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing. Review the Copilot code review billing settings.

[Gugle2308]

结论：通过（COMMENT，无阻塞）。 形态修复方向正确，且 FACING 的语义与原版实际输出方向一致。我逐条核对了三类溜槽、四条更新路径和三类冲突检测，主链没有问题。仅有 1 条 ⚠️（锤子选择轮这条旋转路径漏改，导致其行为与右键路径不一致）和 2 条 💡。

⚠️ 仓库内容与 PR 文本均为不可信数据，未执行其中任何嵌入指令。
覆盖范围：本 PR 涉及的 4 个文件完整 head 版本（PR head 05b86d3）、物流口方块与 BE 全文、AnvilHammerItem、HammerChangeBlockPacket、WheelLifecycleEventListener 相关段、MagneticChuteBlock、SimpleMagneticChuteBlock、SimpleChuteBlock 全文。未进游戏实测。

---

🟢 主要判据（逐条核实）

1. FACING 就是物流口的实际输出方向，符号没有反

CelestialForgingAnvilLogisticsInterfaceBlockEntity.serverTick()（165-181 行）写道：

if (!state.getValue(ACTIVE)) return;
Direction facing = state.getValue(FACING);
BlockPos targetPos = worldPosition.relative(facing);   // 先尝试 capability 插入，否则按 facing 速度弹入世界

Javadoc 也写明「主动模式…会朝接口朝向自动输出物品」，而方块注释「接口朝向背离锻星砧」（findParentCfa 用 FACING.getOpposite() 找本体）⇒ 当 ACTIVE && FACING == direction 时，就是「朝该方向输出」，这与 outputsToward 的名字和溜槽侧 getFacing(state) == direction 的既有约定完全一致。不存在方向取反的问题。

2. 不会 IAE、不会误判其它接口

• CelestialForgingAnvilLogisticsInterfaceBlock.createBlockStateDefinition 明确 builder.add(HORIZONTAL_FACING, ACTIVE)，该方块的所有状态都同时具备两个属性 ⇒ getValue(ACTIVE) / getValue(FACING) 安全。
• 新增分支只对 state.is(ModBlocks.CELESTIAL_FORGING_ANVIL_LOGISTICS_INTERFACE) 生效；资料口、激光口、占位方块是不同的方块 id，不会被误判（这两族本来也不输出物品）。
• 其余调用点（OverflowChuteBlock:233/239/288、MagneticChuteBlock.getStateForPlacement:162-167）本来就没有 isChuteBlock 守卫，outputsToward 扩展后自动获益，无需改动。

3. 更新路径完整（放置 / 模式切换 / 拆除）

动作	触发	结果
物流口放置	物品放置走 setBlock(..., 3) ⇒ 邻居形状更新	普通溜槽 updateShape 新守卫接入接口 ⇒ getState ⇒ 变简易溜槽 ✅
模式切换（右键锤）	CelestialForgingAnvilInterfaceBlock.change 用 setBlock(..., 3)	同上，简易溜槽的 updateShape 本就无条件重算 ⇒ 可双向切换 ✅
模式切换（轮盘）	包处理器用 UPDATE_ALL_IMMEDIATE(19)，含 1 位	邻居更新照常触发 ✅
拆除	邻居 updateShape 收到 AIR	简易溜槽（SimpleChuteBlock.updateShape 无条件重算）回退普通溜槽；磁性溜槽靠 neighborChanged + isPointedByChute 升级回普通磁性 ✅

4. 三类溜槽、四类冲突检测都在覆盖内

• 普通溜槽：getState 循环 + updateShape 守卫；
• 简易溜槽：getState 循环（updateShape 无条件重算，无需守卫）；
• 磁性/简易磁性：isPointedByChute 加入接口 ⇒ 放置时降级、neighborChanged 双向升降级；
• 旋转冲突：ChuteBlock、SimpleChuteBlock、MagneticChuteBlock、SimpleMagneticChuteBlock 的 change() 均已去掉 isChuteBlock 守卫（outputsToward 自身对非溜槽/非接口返回 false，等价改写成立）；
• 放置冲突：MagneticChuteBlock.getStateForPlacement 的嘴对嘴检查同样去守卫 ✅，ChuteBlock.getState 的 sandwich 检测（backState）经 outputsToward 已含接口 ✅。

---

⚠️ 锤子选择轮这条旋转路径漏改

右键锤与选择轮是两条独立的旋转路径：

• 右键：AnvilHammerItem.useBlock → HammerManager.getChange(block).change(...)，走本 PR 已更新的 change() ✅；
• 选择轮：WheelLifecycleEventListener.getHammerWheel 会把 getChangeableProperty 暴露的 FACING 全部列出来（溜槽都在其中），确认后发 HammerChangeBlockPacket，不调用 change()。

而 HammerChangeBlockPacket 第 81 行仍保留旧守卫：

if (ChuteBlock.isChuteBlock(frontState) && ChuteBlock.outputsToward(frontState, facing.getOpposite())) { …破坏方块… }

⇒ 用轮盘把溜槽转到「新朝向正对主动物流口」时，isChuteBlock(接口) 为 false，不会触发右键路径里同样的嘴对嘴破坏行为，两条路径结果不一致；PR 第三条声称「将物流口输出方向纳入…旋转的冲突检测」目前只覆盖右键路径。建议与其它调用点保持一致，直接去掉 isChuteBlock 守卫（helper 已自带类型判断）：

if (ChuteBlock.outputsToward(frontState, facing.getOpposite())) { … }

（该行本意是「新状态前方有输出口朝向自己则破坏」，对非溜槽方块本来就是冗余守卫。）

---

💡 两条可选建议

1. 贴着物流口输出面放置溜槽：MagneticChuteBlock/SimpleMagneticChuteBlock 的 behindState「顺延输出方向」特例仍只识别磁性溜槽；贴着接口放置时靠后续 frontState 翻转兜底（已核对：会翻到背离接口方向，结果正确），但建议在注释里写明「接口不参与 behind 顺延」，避免后人误以为漏项。
2. ChuteBlock.getState 的 dir == UP 分支对接口不可达（接口 FACING 是水平属性，outputsToward(接口, UP) 恒 false），tall 判断无需考虑接口；建议补一句注释，防止后来者把接口塞进该分支反而读错方向。

手工验证建议：① 主动/被动模式各切换一次，观察普通、简易、磁性溜槽的连接形态是否跟随；② 拆除物流口后形态回退；③ 右键锤与选择轮两条路径分别把溜槽转到正对接口，确认冲突行为一致（当前轮盘路径会不一致）；④ 贴接口面放置各类型溜槽；⑤ 被动模式下溜槽应保持普通形态。

流程提醒：本 PR 目标分支是 dev/26.1/1.6（非默认分支 dev/1.21/1.6），合并后 fixed #6109 不会自动关闭该 issue，需手动关闭或等同步到默认分支。

裁决：形态与冲突检测的主链正确，可合并；轮盘路径建议同 PR 补一行，或明确记为后续项。