筛选界面与数据同步

基本信息

xSize / ySize 两个类都没有覆写，因此沿用 GuiContainer 的默认 176 × 166。

库存模型

markDirty() 会把 stackSize == 0 的槽位直接置 null，所以空筛选格读出来是 null 而不是一个空栈 —— ItemOreFinderTool 与 GuiOreFinder 都依赖这一点做判空。

槽位布局（共 37 个）

被锁定的是玩家当前手持的那一格：if (i == player.inventory.currentItem) 时改用 SlotLocked（ContainerOreFinder.java:29-33）。锁定目的就是防止玩家把正在生效的魔杖从界面里拿走。

SlotFilter / SlotLocked 子类枚举

⚠️ 事实澄清：SlotFilter 与 SlotLocked 没有任何子类。源码 grep 证据：

$ grep -rn "extends SlotFilter\|extends SlotLocked" src/main/java
（零命中）

两个类各自在 ContainerOreFinder 构造器里被实例化恰好一次（1 个 SlotFilter + 1 个 SlotLocked），行为完全由它们自己覆写的方法决定。Slot 的其余 35 个子类全部是原版 Slot。

SlotLocked 通过 6 个覆写把该快捷栏格变成完全只读，任何取放路径都被堵死。

isAcceptableFilter(stack) = target.canSearch() || target.isBlocklisted()，含义是：被方块黑名单拒绝的物品仍然可以放进筛选格（放进去后界面顶部显示"黑名单方块！"警告），只有"完全解析不出目标"的物品才放不进去。

容器操作规则

transferStackInSlot(EntityPlayer player, int index)：

slotClick(int slotId, int clickedButton, int mode, EntityPlayer player) 覆写了两条拦截：

1. 该槽的 getStack() == player.getHeldItem() → 直接 return null，防止点击 / 拖动正在手持的魔杖
2. mode == 2（数字键换位）且 clickedButton 落在 0 ~ 8 → 目标快捷栏索引 1 + (9 * 3) + clickedButton；若那是 SlotLocked 则 return null

两条分支结尾都走 detectAndSendChanges()。

NBT 存档路径

筛选物存在玩家的扩展属性里，不存在魔杖的 NBT 里。

结构：

ExtendedPlayerProp
└── BuildingKit                (NBTTagList)
    ├── { Slot: 0b, <物品 NBT> }
    └── { Slot: 1b, <物品 NBT> }

不持久化的字段：OreFinderPlayerData 的 hasLastScan、lastScanX、lastScanY、lastScanZ、lastScanFilter 是纯内存扫描缓存 —— saveNBTData 只写 filterInventory，所以重登后 hasLastScan 归 false，会立即重新扫描一次。

copy(OreFinderPlayerData props) 也只复制 filterInventory（由 PlayerDataEventHandler.onClonePlayer 在玩家死亡 / 重生时调用），扫描缓存不复制。

一处遗留写法：readFromNBT 用 compound.getTagList(tagName, compound.getId()) 取列表，第二个参数传的是 compound 自身的 NBT 类型 id，而不是 NBTTagList 的 10。

网络消息

通道：NetworkRegistry.INSTANCE.newSimpleChannel("ifu")（PacketDispatcher），packetId 从 0 起递增，在 preInit 由 PacketDispatcher.registerPackets() 注册。

process 在客户端执行 OreFinderPlayerData.get(player).loadNBTData(data)，用收到的数据覆盖本地筛选格。

AbstractMessage 的三级结构（AbstractMessage.java）：

PacketDispatcher.registerMessage 按子类决定注册哪一侧：AbstractClientMessage 子类注册 Side.CLIENT；AbstractServerMessage 子类注册 Side.SERVER；两者都不是则用同一个 packetId 在两侧各注册一次。

⚠️ 本 mod 没有任何 AbstractServerMessage 的具体子类，也没有直接继承 AbstractMessage 的双向消息 —— 客户端 → 服务端的自定义消息数为 0（魔杖的扫描全部在服务端完成，客户端只负责播放音效与界面绘制）。

事件订阅

PlayerDataEventHandler（在 load() 里注册到 MinecraftForge.EVENT_BUS）：

界面文字与颜色

GuiOreFinder.drawGuiContainerForegroundLayer 画 4 类文字：

文字超宽时由私有方法 fit() 截断：trimStringToWidth(text, maxWidth - width("...")) + "..."，其中 maxTextWidth = xSize - 10 - 8。

ColorUtils 用 GTNHLib 的 ColorResource.Factory("ifu") 声明 5 个颜色：

ColorResource 机制允许按名字覆盖这些默认值。这些颜色只用于筛选界面的文字，与矿石稀有度 / 矿层显示无关 —— ColorUtils 全文件仅这 5 个常量，唯一引用者是 GuiOreFinder。

背景层只是绑定贴图并 drawTexturedModalRect(guiLeft, guiTop, 0, 0, xSize, ySize)，没有额外绘制逻辑。

相关条目

• 寻矿魔杖 - 潜行右键打开本界面
• 寻矿魔杖配置 - 3 个列表项正是本界面的筛选规则来源
• 矿石勘探效果 - 界面显示的 MatchTarget 如何判定