分区：15_助手版本迭代说明源文件：凝神珠不触发_改动说明.md篇幅：7.9 KB收录：2026-10-19 17:10

自动凝神珠不触发 — 修复说明

时间：2026-10-06 20:17　｜　工程：D:\AI空间\rxjh\旧版本更新.代码（文本主本）

一句话

是否是凝神珠 的名单里那一个 ASCII 空格，把「自动凝神」整个功能判死了。

改成「先把物品名里的空格全部剔掉再比对」，地．凝神珠 (十万) 和 地．凝神珠(十万) 两种写法都能命中。

触发链（问题出在哪一环）

功能检测时钟（每 N 秒）
  └─ _功能检测时钟_周期事件            第 892 行
       └─ .如果真 (自动凝神.选中)                    ← ① 勾选框
            └─ .如果真 (遍历背包凝神珠数量 () ≥ 1)     ← ② 卡在这里
                 └─ .如果真 (自动使用凝神珠运行中 ＝ 假)
                      └─ 启动线程 (&自动使用凝神珠)   ← ③ 线程根本没起来

遍历背包凝神珠数量 的计数靠 是否是凝神珠，而 是否是凝神珠 的名单是：

“地．凝神珠 (十万)/天．凝神珠 (十万)/…/”
        ↑ 这里有一个 ASCII 半角空格（U+0020）

名单匹配不上 → 计数恒为 0 → ≥ 1 不成立 → 线程压根不启动。<br>而且 自动使用凝神珠 里所有 写日志 都是注释状态（9960 / 9969 / 9985 / 10005 / 10116 / 10021 行），<br>所以既不搬珠子、也不报错、日志里一个字都没有 —— 完全的静默失效。

为什么是 2026-10-06 14:24 那次改动引爆的

时间	`是否是凝神珠` 的写法	实际行为
14:24 之前	`寻找文本 (名单, 物品名称, , 假) ＝ -1` ← 逻辑反了	返回真 = 不是凝神珠。于是 `遍历背包凝神珠数量` 数的是「不在名单里的物品格数」——背包里只要有任意一件别的东西就 ≥1 → 每周期都在误触发
14:24 之后	`≠ -1`（改对了）	变成严格精确匹配。名字只要差一个空格 → 恒假 → 完全不触发

也就是说：这个功能以前靠 bug 在「假装工作」。14:24 把逻辑修对之后，名单里那个空格才第一次真正暴露出来。

同一个 是否是凝神珠 还被另外 3 处调用（自动使用凝神珠 源判定、回读目标格校验、遍历凝神珠位置是否为空），
所以这一处失效会连带影响「搬到哪一格」的判断。

改动（只有 1 个子程序）

文件：旧版本更新.代码\代码\窗口程序集_MainDialogWnd.form.e.txt（12774 → 12784 行）

.子程序 是否是凝神珠, 逻辑型
    .参数 物品名称, 文本型
    .局部变量 名称, 文本型          ← 新增

    ' 名单里不要再加回空格
    名称 ＝ 子文本替换 (物品名称, “ ”, “”, , , 真)      ← 新增：剔半角空格
    名称 ＝ 子文本替换 (名称, “　”, “”, , , 真)        ← 新增：剔全角空格
    .如果真 (名称 ＝ “”)                              ← 新增：空串保护
        返回 (假)
    .如果真结束
    返回 (寻找文本 (“地．凝神珠(十万)/天．凝神珠(十万)/…/”, 名称, , 假) ≠ -1)

三个要点：

名单改成不含空格（8 项不变，仍只有「地．/天． × 十万/五百万/五千万/一亿」）。
比对前先剔空格 —— 半角 U+0020 和全角 U+3000 都剔。这样无论游戏里是哪种写法都能命中，以后谁再动空格都不会把功能改死。

子文本替换 在本工程有现成先例（11450 / 11459 行），无需新增支持库。

空串保护：寻找文本 (名单, "", , 假) 返回 0，而 0 ≠ -1 为真，会把读失败的空名字误判成凝神珠。加了 名称＝ "" 直接返回假。

验证

项	结果
字节级写入（保留 UTF-8 BOM + 纯 CRLF）	BOM ✓ / CRLF 12784 / 裸 LF 0 ✓
`.局部变量` 声明区未被注释打断	✓（易语言硬约束，已在脚本里加静态断言）
块结构配平（`.如果真` 全闭合）	✓
e2txt t2e 回转	SUCC，0 错误 0 警告 ✓
全量 466 个子程序 · L1 代码级往返比对	0 差异 ✓
本次改动子程序 L2 注释级	0 丢失 ✓（新注释都是独立行）
改动范围	diff 只落在 10433–10452（`是否是凝神珠` 一个子程序）✓
二进制核对	魔数 `CNWTEPRG`、`子文本替换` 7 处、名单已无空格 ✓
易语言 F7 编译	未代跑（见下）

F7 没代跑：你的易语言 IDE 开着，自动化探针会抢前台焦点，可能冲掉未保存的编辑，也可能把 F7 落到游戏窗口上。请自己按一次。

如果编译后还是没反应 —— 看这一个信号

遍历凝神珠位置是否为空（10024 行）里有一条活着的日志：

写日志 (… “凝神珠第” ＋ 到文本 (凝神珠格子) ＋ “格被[” ＋ 物品名称 ＋ “]占用，跳过。” …)

重新编译运行后，盯一下挂机信息框（或 log\角色名.txt）：

现象	结论	下一步
出现「凝神珠第N格被[…]占用，跳过」	名字还是没匹配上。把中括号里的原文发我，我照着改名单	名字可能有别的写法（繁体/全角括号/别的档位）
不出现，但珠子仍不搬进专用背包	名单这关过了，卡在凝神珠专用背包的基址	见下面「第二个坑」
不出现，珠子正常搬了	已修好	—

第二个坑（本次未改，等你确认）

.常量 凝神珠背包基址值, "62846428", , , 【待确认】旧=背包基址+0x0C(03B9DCEC)映射已作废(背包管理器布局已变),新容器偏移待CE钉死

这个常量自己标着「【待确认】」，注释说原来的「背包基址 + 0x0C」映射已作废，新偏移还没用 CE 钉死。<br>它被 遍历凝神珠位置是否为空（10030 行）和 遍历凝神珠背包（2078 行）使用 —— 如果它是错的，会出现「触发了但一格都搬不进去」（6 格全部跳过 → 返回 -1）。

要做的是用 CE 在游戏里搜凝神珠专用背包的数值、找访问，把这 6 格的容器地址钉死。需要你配合游戏实测，我这边没有进程句柄。

手动测试入口（不用等时钟）

界面上有两个现成按钮，可以直接验证：

_按钮1_被单击（11708 行）→ 直接调 自动使用凝神珠 ()，手动跑一次搬运逻辑。
_凝神珠背包_被单击（11680 行）→ 调 遍历凝神珠背包 ()，把凝神珠专用背包 6 格的内容打到挂机信息框，并写入 物品编号.ini（全局目录下）。

后者读的也是那个【待确认】基址，如果打出来是空的/乱码，就印证了第二个坑。

⚠️ 编译源别选错

文件	状态
`旧版本更新_修复后.e`	✅ 本次交付，2,741,455 字节，用它编译
`旧版本更新.e`	❌ 过期副本（16:33 保存）。它的 `是否是凝神珠` 还是 `＝ -1` 的反逻辑版，不含本次修复

如果你在 旧版本更新.e 里改了什么，告诉我，我同步过来。

产物

项	路径
主本（文本工程）	`D:\AI空间\rxjh\旧版本更新.代码`（12784 行）
编译源	`D:\AI空间\rxjh\旧版本更新_修复后.e`（2,741,455 字节，魔数 `CNWTEPRG`）
改动前备份	`旧版本更新_修复后.bak_凝神珠去空格前_20261006_2017.e`
主本文本备份	`_patch\form.e.txt.bak_凝神珠去空格前`
补丁脚本	`_patch\fix_凝神珠去空格匹配.py`（含断言，幂等可重跑）
审计文本（回转产物）	`_patch\rt_ns\代码\窗口程序集_MainDialogWnd.form.e.txt`

回滚：把 _patch\form.e.txt.bak_凝神珠去空格前 拷回主本，重跑 t2e 即可。

本页由 Markdown 报告自动转排；如需原始 md，可在原会话工作区取用。