摘要

玩家在游戏里右键一个兵种，会看到它的属性面板（攻击、防御、伤害等）。项目里的 SE（State Estimation，状态估计）模块用截图读到的面板数值，反推对手可能带了哪些技能和宝物。做这件事之前，SE 要先问 Simulator：“这个兵身上挂着的状态会不会改变面板数值？”

曙光盔甲（三种）和狂暴（四种）这七个原生状态只改“受到 / 造成的全部伤害倍率”，但旧查询看到这两个不认识的字段，就回答“部分已知”（partial）。于是一张已保存的凤凰面板无法参与攻防核对。本实验只为这七个 ID 补上精确解释：它们不改八种面板字段。修复后凤凰面板恢复核对，297 项软件检查通过。

要回答的问题

在不改查询接口、不全库放宽字段白名单的前提下，能否证明这七个状态确实不影响面板字段，从而让 SE 用上已保存的面板？

方法

  1. 读当前安装版本（build 25672315）中这七个状态的配置，以及原生代码里面板取值的位置，逐一核对八种面板字段。
  2. 查询的返回类型、错误、版本号都不变；“已知”只指八种面板字段。证据不足的其他状态继续返回部分已知或未知。
  3. 用合法施法真正触发盔甲和狂暴，确认伤害倍率和首击、狂暴第二击确实变化，而面板字段不变。这是 Simulator 软件行为，不是真实游戏实测。
  4. 只用此前已保存的两局截图读数（49 帧和 58 帧），把 SE 完整重算一遍，前后对照。

设置

  • 修改范围：Simulator 一个文件，新增 17 行、修改 1 行。
  • 正例：01:39 那局第 24 帧的凤凰面板；负例：宠物防御候选、“绝望”状态仍未知。
  • 停止条件：若不能证明全部声明字段的范围，就不升级为“已知”，也不另造接口。

结果

  • 凤凰面板：派生的“临时属性”从“未知”变为“无”，原四个候选和读数保持。已读生物攻击 54 = 基础 28 + 英雄 9 + 战斗魔法 17；防御 39 = 26 + 9 + 4，与“没有新增来源”相符。其余七种技能 / 宝物组合在声明的有限前提下不符。这不等于认证敌方没有某技能或宝物，也不排除未建模的相互抵消。
  • 16:57 那局第 38 帧：临时属性从“未知”变为“只影响防御”，因为宠物候选仍影响防御；第 16、40 帧的“绝望”仍未知，三帧的来源核对继续阻断。
  • 原始观察去掉派生字段后逐项相等；候选、归属、排除和攻击证据完全不变。
  • Battle App（玩家使用的战斗笔记应用）严格读取通过，两份结果只改了派生状态范围和说明（9 条和 2 条）。
  • 软件检查：297 个不同测试节点通过，其中新增 40 个（提供方 20、SE 20），包括 8 种法术等级 / 种类的合法施法与攻击。

失败与负结果

过程中有 9 次仪器或夹具错误，都已记录、修正后重跑：只读探针复制只读映射报错；原生反汇编扫描在叶函数处中断，改用下一函数地址定边界后成功；测试导入路径错误；夹具布阵位置不合法；狂暴读取用错了简化取值函数；高等级狂暴的反击杀死施法兵导致第二击未出现；App 校验用不唯一的标题取说明；两处导入格式。它们都不是生产代码缺陷，也不是识别准确率问题。

局限

  • 只修这七个 ID，不推广到整个状态库。
  • 战斗夹具是显式构造的相邻初态，不代表能从布阵合法走到该位置。
  • 单帧结果说明“支持范围”扩大，不是独立的识别准确率，也不证明全部公式覆盖。

结论与下一步

有限修复达到目标：凤凰面板重新进入攻防核对，其余结果不变。随后以此为基础构建了 Battle App 本地预览包（包内 200 项 Core 与 208 项 App 检查通过），没有重跑视频或扩展状态算法。