每次交互向熔炉/精炼厂装载5个物品，并遵循各站点的限制（例如窑炉只能使用木材）。自动从箱子、推车和掉落的煤炭中拉取；为火把、壁炉和霜冻铸造厂补充燃料；批量填充炭窑。仅客户端。

简单合成

AI生成声明本模组由 AI 智能体（WorkBuddy）在用户的明确需求与逐项验收下编写；功能设计、真机测试与发布决定均由用户主导。

炼制站点 / 火源的装填增强。 由 EasyBatchFill 与 EasyNearbyFill 合并而成 —— 合并同时消掉了原先两者之间那条「必须成对升级、单升一边 BepInEx 直接加载失败」的跨程序集硬依赖。

功能

• 批量装填：单次交互装填 批次大小 个（默认 5），取代原版的一次 1 个。 站点：熔炉 / 高炉 / 炭窑 / 风车 / 纺车 / Eitr 精炼厂。
• 站点进料限制（1.0.2 新增）：限定某个站点只允许自动装填指定材料。 炭窑只烧木材（不烧细木 / 圆木）。
• 火源加燃料：火炬 / 壁灯 / 篝火 / 火盆 / 灶 一次加 批量大小 个； 营火（火坑）默认采用「一次一个」模式：数量保持原版 1 个， 但仍然会从附近箱子自动取木头 —— 做饭的基础火一次烧 5 个木头太快。
• 就近取材：背包材料不足时，自动从半径30米内的箱子中补足。默认为 木箱 / 加固型宝箱 / 黑金宝箱 / 灰石箱 / 桶 / 衣柜； 个人宝箱与珍宝箱有意排除。
• 板车也算料源（包含购物车，默认开启）：静止停放的板车/雪橇与箱子同样会被取料； 正在被拖行的板车会跳过（位置在变，且去接管所有权可能把车抢走）。

  ⚠️ 不需要把 购物车 加入 允许的容器 —— 板车走的是独立的识别通道， 与箱子白名单无关（判断依据见下方「板车是怎么被认出来的」）。

• 占用保护：队友站在箱子旁就跳过它，避免抢走所有权导致对方物品回弹。
• 霜铸熔炉加燃料（1.0.7 新增）：给霜铸熔炉（霜寒铸造厂，官方中文“霜铸熔炉”）加液态冰霜（冰冻燃料）时，也能从附近箱子 / 板车自动取料。 一次1个 （与原版一致，不做批量）。

  为什么要单开一项：它挂的是 烹饪台 组件，不是熔炉用的 熔炉 —— 原先两套补丁都覆盖不到它。详见下方「霜铸熔炉（1.0.7 起）」专节。

• 木炭窑联动（1.0.8 新增）：给一座炭窑加木材时，把周围 10 米内的炭窑一起装满 （每座各装 批次大小 个）。详见下方「木炭窑联动（1.0.8 起）」。
• 地面掉落物（1.0.8 新增）：熔炉 / 高炉加燃料时，背包不够就先捡地上的木炭， 还不够再找箱子。详见下方「地面掉落物（1.0.8 起）」。

配置（5 节）

节	内容
1 - 批量填充	启用 / 批处理大小 / 前哨站矿石许可 / 冰霜铸造厂预制件 / 窑炉连接预制件 / 窑炉连接半径
2 - 火源	已启用 / 排除 / 来源（留空 = 全部火源生效）/ 一次一个 / 按住间隔 / 尊重切换
3 - 附近宝箱	启用 / 半径 / 地面拾取 / 允许的容器 / 包含购物车 / 尊重守卫 / 认领所有权
4 - 安全	使用中跳过 / 若玩家在附近则跳过 / 玩家附近距离
5 - 调试	调试日志

BepInEx/config/easycraft.client.only.cfg　⚠️ 改完必须重启游戏。

板车是怎么被认出来的（1.0.5 修正）

板车（购物车）与雪橇（雪橇）用的都是游戏的 车厢 组件，内部各带一个容器。 它们不在 允许的容器 白名单里 —— 走的是独立识别通道，两条信号任一命中即算板车：

优先级	信号	原理
主	购物车注册表（本模组维护）	用 Harmony 补丁复刻游戏自己的 Vagon.m_instances 清单（醒来 里加、销毁时 组删），再用 Vagon.m_container 反查对应的容器
兜底	集装箱.m_wagon ！= null	游戏字段，两者互相引用

为什么不用 货物车厢 当唯一依据（1.0.5 修的就是这个）： 这个字段在整个游戏代码里零处写入（只靠预制体序列化），只有 3 处读取， 且全部带 null 判断：

容器.RPC_请求打开 / RPC_请求堆叠 / RPC_请求全部拿取 如果（正在使用（）||（m_wagon != null && m_wagon.正在使用（）））{ 拒绝本次开启 }

⇒ 说明游戏本身就预期它可能为 null，当它为 null 时一切正常，没有任何可见症状。而旧版代码只认它 ⇒ 一旦为 null，板车就会被当成“名字不在白名单里的普通箱子”静默跳过。

反过来 Vagon.m_container 是必须连的：更新质量 / 更新加载可视化 都靠它来算载重（往板车里放东西会让车变沉，这是核心可见行为）。 以它为主信号才可靠。

什么情况会跳过板车

情况	是否取料	日志里会说什么
静止停放	✅ 领取	正常取料日志
正在被拖行	❌ 跳过	[板车被跳过] … → 正在被拖行（停放后即可取）
包含购物车 = false	❌ 跳过	[板车被跳过] … → IncludeCarts 开关是关的
有人正开着它的容器	❌ 跳过	[有人正在使用] …（受 跳过 控制）
守卫石无权限	❌ 跳过	[守卫石无权限] …（受 尊重守卫 控制）

每条诊断都会附带 板车[是(哪条信号)/否]，能直接看出识别有没有生效。

木炭窑联动（1.0.8 起）

给一座炭窑加木材，把周围一圈炭窑一起装满。

配置	默认	说明
1 - 批量填充 → 窑炉连接预制件	木炭窑	名单里的窑才联动；留空 = 关闭
1 - 批量填充 → KilnLinkRadius	10 米	搜索半径；0 = 关闭

• 每座窑各装一份（批大小 个），各自按剩余容量封顶 —— 不是总量分摊。 4 座窑 = 各 5 个，共消耗 20 个木材。
• 料源共享（背包 → 附近箱子），按距离由近到远先到先得。
• ⚠️ 炭窑加木材走的是进料口（添加矿石）而不是燃料口 —— 炭窑的机制本来就是“把木材烧成木炭”（矿石接收站 的默认值也印证了这点）。
• 找邻居：物理重叠球体 + 在父级中获取组件<Smelter>()。 必须去重 —— 一个建筑身上有多个碰撞体，不去重会把同一座窑重复装填好几次。
• 你正在操作的那一座先按原逻辑装（所以“已满”/“没料”的提示文案是准的）；它失败且还没动过料源直接交回原版 ⇒ 不会出现“既扣了料、又被原版再扣一次”。

地面掉落物（1.0.8 起）

熔炉 / 高炉加燃料时，取料顺序由 背包 → 箱子 变成 背包 → 地面 → 箱子。

配置	默认	说明
3 - 附近宝箱 → 地面拾取	煤炭	允许从地上捡起的物品；留空 = 关闭
（半径）	沿用 3 - 附近宝箱 → 半径（30米）	圆心判据同箱子：机器 或 玩家，命中任一即可

⚠️ 生效范围刻意收窄：只对 熔炉 燃料口生效 ——矿石口 / 火源 / 霜铸熔炉（烹饪台）完全不碰。

名字三种写法都认（忽略大小写）：$item_coal / 煤 / 煤。

数量为什么是准的

地面上一堆物品 = 一个 掉落物品 对象，真实数量在 物品数据.堆叠数量 里（可能装着十几个）， 绝不能按“一个对象 = 一个物品”来数。非法输入验证：

// ItemDrop.RemoveOne() 中，如果 (!CanPickup(true)) { RequestOwn(); return false; } // 没有权限 → 一个都不取
如果 (m_itemData.m_stack <= 1) { m_nview.Destroy(); return true; }
m_itemData.m_stack -= 1; Save(); return true;
// ItemDrop.CanPickup(bool) 末尾：return m_nview.IsOwner();
// ItemDrop.SetStack(int) 首句：if (!IsOwner()) return; // 静默失败，所以本模组不用它

⇒ 本模组的做法：

1. 先 声明所有权（与箱子取料同一套模式）
2. 加载() 刷新 物品数据，避免按旧堆栈决定取多少
3. 只取 min(还需要的, 这堆有的)，逐一 移除一个() 并按其返回值计数 —— 返回 false 就是没拿到写权，这一下不算数
4. 遍历前给 掉落物实例 做快照（取空会 摧毁（边遍历边修改集合会导致漏掉某些项）

宁可少加（下次交互还能补），绝不虚报数量。

霜铸熔炉（1.0.7 起）

问题给霜铸熔炉加液态冰霜时只能从自己背包拿 1 个，放在附近箱子里的取不过来。

根本原因霜铸熔炉（霜冻铸造厂）挂着的是 烹饪台 组件，不是熔炉或高炉用的 熔炉。上面的「批量装填」只接管 熔炉（添加矿石 / 添加燃料）和 壁炉（火源），所以对霜铸熔炉完全没生效。

组件身份是实测的 —— 预制体脚本引用 path_id 交叉比对 （同一 bundle 内，同一个 C# 类只有一个 MonoScript 资产、只有一个固定 path_id， 所以两个预制体引用同一 path_id 即同一个组件）：

预制体	组件脚本 path_id
霜寒铸造厂 霜铸熔炉	甲、乙、丙、 4793016392223414848
烹饪台 烹饪台	甲、乙、丙、 4793016392223414848 ← 完全一致
霜炉 霜窑	甲、乙、 -1171893114429426784，C
熔炉 / 高炉 / 炭窑 / 风车 / 纺车	都带 -1171893114429426784

⇒ -1171893114429426784 = 熔炉，4793016392223414848 = 烹饪台。 运行日志也一致：玩家日志 里 霜冻铸造厂 零条 EasyCraft 记录，而同族的 霜炉部件（真·熔炉）有 10 条 [站点燃料口装填]。

做法接管 烹饪台.燃料添加开关，燃料名从 燃料物品 动态读 （霜铸熔炉实测 = 液态冰霜），数量固定 1，不足时走与其它站点同一条「就近取料」链路。 RPC 按原版 调用RPC("RPC_AddFuel") 调一次（上游这个方法固定 设置燃料(获取燃料()+1)、无 amount 参数、服务端也不封顶）。

配置 霜铸工坊预制件

• 默认 寒霜铸造厂；留空 = 该功能完全关闭
• ⚠️ 普通「烹饪台 / 铁烹饪架」用的是同一个 烹饪台 组件，所以这里是白名单：只写进去的才接管，名单外的烹饪站行为与不装本模组时一模一样。

明确不碰的两处

• 铸胚投料口（烹饪台.添加食物开关）：本模组源码对 添加食物开关 / 使用物品 / 交互时 零引用，只挂了 添加燃料开关。
• 批量：燃料口只加 1 个 —— 只解决“取不到料”，不改变加料节奏。

站点进料限制 矿石允许站（自 1.0.2 起）

原版炭窑能烧 木材 / 细木 / 圆木 三种，价值差很多。这一项让本模组的自动装填 只选你允许的材料——默认就是「炭窑只烧木材」：

木炭窑=$item_wood

想同时限制别的站点，用分号加组：

木炭窑=$item_wood ; 熔炉=$item_copperore,$item_tinore

• 材料名三种写法都认（忽略大小写）：木材 / 木材 / 木头

• 站点名也三种都认：木炭窑（GameObject 名）/ 木炭窑/ 炭窑 —— 内部会去掉 碎片_ 与下划线后归一化比较，所以顺手怎么写都能匹配上。

• 常用站点名：

  站点	游戏对象名
  炭窑	木炭窑
  冶炼炉	熔炉
  高炉	高炉
  风车	风车
  纺织机	纺车部件
  埃达之力提炼器	埃特精炼厂

• 只影响本模组的自动装填（批量装填 + 就近取料）；你自己手动往站点里放什么都不受限制。

• 留空 = 不限制任何站点（完全回到原版）；某个站点写成 站点=（右边留空）= 单独放行该站点。

• 名字万一写错，站点不会变成“什么都装不进去” —— 会退回原版行为，同时打一条 Warning 把该站点实际可用的材料名列出来，直接照抄即可。

• 生效情形看日志里的 站点进料限制生效：charcoal_kiln 只允许装填 [$item_wood]（该站点可用共 3 种：…）。

三张火源名单叠加后的语义（1.0.1 起）

排除	一次一个	行为
✅ 命中	❌ 不在	完全交回原版（一次1个，也不从箱子里取料）
✅ 命中	✅ 在	数量固定1个，但料源（附近箱子）可用 ← 营火默认
❌ 未命中	—	正常接管，一次装 批量大小 个

想给别的火源也用「一次一个 + 拉料」，把它的 GameObject 名同时加入 排除 和 一个一个来。

⚠️ 填火源名字前先看这里

排除 / 来源 里填的是 游戏对象名称，它不一定等于本地化键：

官方中文	游戏对象名	容易误写
营火（能做饭的基础火）	火坑	火坑
篝火	篝火	篝火
灶	炉火	炉石碎片
壁灯	矮人灯笼碎片	—
火炬	地面火把 / 木制地面火把 …	—

不确定某个火源到底叫什么，看日志里的 [火源探测] 好 —— 它会把“组件在=…”和“ZDO名=…”都打印出来。

⚠️ 填箱子名字前先看这里（1.0.6 修正）

好消息：你几乎不用管下划线怎么写——匹配已归一化，两种写法都认。

归一化规则 = 忽略大小写 + 去除 碎片_ 前缀 + 去掉所有下划线。 所以下面这些写法全部等价，随便挑一种：

黑金属宝箱 == piece_chestblackmetal == CHESTBLACKMETAL

为什么改成归一化（1.0.4 的“修正”其实修错了）

游戏里 GameObject 名与本地化键不是同一个字符串。真机日志实证（黑金宝箱采样 260 次）：

游戏对象名（匹配用的是这个）	本地化键	一致？
宝箱	部件箱	✅
黑金属宝箱	黑金属碎片宝箱	❌ 不一致
私人宝箱	私人宝箱	❌ 不一致

⇒ 多词箱子的 GameObject 名带下划线、本地化键不带；单词的 宝箱碎片 两者相同。 这就是为什么大箱子一直好使，而黑金箱等一直静默失配。

⚠️ 1.0.0~1.0.4 的经历值得一提：1.0.4 曾放话说"箱子名一律不带下划线"，依据是扫了 资源文件 ——而那份里装的其实是本地化键，不是预制体名，结果把一个原本能匹配的名字（黑金箱）反而写坏了。现在两种写法都通，不必再纠结。

箱子对照表（归一化键 = 实际参与匹配的键）

官方中文	游戏对象名	本地化键	归一化键	默认包含
宝箱（木箱）	木制宝箱	木制宝箱	宝箱木	✅
加固型宝箱（大箱子）	宝箱	碎片宝箱	宝箱	✅
黑金宝箱	黑金属胸甲	黑金属碎片箱	黑金属宝箱	✅
灰石箱	格雷斯滕胸甲片	$piece_chestgrausten	宝箱	✅
桶	木桶碎片	$piece_chestbarrel	宝箱桶	✅
衣柜	衣柜碎片	$piece_chestwarderobe	衣柜	✅
个人宝箱	私人宝箱	私人箱子	宝箱·私人	排除
珍宝箱	宝箱碎片	宝箱碎片	宝箱	排除

想恢复某个被排除的箱子（比如个人宝箱），把它的任意一种写法加入 允许的容器 即可：

piece_chestprivate ← 这样写 piece_chest_private ← 或者这样写，完全等价

启动自检会同时打印你写的原文和生效的归一化键，名字对不对得上可以当场核对：

就近取料=开：半径 30 米，允许的箱子 6 种 [piece_chest,piece_chestbarrel,…]（板车=开），… 箱子名匹配已归一化（去 piece_ 前缀 + 去所有下划线 + 忽略大小写）：生效匹配键=[chest,chestbarrel,…]

💡 现在站点名与箱子名用的是同一套归一化规则，不会再出现“这个要精确、那个能宽松”的混乱。

实现要点

• 站点装填：熔炉.添加矿石时 / 补充燃料 的前缀；火源：壁炉.交互 的前缀。
• 素材来源：容器.唤醒 / 销毁时 维护活箱子登记表，搜索时以【机器】和【玩家】各自为圆心。取料顺序：先吃背包 → 按距离更近优先逐个箱子取 → 取够即停。
• 取料前用 ZNetView.ClaimOwnership() 接管箱子 ZDO 所有权 —— 必须，否则 容器.当容器改变时() 的 如果（！IsOwner（））返回； 所有修改将不会被保存，并会产生副本。
• 🔴 调和前缀铁律：处理不了就 返回真 完整交回原版，绝不静默 返回 false ——那会表现为「按 E 完全没反应」，极难排查。

联机

纯客户端。 主机、其他玩家都不需要装。

不声明 网络兼容性特性，不引用 Jotunn，不内嵌 ServerSync / CCS。