物品推送代理

基本信息

属性 值
实现 compat/itempush/ItemPush.scala + 4 个 ItemPushProxy
初始化 ItemPush.init()，Gendustry.scala:78 在 preInit 最早段调用
唯一使用者 Item Eject Cover 的 tickCover
代理数 4（原版 + 3 个跨模组代理）

代理链

ItemPush.init() 按固定顺序注册，先注册先尝试，形成一条链式管道：

顺序 代理 启用条件 后端接口
1 VanillaPush 无条件 IInventory
2 BCPipePushProxy Misc.haveModVersion("BuildCraftAPI|transport@[3.0,)") buildcraft.api.transport.IPipeTile
3 CofhConduitPushProxy Misc.haveModVersion("CoFHAPI|transport") cofh.api.transport.IItemDuct
4 MekanismPushProxy Misc.haveModVersion("Mekanism") mekanism.common.base.ITransporterTile（反射）

ItemPush.pushStack 依次把剩余物品交给下一个代理：

var stack = st
for (proxy <- proxies if stack != null && stack.stackSize > 0)
  stack = proxy.pushStack(from, dir, stack)
if (stack != null && stack.stackSize <= 0) null else stack

因此一个盖板可以依次喂给相邻的原版箱子、BuildCraft 管道、CoFH 导管、Mekanism 管道 —— 四个后端同时存在时会依次尝试，全部拒绝才留在原槽位。

导入方向不走这条链：Item Import Cover 直接调 ItemUtils.addStackToSlots，只支持原版 IInventory（以及 ISidedInventory 的 canExtractItem 校验）。这是一个不对称设计。

各代理的行为差异

代理 关键逻辑
VanillaPush ItemUtils.getAccessibleSlotsFromSide(target, dir.getOpposite) + addStackToSlots(stack, target, slots, true)；找不到 IInventory 邻居时原样返回
BCPipePushProxy 只在 pipe.getPipeType == IPipeTile.PipeType.ITEM 时注入；injectItem(stack, true, dir.getOpposite, null) 返回已接收数，used >= stack.stackSize 时返回 null，否则 splitStack(stackSize - used)
CofhConduitPushProxy conduit.insertItem(dir.getOpposite, stack)，直接返回其返回值
MekanismPushProxy 反射加载 mekanism.common.base.ITransporterTile（Scala 结构化类型）；加载失败打 Failed to load mekanism logistical transporter class 警告并把类置 null

MekanismPushProxy 是唯一用结构化类型 + 反射的代理 —— 因为 mekanism.common.base.ITransporterTile 在 Mekanism 各版本间签名不稳定。Scala 的结构化类型（type ITransporterTile = TileEntity { def getTransmitter: ILogisticalTransporter }）在编译后走动态调用，运行时通过反射解析 getTransmitter 与 insert。

依赖

dependencies.gradle 中 BuildCraft 与 Mekanism 都是 compileOnly（仅编译期），而 Forestry、IC2、bdlib、NEI 是 api。运行时的可用性由 ItemPush.init() 的 Misc.haveModVersion 判定。

BuildCraft 的条件带版本下限：[3.0,) —— 低于 transport API 3.0 的 BC 不注册该代理。

相关条目