[WhereisFff]

fix(recipe): 修复燃烧加热器最后一次加工数量

• 按配方与配置限制计算鱼缸批量加工数量

• 保持一次铁砧触发只消耗一次燃料，并遵守原料及输出容量限制

• fixed [Bug] 当燃烧加热器剩余时间仅够一次加工时，加工物品数量错误 #6052

[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]

审查结论：APPROVE（0 个阻塞项，3 条补充说明）

修复方向正确，删除的是本不该存在的限制。删掉之后，「燃料只剩一次加工量」与「燃料充足」两种情况走完全相同的路径，符合 issue #6052 的预期。

范围说明：webhook 只提供 patch diff；本 PR 为 1 文件 / +1 −25，与 API 元数据一致，diff 覆盖完整。结论基于 head ee039c2 源码树与 base 286f734 对照（已验证被删方法体逐字一致，无夹带改动）。未覆盖：运行时实机行为与多人场景。CI：build ✅ / checkstyle ✅。目标分支 dev/26.1/1.6，issue 报告版本 26.1.2 / snapshot.2862 → 版本对得上。

---

✅ 根因判断正确，且能解释「为什么只有这一种情况复现」

原 batchLimit 的算术如下（数值全部可核）：

• BurningHeaterBlockEntity.LIT_THRESHOLD = 240 * 20 = 4800，ConsumeBurningHeaterFuel 的 fuelCostTicks 也是 240 * 20 = 4800（SuperHeatingRecipe.java:116 与 codec 的默认值一致）；
• 加热器 LEVEL == 2（CauldronProcessing.SUPER_HEATING 的唯一判据，api/recipe/CauldronProcessing.java:36）的条件是 burnTime >= 4800；
• 旧代码计算的是扣完燃料之后的等级：remaining >= 4800 即要求 burnTime >= 9600。

所以当 burnTime ∈ [4800, 9600) 时：当前能匹配高温熔炼，但旧代码预判「扣一次燃料就不够等级 2 了」，于是 return Math.min(limit, 1) —— 只加工一次。这与 issue 描述「剩余燃烧时间只够一次加工时只执行一次」完全吻合，也解释了为什么燃料充足（≥9600）时该 bug 不出现。

✅ 删除是安全的，两条支撑证据

1. 燃料确实只在每次铁砧触发时消耗一次，与批次数无关：FishTankRecipes.prepare 的 afterCommit 里写的是
   effect.acceptWithChance(effect instanceof ConsumeBurningHeaterFuel ? impact : context) —— 传的是共享的 impact 上下文，而 ConsumeBurningHeaterFuel.accept 首行就是 if (context.get(FUEL_CONSUMED)) return; context.put(FUEL_CONSUMED, true)。第一个批次置位后，后续批次直接跳过。既然成本按「触发」计价而非按「批次」计价，拿剩余燃料去约束批次数量在语义上就是错的。
2. 匹配时的限制没有丢：HasCauldronProcessor 仍由 AbstractProcessRecipe.Property 注入（AbstractProcessRecipe.java:783-784），CauldronProcessing.matches(SUPER_HEATING, state) 只接受 BURNING_HEATER && LEVEL == 2。所以不会出现「加热器已熄灭后还能开新配方」——消失的只是「熄灭前这一次也不许满批」这个错误限制。

另外核对过两点，均未受影响：

• 被删分支只对 ConsumeBurningHeaterFuel 生效，而它仅由 SuperHeatingRecipe 添加；FastCookingRecipe 不含该 outcome，所以快速烹饪（加热器 LEVEL 1）路径行为不变。
• 输入/输出容量限制仍由 ItemBatchPlan 的 capacity 与 shared/separate 负责，本 PR 未触碰，不存在新增溢出路径。

---

⚠️ 建议在 PR 描述里写明这是玩家可见的效率变化（非阻塞）

改动后，burnTime ∈ [4800, 9600) 的加热器一次触发可产出 min(maxEfficiency, inWorldRecipeMaxEfficiency) 批，而消耗仍是 4800 ticks。也就是说「燃料成本 = 每触发 1 次」，与剩余燃烧时间彻底解耦。这是 issue 的期望（「正确执行正确数量的物品加工」），但属于收益提升：低燃料状态不再是惩罚项。建议正文补一句，避免后续被当作「燃料被白嫖」回滚。若设计上确实想限制单次触发的最多烧炼量，正确的落点是 SuperHeatingRecipe 的 maxEfficiency，而不是恢复这里的 clamp。

💡 limit 的实际上限其实来自 AnvilLib 配置

SuperHeatingRecipe 的构造器调用 super(property)，而 AbstractProcessRecipe(Property) 把 maxEfficiency 固定为 Integer.MAX_VALUE（AbstractProcessRecipe.java:71-73）⇒ Math.min(process.maxEfficiency(), AnvilLibRecipe.CONFIG.inWorldRecipeMaxEfficiency) 实际取值 = inWorldRecipeMaxEfficiency。「配方级上限」这一半是空转的，值得加一行注释说明，否则后续维护者会误以为每个配方自带上限。

💡 姊妹 PR 需同步合并

已找到同一改动的 1.21 线版本 #6085（1.21 Fix final burning heater batch），两 diff 结构完全一致，仅 outcome 类型名因 26.1 重构而异（1.21 为 SuperHeatingRecipe.ConsumeFuel 内嵌类，26.1 已提为独立的 ConsumeBurningHeaterFuel record）。两线须一起合入，否则 issue #6052 在另一条线仍可复现——建议在描述里互相链接。

---

🧪 建议验证

1. 复现用例（issue 原始场景）：燃烧加热器燃至 burnTime 略高于 4800（旧代码必现只加工 1 次），鱼缸内放足够原料 + 空输出槽 → 落砧一次，应加工满批且燃料只扣 4800；
2. 回归用例：burnTime 充足（≥9600）时批次数与改动前一致；
3. 边界：burnTime 恰为 9600（旧代码最后一个不触发 clamp 的值）与恰为 4800（旧代码第一个触发 clamp 的值）各测一次；
4. 不应加工：burnTime 略低于 4800（LEVEL 1）→ 高温熔炼不匹配，落砧无产出（确认没被顺手放宽）；
5. 燃料归一：连续多次落砧，确认每次触发各扣一次 4800，不会因为批次数多扣；
6. 输出溢出：输出槽接近满时落砧，产物只进槽内、不留掉落物（确认 ItemBatchPlan 容量限制仍生效）。

[PigeonNian]

LGTM