SharedProspecting

[!INFO] Git Commit: dc76772 | Updated: 2026-04-25

modid sharedprospecting | 包根 com.rune580.sharedprospecting | Minecraft 1.7.10 / Forge 10.13.4.1614

简介

把 Visual Prospecting 的勘探数据在 ServerUtilities 队伍成员之间共享的纯数据 mod。队友 A 探到的矿脉会同步给同队伍在线的队友 B，双方看到完全一致的矿脉列表，且"已被挖空"的矿脉会一起同步，队友不会再看到已经被别人挖光的矿。

mcmod.info 的官方描述是 “Syncs VisualProspecting data between members in a ServerUtilities Team.”

本 mod 不添加任何方块、物品、实体、指令或配置项，全部功能通过 6 个针对 Visual Prospecting 的 Mixin 和 6 条自定义封包实现。

硬依赖

@Mod 注解原文（SharedProspectingMod）：

dependencies = "required-after:visualprospecting"
            + "required-after:serverutilities"
            + "required-after:gtnhlib@[0.5.14,)"
acceptedMinecraftVersions = "[1.7.10]"
acceptableRemoteVersions   = "*"

acceptableRemoteVersions = "*" 表示服务端装了本 mod 也不强制客户端安装。

源码规模

23 个 Java 文件，无资源型内容（无 lang 文件、无贴图、无模型、无配方）。

ClientProxy 只有一行 super.preInit(event)，与 CommonProxy 行为完全一致——本 mod 没有任何客户端专属注册。

事件生命周期

SharedProspectingMod 有 5 个 @Mod.EventHandler，全部转发给 proxy：

设置与机制

• 队伍数据模型 SPTeamData - 什么是"队伍"、队伍数据的 8 个事件挂钩、成员变更如何广播
• 维度有序缓存 OrderedDimCache - 只追加的有序坐标表、revision 即长度、区间增量截取
• 版本号同步机制 - 客户端/服务端如何保持同步、缓存未就绪的暂存、失配边界情况
• 持久化与 NBT 结构 - 服务端队伍 NBT 与客户端 revision.dat 的完整字段表、旧格式兼容与目录迁移
• Mixin 清单 - 全部 6 个 mixin 的目标类、注入点、SRG/描述符签名、两个配置 JSON
• 网络封包协议 - 6 条封包的字段、方向、1500 批量切分、维度哨兵值

本 mod 没有的内容

以下 12 个维度经源码核查确认无任何内容，因此未建目录、未生成条目。核查命令在 /Users/evlos/a/mirror/SharedProspecting/src/main/java 下执行。

方块 / TileEntity / 多方块结构 — 无

$ grep -rn "registerBlock\|registerTileEntity\|registerDimension" .
(no match)
$ grep -rn "new Block(\|extends Block\b" .
(no match)

物品 — 无

$ grep -rn "registerItem" .
(no match)

（SharedProspectingMod.java:36 有一处 GameRegistry 字样，位于 FML 模板自带的英文注释 // GameRegistry." (Remove if not needed) 中，不是代码。）

实体 — 无

$ grep -rn "registerEntity\|extends Entity" .
(no match)

服务端指令 — 无。serverStarting 是空方法。

$ grep -rn "ICommand\|CommandBase\|registerCommand\|addChatCommand" .
(no match)

配置项 — 无。本 mod 不生成任何配置文件，无 @Config、无 Configuration 实例。

$ grep -rn "Configuration\|@Config\|config\." .
(no match)

热键 — 无

$ grep -rn "new KeyBinding\|ClientRegistry.registerKeyBinding" .
(no match)

附魔 / Buff(Debuff) / 成就 / 群系 / 结构 — 无

$ grep -rn "Enchantment\|PotionEffect\|Achievement\|BiomeGen\|addStructure" .
(no match)

世界生成 / 生物生成 — 无

$ grep -rn "WorldGenerator\|registerWorldGenerator\|spawnEntity\|onChunkLoad" .
(no match)

自定义维度 — 无

$ grep -rn "registerDimension\|registerWorldProvider" .
(no match)

合成配方 / 熔炼配方 / 成就页 — 无。本 mod 无任何 resources/assets 与 resources/data 目录（src/main/resources 下只有 4 个文件：2 个 mixin JSON、1 个 AT 配置、1 个 mcmod.info）。

物品效果 — 无。同上，源码中无任何 PotionEffect 相关引用。

自己实现的队伍系统 — 无。队伍完全由 ServerUtilities 的 ForgeTeam 提供，本 mod 只通过 team.getData().get("sharedprospecting") 挂载一份数据槽。

已知限制

• getEarlyMixins 是死代码：方法已实现但全仓库无调用点，Phase.EARLY 不可达（源码自带注释 “This may be possible to handle differently or fix.”）。
• 判重是 O(n) 线性扫描：OrderedDimCache 用 LongArrayList.contains 判重，队伍数据量极大时是性能瓶颈，源码未做额外索引。
• 混血粒度不对称：矿脉增量在取出时按键查表还原（O(1)），地下流体则逐区块重新扫描世界（prospectUndergroundFluidBlockRadius，radius 0），代价明显更高。
• 客户端 pendingRevision 只保留最后一条，且丢失维度信息，补发时套用玩家当前所在维度。
• 封包零校验：MessageSendExistingData 的流体坐标键无任何校验即可入库（矿脉有 ServerCache 反查兜底）。
• 无版本兼容层：SharedProspectingMod 没有 versionCheck 逻辑，本 mod 自身更新导致 NBT 结构变化时没有迁移保障（仅有 OrderedDimCache 内部针对 ores/fluids 两个旧字段的回退）。