建造自己的魔兽世界（熊猫人之谜）

几年前我搭过一台巫妖王之怒（3.3.5）的服务器。这次换成熊猫人之谜（5.4.8），主要给家里的小朋友玩，所以用的是英文客户端，英文她读起来比中文顺。整个过程是我和 Claude Code 一起完成的：我负责在游戏里测试、提问题和做决定，它负责查源码、改配置、写补丁。

本文按时间顺序记录了到 2026-11-13 为止的工作，一共四章：

1. 服务器选型、基础设施搭建、服务端部署
2. 熊猫人新手岛（Wandering Isle）任务修复
3. 矮人新手村（Coldridge Valley / Dun Morogh）任务修复
4. 全局修复：全库任务审计和批量修复

第一章　选型、基础设施与服务端部署

1.1 版本和核心的选择

• 客户端版本：5.4.8（build 18414）。 开源的熊猫人模拟器和数据库基本都只支持这个版本。官方现在的熊猫人怀旧服是 5.5.x，版本号对不上，不能用。
• 核心：SkyFire_548。 它是从 TrinityCore 改出来的开源核心，至今还在更新。网上那些”一键包”和来路不明的商业核心是闭源的，可能有后门，出了问题也没法自己修，所以不考虑。
• 心理预期要放低。 熊猫人的模拟器远不如 3.3.5 + AzerothCore 成熟：团队副本和地下城的 Boss 脚本缺很多，场景战役、宠物对战也不完整，练级任务大体能做，但会碰到卡住的任务。后面两章基本都在修这类问题。

1.2 服务器

我直接用了手上现成的一台 AWS EC2：

小规模游玩，2 核 4 GB 就够了。服务端跑起来以后，worldserver 占内存约 1 GB，MySQL 约 0.7 GB。2 核的瓶颈在编译和生成 mmaps 时才会显现。

系统太新是个问题：SkyFire 代码比较老，直接在 Ubuntu 26.04 上编译大概率会失败。所以编译和运行全部放进 Docker，宿主机上只装 Docker CE 和 compose 插件。另外要在 AWS 安全组里放行 3724/tcp（登录服务）和 8085/tcp（世界服务），MySQL 的 3306 不对外开放。

1.3 目录和容器

所有文件都放在服务器的一个工作目录下：

claude_works/
├── SkyFire_548/          # 上游仓库 main 分支
└── mop-server/
    ├── Dockerfile        # 多阶段构建，照搬上游 CI 的编译环境
    ├── compose.yaml      # mysql:8.4 + authserver + worldserver
    ├── gen-config.sh     # 从官方 .conf.dist 生成配置，只覆盖要改的项
    ├── db-init.sh        # 首次启动时创建数据库账号
    ├── .env              # 随机生成的数据库密码（权限 600）
    ├── db/sfdb27/        # 官方世界库 SFDB 27
    ├── extract.sh        # 地图数据提取脚本，可以分步重跑
    ├── data/             # dbc / db2 / maps / vmaps / mmaps
    ├── sql-custom/       # 自己写的数据库修复
    ├── patches/          # 自己改的源码补丁
    └── backup/           # 每次改库之前的备份

• 编译环境照搬上游的 .github/workflows/ubuntu.yml：Ubuntu 24.04 + GCC 14（项目用的是 C++23），从源码编译 Boost 1.91 和 OpenSSL 4.0（开启 enable-legacy），用 CMake + Ninja 构建，同时打开 TOOLS=ON，镜像里就带上了地图提取工具。第一次完整编译在 2 核机器上用了约 37 分钟，镜像 310 MB。
• 后来改源码多了，我在 Dockerfile 里给构建目录加了 BuildKit 缓存挂载（--mount=type=cache,id=skyfire-build,target=/build）。之后改一两个脚本文件，增量编译只要 1 分钟左右。
• 数据库用 SkyFire 自带的更新器：首次启动自动建库，导入 SFDB 27，再补跑之后的增量更新。

1.4 部署时踩的坑

1. 通过 SSH heredoc 写文件，单引号被吃掉了。 db-init.sh 里的 SQL 少了引号，数据库账号没建出来，authserver 一直报”访问被拒”。后来改成在本地写好文件，再用 scp 传上去。

2. 世界库里写死了 DEFINER。 SFDB 27 的 dump 末尾有 61 个存储过程，都写着 DEFINER=skyfire@localhost。我们的账号是 skyfire@%，两者不匹配，MySQL 要求更高的权限，导入就中断了。解决办法是用 sed 去掉 DEFINER，生成 world_base.nodefiner.sql，再让 compose 挂载这份文件。这样存储过程都还在，也不需要给账号提权。

3. 导入失败后又被自动重启，留下一个半成品库。 更新器只要看到 world 库”不为空”，就会跳过基础导入，直接在残缺的库上继续跑更新。正确的处理是：删掉 world 和 characters 两个库，临时关掉 worldserver 的自动重启，重新导入；确认成功后，再把自动重启恢复成 unless-stopped。

导入成功后的数据：world 库有 180 张表、22.5 万个 NPC 刷新点、1.8 万个任务。日志里有约 500 条 “GUID not found” 之类的一致性警告，这是 SFDB 数据本身的小毛病，不影响运行。

1.5 客户端和地图数据

• 语言。 服务器不限制客户端的语言，只要求版本是 18414，而且按每个连接的语言返回文本。但 SFDB 27 的 locales_* 表全是空的，用中文客户端会看到界面是中文、任务和 NPC 是英文的混排效果。我们本来就打算用英文客户端，所以这不是问题。

• 地图数据提取直接在服务器上做：把客户端的 Data 目录（约 24 GB）传上去，用镜像里的工具依次提取：

  • mapextractor：dbc、db2、maps，约 1 分钟；
  • vmap4extractor + vmap4assembler：生成 vmaps，1.1 GB；
  • mmaps_generator：最慢的一步，2 核跑了约 6.5 小时，生成 3.1 GB。

  日志里有大量 Can't open ... .wdt，都来自 test、development、Transport* 这类开发用地图，可以忽略。mmaps 全部完成后，打开 mmap.enablePathFinding = 1，NPC 就会绕开障碍物走，不再穿墙。

• 服务器地址。 熊猫人客户端已经没有 realmlist.wtf 文件了，服务器地址只写在 WTF/Config.wtf 里：SET realmList "服务器地址"。改的时候游戏要关着，否则退出游戏时会把你的修改覆盖掉。

• 连接补丁。 5.4.8 的 Wow.exe 需要打连接补丁（SkyFire 仓库里的 contrib/Client_Patch，来自 Arctium 项目），否则登录不上。我用 Python 按补丁的字节模式检查了手上的 exe，发现它已经打过补丁：原始模式一个都匹配不上，叠加补丁字节后才各匹配到一处。如果这时再用原版工具打一遍，它会静默跳过所有模式，输出一个和原文件一模一样的 “Wow_Patched.exe”，你根本不会发现。来源不明的 exe 要先扫毒，也别在这个客户端里输入暴雪账号。

1.6 GM 账号和控制台

在 worldserver 控制台里创建账号（SkyFire 的参数顺序是”邮箱 用户名 密码”）：

account create <邮箱> <用户名> <密码>
account set gmlevel <用户名> 3 -1

小坑：Ubuntu 26.04 的 sudo 换成了 sudo-rs，它会在中间多套一层终端，用 sudo docker attach 进控制台后，Ctrl+P Ctrl+Q 退不出来。直接关掉 SSH 窗口是安全的：容器开着 tty 模式，断开 attach 不会把 worldserver 停掉。以后不加 sudo，并且换一个退出键：

docker attach --detach-keys="ctrl-x" mop-worldserver-1

1.7 方便自己人玩的配置

都写进了 gen-config.sh，重新生成配置也不会丢：

• 经验倍率：击杀 5 倍、探索 5 倍。任务经验一开始也是 5 倍，后来调回了 1 倍。

• 新角色初始金币 10 万金。

• AllFlightPaths 1：所有飞行点直接开放；InstantFlightPaths 1：飞行改成瞬间到达。后来发现它会把任务里的演出航线也变成瞬移，就改了源码，只让普通航线瞬间到达（见第三章 26094）。

• PlayerSaveInterval 300000：自动存档从 15 分钟一次改成 5 分钟一次（原因见 1.8 节 11 月 13 日那次重启）。

• MaxPrimaryTradeSkill 10：每个角色可以学全部主专业（默认 2 个）。核心在每次登录时按配置重新计算剩余的专业数，老角色也直接生效。注意英文客户端技能书的专业页只有两个主专业的位置，第三个以后不一定显示出来，但专业本身能用。

• 骑术、飞行许可和本阵营所有坐骑写进 playercreateinfo_spell，新建角色就有 36 格大包。

  这里有个意外发现：playercreateinfo_spell 不只在创建角色时生效，每次登录都会重新学一遍（Player::LoadFromDB → learnDefaultSpells），所以老角色也都拿到了。我们觉得这样挺好，就保留了。

• 每个出生点放了一个自制的装备商人（Newcomer Watcher），按职业只卖对应的装备。

• 顺手修了沙石幼龙：它的 VehicleId 是 0，不能带乘客。根据 Vehicle.dbc 选了一个空闲的双座载具 ID 填上，现在队友也能坐上去了。

1.8 崩溃排查

第一次崩溃：先打开 core dump

11 月 9 日 worldserver 段错误退出过一次（退出码 139）。我用 dmesg 里的地址加 addr2line，定位到 Player::GetQuestStatus。最大的嫌疑是熊猫人岛任务 29414 的 Aysa 冥想事件脚本 npc_aysa_meditationAI：它缓存了裸的 Player* 指针，重置时不清空，每个 tick 都去调用 GetQuestStatus。而唯一接过这个任务的角色，正好在崩溃前下线了。

不过这只是推测。我们的原则是没有调用栈就不改代码，所以先把 core dump 打开：

• 关掉 apport，core_pattern 设为 /cores/core.%e.%p.%t；
• compose 里给 worldserver 加上 ulimits: core: -1，并把 ./cores 挂载进容器；
• 宿主机装好 gdb。下次崩溃时，先看调用栈里有没有 npc_aysa_meditationAI::UpdateAI，再决定怎么改。

后来抓到的两个 core：关机时的 use-after-free

之后 cores/ 目录里陆续出现了两个 core，分别生成于 11 月 11 日 14:53 和 11 月 13 日 00:15，每个约 1.3 GB。两次都正好是我改完数据、重启 worldserver 的时候。

第一个难点：崩溃时运行的二进制已经没了。 我们几乎每天都在重新编译，第二个 core 生成 8 分钟后，镜像就又编了一版。直接用现有的二进制去 gdb，调用栈全是 ??。解决办法分三步：

1. 从 core 里读出当时那个二进制的 build-id。 core 里的 NT_FILE 记录了 worldserver 映射到的地址，那一页里还保留着 ELF 头和 .note.gnu.build-id，写个几十行的 Python 就能把它读出来。两个 core 的 build-id 分别是 18f43ca4… 和 144db24d…，和现在的二进制都对不上。
2. 按当时的源码重编一份。 复制一份源码，把第二个 core 之后打的补丁（Raid Night）撤掉，借用同一个 BuildKit 编译缓存增量编译。38 秒就编完了，build-id 正好是 144db24d…，完全一致。
3. 在镜像环境里跑 gdb。 宿主机是 Ubuntu 26.04，容器是 24.04，两边的 libc、libstdc++ 不一样。所以要在镜像里临时装上 gdb，把 core 挂载进去再分析，这样共享库也能对上。

拿到的调用栈：

#0  WorldSocket::CloseSocket() [clone .part.0]
#1  ReactorRunnable::Stop()
#2  WorldSocketMgr::StopNetwork()
#3  WorldRunnable::Run()

它不是游戏过程中的崩溃，而是关机过程中的崩溃。 主循环已经结束，正在断开所有网络连接。第一个 core 没有重编对应的二进制，但我把两个 core 栈上指向 worldserver 的返回地址一一列出来对比：网络模块的地址整体差 0x3200，主程序整体差 0x30c0，崩溃的 PC 也正好差 0x3200。所以这是同一处崩溃。

原因。 看反汇编，崩溃点在内联进来的 CloseTcpSocket() 里。它依次调用 cancel()、shutdown()、close()，崩在最后的 close() 上：从 socket 对象里读出来的指针是 0x7acba8c1421e，地址没有对齐，正是 glibc 回收内存后写进去的那种”乱码”。也就是说，这个 socket 对象在 CloseSocket() 执行的过程中被释放了。再看源码：

void Stop()
{
    std::vector<WorldSocket*> sockets;
    {
        std::lock_guard<std::mutex> guard(m_SocketsLock);
        sockets.assign(m_Sockets.begin(), m_Sockets.end());   // 只复制了裸指针
    }
    for (WorldSocket* socket : sockets)
        socket->CloseSocket();
    ...
}

Stop() 复制了连接列表，但没有给这些连接加引用计数。CloseSocket() 里的 cancel() 会让网络线程立刻执行被取消的异步读回调，回调一路走到 SocketClosed()，减掉最后一个引用，把对象 delete 掉。而主线程这时还在 CloseSocket() 里面，接着就去 close() 一块已经释放的内存。

影响。 只有关机时恰好有客户端连着才会触发，比如有人停在登录界面或者人物选择界面。保存角色的 KickAll() 在断开网络之前就执行完了，所以角色数据不会丢，只是 worldserver 没能正常退出。

修复。 在锁里给每个连接加一个引用，CloseSocket() 返回后再减掉：

{
    std::lock_guard<std::mutex> guard(m_SocketsLock);
    sockets.assign(m_Sockets.begin(), m_Sockets.end());
    for (WorldSocket* socket : sockets)
        socket->AddReference();
}
for (WorldSocket* socket : sockets)
{
    socket->CloseSocket();
    socket->RemoveReference();
}

注意不能在 CloseSocket() 自己里面加引用：析构函数 ~WorldSocket() 也会调用 CloseSocket()，引用计数会从 0 变回 1 再变回 0，导致对象被二次 delete。

改完后我做了个测试：开 20 条到 8085 端口的 TCP 连接，然后重启 worldserver。这样测了两轮，都正常退出，没有生成 core。不过原来的 bug 本身也是看时机才触发的，所以这只能说明修复没有引入新问题，还不能算证明它彻底修好了。之后每次重启都会看一眼 cores/ 目录。

11 月 13 日：一次”被重启”引出的关机顺序问题

下午 18:03 服务器突然重启，cores/ 里多了一个 core。我一度以为终于抓到了 11 月 9 日那个崩溃的现场，结果不是。

• 谁重启的： 机器自带的自动更新（unattended-upgrades）的自动重启是关着的。查 SSM agent 的日志才找到，18:00 AWS 下发了一条 Systems Manager Run Command，文档是 AWS-RunPatchBaselineAssociation，参数是 Operation=Install、RebootOption=RebootIfNeeded。这次更新里有 libc，装完就判定需要重启。AWS 的补丁策略我们决定先不动。
• 为什么崩： 主机关机时，docker 是同时停所有容器的，数据库先停了。worldserver 这时正在给在线的角色做下线存档，写库失败，重连也连不上；退出时数据库连接的句柄已经是空的，~MySQLConnection 里的 ASSERT(m_Mysql) 主动让进程崩溃。core 是关机途中写的，被截断了，gdb 只看得到 Skyfire::Assert 一层，原因是从 docker 日志里那行 ASSERTION FAILED: m_Mysql 看出来的。
• 影响： 那次下线存档没写进去，角色回到了上一次自动存档（当时间隔是 15 分钟）。
• 加固：
  • 加了一个 systemd 服务 mop-graceful-stop，排在 docker.service 之后启动，所以关机时会先于 docker 停止。它停止时执行 docker compose -p mop stop -t 120 worldserver authserver：worldserver 收到 SIGTERM 会先保存所有在线玩家再退出，最多等 2 分钟，然后 docker 才去停数据库；
  • 自动存档间隔从 15 分钟改成 5 分钟（PlayerSaveInterval 300000，写进了 gen-config.sh），出事时最多丢 5 分钟。

顺带记一个坑：etc/worldserver.conf 是单文件挂载进容器的。用 sed -i 改它，会生成一个新文件来替换原文件，运行中的容器还挂着旧文件，所以 reload config 读到的仍是旧值，必须重启容器才生效。

编译缓存的小插曲。 为了还原旧二进制，我在共享的编译缓存里编过一份”撤掉补丁”的源码。之后正常编译时，ninja 只看修改时间：真实源码比缓存里的 .o 旧，就不会重编，结果编出来的 worldserver 里少了 Raid Night 的脚本。我用 nm 检查时发现了这个问题，于是把所有改动过的文件 touch 一遍。但 Docker 的层缓存只认文件内容、不认修改时间，又把整个编译步骤跳过了。最后在源码目录里临时放一个标记文件，让 COPY 层失效，才真正重编。以后再借用编译缓存做这种事，最好单独用一个 cache id。

1.9 修任务的工作方式

修之前我先确认了一件事：核心和 SFDB 都已经是上游最新版本，所以等上游更新是修不好这些任务的。另外，通用的任务物品掉落是正常的（20 个各种族的”收集掉落物”任务都完成了），坏的都是个别任务的数据或脚本。于是定了几条规矩：

• 只修”真的坏了”的，不降低难度。 缺 NPC、缺脚本、缺刷新点、进度根本拿不到，这些算坏了，要修。东西难找、需要自己动脑子的，保持原样，不加提示，也不挪位置。拿不准算哪一种时，先讨论再动手。

• 数据库修复写成 sql-custom/日期_序号_名字.sql，改之前先把相关的行导出到 backup/。以后重建数据库，要把这些文件按顺序重新执行一遍。

• 源码改动导出成 patches/*.patch。不卡进度的 C++ 改动先攒着，攒够一批再编译重启。

• 有两个热重载命令千万别用错：

  • reload spell_area 不会清空 mSpellAreaForAreaMap，会留下悬空指针（use-after-free）。改了 spell_area 就重启 worldserver，不要热重载。
  • reload smart_scripts 不会更新已经刷出来的生物，因为 SAI 在生物创建时就把脚本复制了一份。这种情况同样要重启。

  而 reload conditions 和 reload quest_poi 可以放心热重载。

第二章　熊猫人新手岛任务修复

熊猫人新手岛（Wandering Isle）是这个服务器里问题最集中的地方。查了很久才找到根源：上游的 commit 2f8c98dc67（“Drop dead code”）把新手岛的一大批 NPC 脚本当成死代码删掉了，但数据库里这些 NPC 的 ScriptName 还留着。结果就是 NPC 站在那里，什么都不做。之后再遇到”有 ScriptName 却找不到代码”的新手岛 NPC，第一步就是 git show 2f8c98dc67，把原来的代码找回来。

第二个大问题是相位（phase），后面好几个任务都栽在这上面。

29423 The Passion of Shen-zin Su：Huo 下线就丢，相位不刷新

• 现象： 要护送火精灵 Huo 回神庙，下线再上线 Huo 就没了，任务卡住。
• 原因：
  1. Huo 是法术 128700 召唤出来的临时守护者，下线时会消失，但 128700 的光环还保存在角色身上，所以系统不会再召唤一次。
  2. 交付进度靠区域触发器 AT 7835 的一次性脚本，要求 Huo 在 15 码以内，很容易错过。
  3. 核心的相位 bug： UpdateAreaPhase 只会在进入区域时加上 phase_area 定义的相位，离开时从不移除；接任务、交任务时也不会重新计算区域相位，只有重新登录才会。
• 修复：
  • 新增一个 PlayerScript，登录时如果有 128700 光环就重新召唤 Huo；
  • 把交付逻辑抽成一个共用函数，判定半径放宽到 40 码，再加一个”看见 Shang Xi 就交付”的兜底；
  • 在 Object.cpp 里补上离开区域时移除相位的逻辑，并在接任务、设置任务状态、交任务、放弃任务时重新计算区域相位。注意不能放进 UpdatePhasing：移除相位光环时会调用它，结果又会把相位加回来。

29663 Lesson of the Balanced Rock：被删掉的脚本

站在木桩上的 Tushui 武僧（55019）的脚本被上游删掉了。我把它恢复了：武僧会自动站上 8 码内最近的空木桩，被打败后消失；同时把它们的游荡改成原地不动。顺带一提，同一组的 29661 Lesson of Dry Fur 其实没坏，只是没找到那口铃铛。

31450 A New Fate：选阵营的灵魂不能对话，交任务的 NPC 不存在

• 对话： Master Shang Xi 的灵魂（56013）的 npcflag 只有任务标记，没有对话标记。任务图标消失后，玩家就点不出对话了。补上对话标记后，选阵营的界面能弹出来，传送去暴风城或奥格瑞玛也正常。
• 交任务： 两边负责交任务的 Aysa（60566，联盟）和 Ji（60570，部落）在数据库里根本没有刷新点。我把他们刷在传送落地点前方 4 码处。暴风城的落地点在城市建筑模型（WMO）上面，地形高度比实际站立高度低了将近 30 码，所以 z 坐标要用建筑表面的高度。

29678 Shu, the Spirit of Water：跳石头跳回原地

河里的跳石是陷阱型游戏对象，踩上去会强制施放 Rock Jump A/B/C。脚本里调用了 MoveJump，但法术默认的 EffectJumpDest 效果会在之后执行。因为 DEST_DB 类型的目标在 spell_target_position 表里没有数据，默认效果就把玩家”跳到自己身上”，覆盖掉了脚本的跳跃。在三个法术脚本里加上 PreventHitDefaultEffect 就好了。

29770 Still Good!：不是 bug

要收集的南瓜（Pilfered Pumpkins，17 个）在地鼠洞（Virmen Grotto）里，不在旁边那片装饰用的南瓜田。这个算”难但能做”，保持原样，最后靠自己找到了。

29792 Bidden to Greatness：护送脚本被删

原来的护送脚本 mob_mandori_escort 被删掉了。我没有完整还原护送过程，而是写了一个区域触发器脚本：任务未完成时走到 Mandori 门口给一个进度，走到 Pei-Wu 门口再给一个。流程比原版简单，但任务能完成了。

29794 None Left Behind：背伤员

• 恢复了受伤水手（55999）的脚本：右键水手，他会坐上玩家的”载具位”让你背着走；送到 Delora 旁边，任务进度加一，水手道谢后消失。
• 第一次测试时水手背上了，但交付点没反应。原因是玩家处于载具状态时，客户端似乎不发送 CMSG_AREATRIGGER。于是改成由水手的 AI 自己判断：离交付点 15 码以内就算送到。

30767 Risking It All：没有路径点的护送

原版的护送 NPC 和对话都被删掉了，数据库里也没有路径点。我做了个简化版：玩家任务未完成、走到坠毁的飞艇边时，直接给进度，播放动画（movie 117），1 秒后把玩家传送到坡下交任务的 Ji 身边。没有原版的对话。

29799 The Healing of Shen-zin Su：治疗事件

恢复了 Ji（57739）的事件脚本和治疗者（60878/60896）。附近有任务未完成的玩家时，持续召唤治疗者和来捣乱的鱼人（Deepscale Fleshrippers）。每 3 秒按存活的治疗者数量累计进度，通过替代能量条显示，到 700 就完成，大约 3 到 5 分钟。

29786 Battle for the Skies：Boss 看不见，还卡在 Evade

• 看不见： 接任务后，Aysa 把玩家放进了相位 524（为了显示炮台），而 Zhao-Ren 在相位 0。按 WorldObject::IsPhased 的规则，玩家的相位列表必须为空或包含 169，才看得见相位 0 的对象。重新登录能看见 Zhao-Ren，但炮台又没了。修复方法是：接任务时同时加上相位 169，再用 phase_area 规则保证任务期间该区域是 169 + 524。
• Evade： 所有攻击都显示 “Evade”。EnterEvadeMode 先设置 UNIT_STATE_EVADE，然后让它飞回出生点；但 Reset() 清掉了移动，回家的移动没到终点就结束了，Evade 状态也就永远不会被清除。修复是：在 Reset 里清除这个状态，并重写 EnterEvadeMode，让它不再飞回出生点。

29421 Only the Worthy Shall Pass：一刀秒杀导致 NPC 消失

• 现象： 打完 Li Fei，负责交任务的 Li Fei 不见了，要重新登录才出来。
• 原因： 我们的装备太好，一下就把 Li Fei 从 20% 以上的血量直接打死了。智能脚本（SAI）里”血量在 1%–20% 之间时给进度并切换相位”的事件根本没有触发。击杀本身让任务完成了，但玩家还留在旧相位 631 里。
• 修复： 纯 SQL，加了两个死亡事件，在 Li Fei 死亡时给击杀者切换相位；顺便修了一条接反了的事件链接。SAI 在生物创建时就复制了脚本，热重载对已经刷出来的 Li Fei 无效，所以要重启。

29679 A New Friend：水精跳到远处就停了（实测抽检）

这一段是跟着水精 Shu 在倒影池里追水柱：Shu 随机跳到 4 个池边位置之一，2 秒后在身边召出水柱，7 秒后喷发，踩在上面的玩家计数。脚本（npc_shu_pool_of_reflection）是在的，问题在它的”还有没有人在玩”检查：每轮水柱消失后只在 Shu 周围 20 码内找接了任务的玩家，找不到就停；重新启动也要求玩家走进这 20 码。可 4 个跳点之间隔着 20–50 码，玩家只要没紧贴着 Shu，它跳到远处就停住了——实测时角色在池子西边缘，离最近的跳点也有 28 码。把半径改成 60 码，覆盖整个池子（补丁 patches/2026_11_13_05_zone_wandering_island_cumulative_incl_shu_pool_radius.patch）。

29775 The Spirit and Body of Shen-zin Su：牛车点了没反应（实测抽检）

任务说”路边有辆车等着送你去神庙”。车就在 Dai-Lo 农场，鼠标移上去有上车的箭头，但点了没反应。新手岛一共有三个这样的牛车站：Singing Pools → Dai-Lo 农场、Dai-Lo 农场 → 神庙、天火号坠毁点 → 神庙。三个站的问题完全一样：

• 点击法术不对。路边那辆车点击时施放的是通用的”骑乘载具”（46598），可它本身不是载具，所以什么都不发生。法术数据里其实有正确的法术，比如 114453 “Summon Ox Cart, Farmlands -> Temple”：在路边那辆车的位置召出一辆能坐人的车（59496），把点击的人放上车，再触发 114454 在旁边那头牦牛的位置召出一头会走路的牦牛（59498）；
• 召唤位置缺条件。这两个法术的目标类型是”附近某个 NPC”（46），必须用条件指明是哪个 NPC，没有条件就找不到目标、什么都不召。补上：车召在路边那辆车的位置，牦牛召在旁边那头牦牛的位置；
• 没有路线。上游原来的脚本（spell_grab_carriage、npc_nourished_yak）已经被当作死代码删掉了，而且从来没有路线数据（script_waypoint 是空的）。

路线我没有手画，而是又写了一个小工具 navpath（tools/navpath/），做法和 vmapcheck 一样：用服务端自带的 Detour 寻路库，直接读服务端的寻路网格（mmaps），算出两点之间真正能走的路，每 5 码取一个点，每个点都贴到网格表面上。三条路线分别是 488、554、699 码（101、124、145 个路点），只走地面不走水。去神庙的两条都停在神庙大台阶脚下。

行为全部用 SmartAI 实现：牦牛被召出来就沿路线走；车 0.5 秒后跟在牦牛后面；牦牛走到终点时把车收掉（乘客自动下车），自己再消失。召唤物只存在 5 分钟，最长那条按默认步行速度要 280 秒，太紧，所以牦牛和车的步行速度加倍，最长约 140 秒。文件是 sql-custom/2026_11_13_42_wandering_isle_ox_carts.sql，由 tools/gen_ox_carts.py 生成。

实测：Dai-Lo 农场这一站可以上车，牦牛拉着车一路走到神庙台阶下放人。

再回到 29423：相位 632 一直不走

上面那段 Li Fei 脚本会把玩家放进相位 632，但没有任何地方再把它移除。结果是所有相位 0 的 NPC 都看不见，包括神庙里的 Shang Xi，所以 Huo 交付不了，任务也交不了。修复方法是：在 Huo 的接任务回调里先移除 632 并刷新相位，再给祝福、召唤 Huo。

小结

第三章　矮人新手村任务修复

矮人这条线的问题，比熊猫人岛的”零散”：很少有整段脚本被删，多数是某个 NPC、某条条件、某个阵营值缺了。大部分改 SQL 就够了，只有两个任务要写 C++。

24477 Dwarven Artifacts：箱子”已被使用”（全服修复）

• 现象： 点矮人文物的箱子，客户端提示 “That is already being used”。
• 原因： 全库有 126 个宝箱类游戏对象（type 3）的刷新状态 state 是 0，而客户端把 0 理解成”正在被使用”。潘达利亚的矿点、草点也在其中。
• 修复： 统一改成 1。这是本服务器的第一个数据修复，对全服生效。

24489 Trolling for Information：偷听不到巨魔说话

任务要求站在巨魔祭司旁边偷听。偷听靠的是区域光环 69991，但它在 spell_area 里的 autocast 是 0，而所有任务相关的行里只有这一行是 0。改成 1 以后就正常了。这个光环是隐藏的，没有增益图标，需要站在祭司 10 码以内。

教训： 一开始我用 reload spell_area 热重载，读了源码才发现它不会清空内部映射表，会留下悬空指针。之后凡是改 spell_area，一律重启 worldserver。

412 Operation Recombobulation：地图标错了位置

任务本身没坏：要收集的齿轮（Gyromechanic Gear）是 Frostmane Scavenger 100% 掉落的任务物品。但 quest_poi_points 里的地图标记指向了 New Tinkertown，那是侏儒任务 26222 收集零件的区域，数据被抄错了。我把 POI 重画到 Frostmane Front，用 reload quest_poi 热重载就生效了。后来发现当时看错位置，主要是地图插件标错了，但服务端的数据确实是错的，所以修复保留。SFDB 里可能还有别的任务 POI 也是这样抄错的。

25839 The Ultrasafe Personnel Launcher：发射器点了没反应

• 原因： 两台发射器（41398）没有 npcflag，没有右键施法，也没有任何脚本，点了什么都不会发生。这个任务没有任务目标，只能靠法术 77393 完成：它会把玩家击飞，空中给一个降落伞，最后直接完成任务。
• 难点： 77393 是对自己施放的击退。核心对”击退自己”会随机挑一个方向（Position::GetSinCos），玩家可能被弹到任何地方。
• 修复：
  • SQL：给发射器加上右键施法，条件是接了任务且未完成；
  • C++：新增法术脚本 spell_q25839_ultrasafe_personnel_launcher，击飞方向取最近那台发射器的朝向。两台发射器本来就朝着目的地，这样每次都能飞到对的地方。

28868 The View from Down Here：把自己缩小了

望远镜道具（Viewpoint Equalizer）施放的法术 93773 能把目标缩小 55%，但它的目标类型是”任意单位”，又没有任何限制。没选中目标时，就把玩家自己缩小了，而且这个光环是永久的（持续时间 -1，会存进 character_aura）。修复方法是加一条条件，限定目标只能是 Frostmane Builder。至于已经缩小的角色，要在离线时删掉那条光环记录。

25841 Strike From Above：信号弹打不出效果

信号弹（Signal Flare）施放的法术 77488 是”附近指定 NPC”类型，但缺了限定目标的条件（conditions 类型 13），南北两个标记点的 NPC 也没有任何 AI。补上条件后，再用 SAI 写成”被法术命中 → 给施法者击杀进度”。原版的飞机飞过轰炸动画没有重做。

25905 Rams on the Lam：吹口哨唤不回山羊

走失的山羊（Stolen Ram，26 只）没有 AI。用 SAI 补上：收到 /whistle 表情时给进度，跟着玩家走 4 秒后消失。注意表情只会发给当前选中的目标，所以要先选中山羊再吹口哨。

25932 It’s Raid Night Every Night：整个事件不存在

这个任务完全没有事件数据：负责计数的 NPC 一个刷新点都没有，也没有 AI；相关的法术没有被任何地方用到；数据库里那个突袭者（41603）只是一个 1 级友好的占位 NPC。只能自己写：

• 新建 zone_dun_morogh.cpp，加进 CMakeLists 和 ScriptLoader；
• Sergeant Flinthammer（41578）：玩家接任务时，或者带着这个任务走到他 30 码以内时，就开始事件。一共 3 波，每波 3 个巨魔，从西边营地方向出来攻击玩家；一波死光 8 秒后来下一波，三波都打完，就给 150 码内的参与者计数；
• 如果附近已经没有有效的参与者，或者事件超过 6 分钟，就收场清理。

波数和每波人数是我们估计的，原版的数值查不到。

25997 Dark Iron Scheming：掉任务物品的队长不存在

图纸是 Captain Beld 100% 掉落的，但 Beld 一个刷新点都没有。我参考任务 POI 和旁边黑铁间谍的位置，把他刷在了建筑里面。

25978 Entombed in Ice：冰块打不动

被冻住的山地人会召唤一个冰块（Icy Tomb 41768），任务要你把冰块打碎。但召唤属性沿用了模板阵营 35（友好），冰块打不动。把它的阵营改成 7（中立，可以攻击）就好了。

26078 Extinguish the Fires：大部分火点扑不灭

• 现象： 铁炉堡机场一共 15 个起火点，只扑灭了两个。
• 机制： 灭火装备放出的法术 78369 是”面前 10 码扇形”的空效果（DUMMY），命中隐形的计数 NPC（Burning Bomber Credit 42046）后，由它的 SAI 给进度。
• 排除过的方向： 法术的区域限制（所有火点都在允许的区域里），以及命中数量上限（没有设）。
• 原因： 大部分计数 NPC 离地 1–4 码，正好嵌在燃烧的轰炸机残骸模型里。核心在 Spell::CheckEffectTarget 里会做视线（LOS）检查，残骸模型挡住了视线，法术就跳过它们。能扑灭的正好是贴在地面上的那两三个。
• 修复： 在 disables 表里只给这一个法术关掉视线检查（flags 64 = SPELL_DISABLE_LOS，法术本身不受影响），用 reload disables 热加载。库里本来就有同样的写法，注释是”bunnies sit inside the towers”。

26085 Rallying the Defenders：插完旗人物和镜头卡一下

• 现象： 旗子能插，任务也能完成，但每次插完人物和镜头都会卡一下。
• 原因： 插旗法术 78395 有三个效果：在目标物体（雪堆 Loose Snow，也是施法焦点）上立旗、碰一下雪堆、触发计数。核心按顺序处理效果，立旗（效果 0，TRANS_DOOR）时，雪堆的位置还没被记成目的地（要到效果 2 才设），于是 EffectTransmitted 退回用施法者的位置——旗子直接立在了角色身上，角色卡进旗子的碰撞模型，镜头也撞上去。
• 修复（C++）： 效果的目标如果是一个游戏物体，就把旗子立在那个物体的位置上。我把整个法术库扫了一遍，用”在目标物体上生成物体”这种写法的只有这一个法术，改动不会波及别的法术。补丁：patches/2026_11_13_03_plant_banner_on_snow.patch。

26094 Striking Back：轰炸机点了没反应

• 原因： 跑道起点那架修好的轰炸机（Repaired Bomber 42092）没有右键施法，点上去什么都不会发生。按原设计，点它会放法术 78510，把玩家送上一条绕机场一圈的专用航线（2203，起点终点都是节点 575，坐骑是 42097）。飞行中用任务给的炸弹（Iron Hammer Bomb，78499）炸地面上的黑铁矮人。
• 还有两个坑：
  1. 炸弹是”落点 10 码内所有指定 NPC”类型，却没有任何条件，会把机场上友方的卫兵、山地人一起炸到；
  2. 我们开的 InstantFlightPaths 对这条航线也生效：起点和终点是同一个点，玩家会被直接传回原地，根本飞不起来。
• 修复：
  • SQL：轰炸机加右键施法（条件：接了任务且未完成），炸弹只对黑铁一方生效（火焰术士、入侵者、两种魔像、General Grimaxe）；
  • C++：Player::ActivateTaxiPathTo 里，瞬间飞行只对普通航线生效。由法术触发的航线是任务演出，要真正飞完全程（补丁 patches/2026_11_13_04_instant_taxi_not_for_spell_flights.patch）。

顺带一提：Player.cpp 是 CRLF 换行，第一次用 Python 打补丁时整个文件被转成了 LF，diff 有四万多行。退回后改用 open(..., newline="") 重新打，最终改动只有 3 行。

26102 Grimaxe’s Demise：将军打不动

General Grimaxe（42010）站在他的黑铁魔像（42008）头顶上，模板里带着”对玩家免疫”的标志（IMMUNE_TO_PC | IMMUNE_TO_NPC），而魔像、Grimaxe 和配套的控制 NPC 都没有任何脚本，所以他永远打不动。修法是用 SAI 重建一个流程：先打死魔像，Grimaxe 解除免疫，喊一句话后冲向最近的玩家。

这个”先打魔像”的流程是我们根据数据推测的，原版细节查不到。

26118 Seize the Ambassador：带不走大使

• 机制： 对大使（Ambassador Slaghammer 42146）使用手铐，法术 78628 会召唤一个”被押解的大使”（42153）。任务是事件型的，完成要靠法术 78642（Credit for Arresting Slaghammer，目标是”召唤者”）。
• 原因： 召唤属性 2967 在核心里落到普通召唤分支，被押解的大使只会站着不动；整个库里也没有任何东西会施放 78642，任务永远完成不了。原来那个大使也不会消失，会出现两个。
• 修复（SQL + SAI）：
  • 手铐只能对大使用，并且要接了任务；
  • 原来的大使被铐住后消失（2 分钟后刷新，别人也能做）；
  • 被押解的大使跟着玩家走，走到 Moira Thaurissan 10 码以内时，自己施放 78642（玩家拿到完成），说一句话后消失。

小结

第四章　全局修复

一个个任务边做边修，效率太低：小朋友卡住了，我才去查，查完再编译重启。做完矮人新手村后，我们换了策略：把前面修过的 bug 归类，每一类写成一个自动检测，扫一遍全库所有任务，提前把问题找出来批量处理。

4.1 种族限制（全服）

这个问题是给两个 GM 角色批量标记任务时顺带发现的。quest_template.RequiredRaces 里有 2224 个联盟任务写的是 1101（人类、矮人、暗夜精灵、侏儒、德莱尼），2027 个部落任务写的是 690（兽人、亡灵、牛头人、巨魔、血精灵）。这些都是大灾变之前的老掩码，不包含狼人、地精和两边的熊猫人。核心的 SatisfyQuestRace 只是简单按位比较，所以这几个种族根本接不了这些任务。

修法是一条规则：只要掩码包含了某个阵营全部的老种族，就把这个阵营的新种族补上。按这个规则改了 4349 个任务和 30 条阵营区域光环（spell_area，比如达拉然的阵营设定、冰冠堡垒的阵营增益、冬拥湖）。

有两处要单独处理：

• conditions.ConditionValue1 是 MEDIUMINT，存不下熊猫人那几位的种族位。唯一受影响的是儿童周任务 558 的接取条件，改成了”阵营 = 联盟”。
• 13 个任务用的是”某阵营减去一个种族”的掩码（77 = 联盟减德莱尼，178 = 部落减血精灵，255 = 前 8 个老种族）。它们是故意排除那个种族的，因为那个种族有自己专用的一版任务。这些也补上了新种族，但原本排除的种族照旧排除，否则那个种族会看到两份重复的任务。

文件：sql-custom/2026_11_13_07_faction_race_masks.sql（可以重复执行）。

4.2 审计脚本

tools/quest_audit.py 是只读的，跑一遍大约两分钟，结果写到 audit/quest_audit.json。它把前面遇到过的 bug 都变成了检测：

“有没有被引用”的判断用的是：全库的召唤法术、SAI 动作、老式脚本命令，加上把 C++ 源码里所有数字都收集起来做兜底（C++ 里写了这个编号，就当它可能被代码处理了）。

4.3 校准：先把误报压下去

第一轮跑出来的数字吓人：1416 个任务的发任务 NPC 不存在，2175 个交不了。抽样一看，误报的来源很清楚：

• 大灾变删掉的旧任务。 凄凉之地、费伍德、丹莫罗的很多旧任务在库里还有记录，但发任务的 NPC 早就不在了。玩家根本接不到，不是 bug。于是加了”可接性”计算：发任务的 NPC/物体在场，或者起始物品拿得到，或者前置任务能做完，才算玩家能接到。只对能接到的任务报问题，另外单独找”前置能做、后续却接不到”的断链。

• 对立阵营。 没有种族限制的任务，有不少其实是部落 NPC 发的。按发任务 NPC 的阵营模板（FactionTemplate）判断敌对，过滤掉。

• 物体施放的法术。 熊猫人新手岛的铃铛、卷轴、火盆，计数法术是玩家点物体时由物体施放的（goober 的 data10、spellcaster 的 data0 等），一开始没算进去。

• 无害的标记法术。 灭火这类”空效果命中计数 NPC”的法术，没条件也能工作，只是会顺带标记旁边的单位。只把伤害、缩小、变形、以及”放错位置”的情况算作问题。

• 载具。 Vehicle::Vehicle 会根据座位自动加上点击标记，218 个”缺点击标记”里绝大多数是载具，真正缺的只有十几个。

• 前置任务。 后来修暴风城的 29399 Shopping Around 时才发现：发任务的 NPC 在场，不代表能接到。29399 要先做完 29398，而 29398 的发任务人根本没有刷新点。于是”可接性”又加了一条：前置任务（PrevQuestId，以及 NextQuestId 指向它的任务）也必须能接到，迭代到不再变化为止。能接到的任务从 8899 降到 8597，联盟剩余的阻塞任务从 846 降到 734。

校准的标准是：玩家实际做完过的任务（排除两个批量标记的 GM 角色）一定是好的，如果审计把它们标成有问题，就是误报。最后几类核心检测在这个对照上都是零误报。抽查剩下的条目，也都是真问题，比如黑海岸 13518 The Last Wave of Survivors 要救的 4 个幸存者全库都没有刷新点，贫瘠之地 King Reaperclaw 有刷新点但掉落表是空的，任务要的角永远拿不到。

4.4 审计结果

联盟能接、非日常非节日的任务里，有明确阻塞问题的一共 1354 个：

60 级以下大约 550 个，80 级以上（大灾变、熊猫人区域）大约 620 个。丹莫罗、洛克莫丹基本干净，问题集中在千针石林、荆棘谷海角、凄凉之地、燃烧平原、荒芜之地、东西瘟疫之地这些区域。

处理方针是我定的：

1. 能接到却交不了的任务，直接禁用，让玩家接不到，免得白做；
2. 其余需要重建内容的问题，按等级段从低到高一批批修；
3. 机械性的标志错误马上修。

下面每一批都附上逐项清单。

4.5 批次一：机械性修复

文件：sql-custom/2026_11_13_12_audit_mechanical_flags.sql，备份：backup/audit_mechanical_20261113.tsv。

• 16 个非载具 NPC 有点击法术却没有点击标记（npcflag | 16777216），点了没反应。只配了”骑乘载具”法术（46598、43671、66245）、本身又不是载具的跳过了，加标记也没用。
• Time-Lost Shrine（222776，任务物体）13 个刷新点里有 5 个 state = 0，和 24477 的箱子是同一类问题，改成 1。

4.6 批次二：禁用交不了的任务

判定条件：玩家能接到这个任务，但它的每一个交任务 NPC/物体都没有刷新点，也不会被任何法术、SAI、脚本召唤，C++ 里也没有引用；或者干脆没有交任务方，又不是自动完成的任务。

• 用 disables 表禁用（sourceType = 1，注释 auto-audit 2026-11-13: no reachable quest ender），普通玩家接不到，GM 仍然可以接；
• 禁用之前确认过：没有任何玩家做完过这些任务，也没有人正接着；
• 依赖它的后续任务本来就做不了，禁用不会让情况更糟；
• reload disables 热加载就生效。

文件：sql-custom/2026_11_13_13_audit_disable_uncompletable_quests.sql，清单：audit/disable_candidates.json。

要特别注意其中的 31013 The Horde Way：这是部落熊猫人选完阵营后的下一个任务，交任务的 Garrosh Hellscream 在库里没有刷新点，按规则也禁用了。以后要走部落熊猫人线，需要回头补上。

4.7 批次三：任务物品的”标记法术”没人接

这是从审计结果里找出来的一个可以自动修的模式，和 25841 信号弹、13509 War Supplies 一样：

• 任务目标是一个隐形的计数 NPC（带免疫或不可选中标志），除了”杀掉它”以外没有任何计数方式；
• 任务给的物品，法术是对单位的空效果（DUMMY 或 DUMMY 光环），本来应该由计数 NPC 收到法术后给玩家计数；
• 现在两样都缺：法术没有限定目标，会随便打中附近最近的单位；计数 NPC 身上也没有”被命中就计数”的脚本。

tools/fix_pattern_c.py 按规则生成修复：

• 给”按编号挑目标”的法术加条件（conditions 类型 13），只能打中这些计数 NPC，原本已有条件的不动；
• 给计数 NPC 加 SAI：被这个法术命中时，给施法者计数。

跳过的情况：计数 NPC 已经有 AI 或脚本的，标记法术挂着 C++ 法术脚本的（可能已经在代码里处理了），物品法术不是无害标记的（比如即死、伤害类，需要另想办法）。最后 76 个任务符合条件，涉及 128 个计数 NPC、67 个法术，加了 131 条 SAI、60 条条件。

重启后启动日志里有 15 条提示”这个 NPC 另有一个计数法术”（There is a killcredit spell for creatureEntry ...）。意思是库里本来有一个专门给它计数的法术，但审计确认没有任何东西会施放它，所以这里直接计数，不会重复计数。

文件：sql-custom/2026_11_13_14_audit_pattern_c_mark_spells.sql，备份：backup/audit_pattern_c_20261113.tsv。

4.8 批次四：1–19 级的掉落表（模式 A）

审计里”要收集的物品没有来源”这一类，很多其实是掉落表空了：掉这件物品的怪还在、也刷着，只是掉落表里没有这一行。比如贫瘠之地的 King Reaperclaw 有刷新点，可他的 lootid 是 0，任务要的角永远掉不出来。

原始的掉落数据找不回来了，但有一个可靠的线索：客户端缓存里，每个生物和物体都带着一份”身上可能有的任务物品”列表，在库里是 creature_template / gameobject_template 的 questItem1..6（库里分别有 4366 个生物、1588 个物体填了这份列表）。tools/fix_pattern_a.py 就按这份列表还原：

• 列表里有这件物品、并且有刷新点的生物：把物品加进它的掉落表，设成任务掉落（掉率写成负数，只有身上有这个任务的玩家才会掉）。任务只要 1 件，或者这个生物刷新点不超过 3 个（多半是有名字的头目），掉率给 100%；其他给 50%。原本 lootid 是 0 的，顺手设成自己的编号；
• 列表里有这件物品、并且有刷新点的宝箱类物体：加进宝箱的掉落表，100%；
• 物品本来有别的获取方式（比如对尸体或物体使用道具），只是那个法术没人施放的，不当成掉落问题处理，留给人工。

1–19 级段（扣掉已禁用的任务）的结果：还原了 40 件物品、93 条掉落，写库后逐条核对过；53 条需要人工处理。

文件：sql-custom/2026_11_13_15_audit_pattern_a_loot_1_19.sql，备份：backup/audit_pattern_a_1_19_20261113.tsv（相关生物/宝箱原来的 lootid/data1 和原有的掉落行）。改了模板，所以重启后才生效（已重启）。

有两处值得一提：

• Elemental Goo（52506）是珠宝加工日常要的材料，缓存里有 40 个深岩之洲的元素生物带着它，这次都加上了掉落。这个日常的最低等级是 1，所以落在这一段里。
• Kaja’Cola Zero-One（52483）的缓存来源同时有怪和三种宝箱，两边都还原了。

4.9 批次五：1–19 级”目标不存在”，先修矮人路线

这一类没有统一的模式，几乎每个任务都是一个独立的机制：对话、坐载具、演出事件、伪装潜入……一个个查。名单里标成”联盟”的 42 个任务也不全准：银松森林、贫瘠之地、艾萨拉、科赞的发任务 NPC 是中立阵营，被误算成了联盟。我按小朋友的路线排了顺序，先修矮人会经过的这几个。

名字对应的计数（模式 C2，tools/fix_pattern_c2.py）。 查 26868 时发现了第三批的一个变种：任务计数用的是一个叫”某某 Credit”的隐形 NPC（没有刷新点），而真正要标记的是同名的那个刷新着的 NPC；任务物品的法术是无害的标记，却没有限定目标，被标记的 NPC 身上也没有给计数的脚本。规则：计数 NPC 名字去掉 Credit 之类的后缀后，正好对应唯一一个有刷新点、没有 AI 的 NPC，就给法术加目标条件，再给那个 NPC 加”被命中就给计数”的 SAI。1–19 级段命中 2 个任务（全库只有 4 个），文件 sql-custom/2026_11_13_16_audit_pattern_c2_1_19.sql，备份 backup/audit_pattern_c2_1_19_20261113.tsv。

文件：sql-custom/2026_11_13_17_embalmers_revenge_stitches.sql（备份 backup/stitches_20261113.tsv）、sql-custom/2026_11_13_18_ironforge_dailies_areatriggers.sql。重启后启动日志提示库里另有一个给”抓到小龙虾”计数的法术 99424，但同样没有任何东西施放它。

4.10 批次六：1–19 级事件型任务，先修西部荒野

“事件型任务没有触发”这一类里，有一大半是节日任务（万圣节灭火、仲夏节抛火炬、儿童周），平时本来就接不到，先不动。剩下的联盟任务里，最重要的是西部荒野 10 级左右的主线剧情。

这几段剧情的演出 NPC（Lou 的旧房子 42500、往日幻象 42693、Helix Gearbreaker 42655、Vanessa VanCleef 42371/42372……）没有脚本、没有刷新点，creature_text 里也一条原版台词都没有，zone_westfall.cpp 里同样没有。要还原演出只能自己编台词，那就不是原版了。所以和新手岛的 30767 一样做最小修复：保留玩家要做的动作，跳过演出，任务事件直接完成。

文件：sql-custom/2026_11_13_19_westfall_events.sql，备份：backup/westfall_events_20261113.tsv。

同一类里还有两个护送任务（黑海岸 5713、秘血岛 9759），以及部落那边的几个，留到后面。

4.11 批次七：两个护送任务

两个任务的发任务 NPC 都在，但没有脚本、没有路径点，上游 git 历史里也从来没有过对应代码。用 SAI 重建（文件 sql-custom/2026_11_13_20_escorts_aynasha_legoso.sql，备份 backup/escorts_aynasha_legoso_20261113.tsv）：

4.12 批次八：侏儒、黑海岸、狼人新手区

为了加快速度写了个检查工具 tools/qinspect.py：给一个任务编号，一次列出任务目标、计数 NPC 以及谁能给它计数、任务物品和它的整条法术链（含施法焦点和区域限制）、发任务/交任务 NPC 和它们的刷新/脚本状态。

这一批里，有原版机制可以接上的就接上；载具或整段剧情根本不存在的，按前面的做法跳过演出。

文件（各自都有 backup/*_20261113.tsv 备份）：sql-custom/2026_11_13_21_gnome_start_quests.sql、2026_11_13_22_down_with_crushcog.sql、2026_11_13_23_darkshore_quests.sql、2026_11_13_25_darkshore_part2.sql、2026_11_13_24_gilneas_quests.sql。重启后启动日志只有”另有计数法术但没人施放”的提示。

“跳过演出”的任务一览（到这里为止）：26322、26364、13885、24904、26706，以及 26228/26290/26320 这几个只保留了动作的。以后如果找到原版的台词和流程，这些都值得回头补。

4.13 批次九：1–19 级任务物品的人工清单

4.8 那批里留下的”靠别的方式获得”的物品，按联盟这边逐个接上（文件 sql-custom/2026_11_13_26_item_sources_1_19.sql，备份 backup/item_sources_1_19_20261113.tsv）。

钓鱼日常。 这些任务鱼在库里没有任何钓鱼掉落。核心钓鱼时先查小区域（subzone）的表，没有才退回大区（GameObject::getFishLoot），所以给每个钓点单独建一张小区域表：抄一份大区原有的普通鱼，再加上任务鱼（任务掉落，50%）。这样只有在那片水里才钓得到，别处不受影响。

点击拾取。 这几样东西都是”玩家先对目标用一个空标记法术，目标再把物品交给玩家”，但目标既不能点、也没有反应：

都只对接了任务、未完成的人生效。

13566 Ritual Materials（黑海岸）。 月夜猎手胡须和蓟熊毛皮只能从”Force …”法术（62512、64116，把物品直接交给目标）拿到，没人施放。改成：这几种动物被打死时，对凶手施放（凶手要接了任务）。

还剩的： 29353 Keepin’ the Haggis Flowin’ 的 Bag o’ Sheep Innards 在库里和客户端缓存里都查不到来源，暂时没修；暗月马戏团的两个任务和 29412 Blown Away（气球物体没有刷新点）只在活动期间出现，先放着。

4.14 批次十：20–29 级

掉落表（模式 A）。 这一段跑出来时发现规则要补一条：荆棘谷那本书的散页（Green Hills of Stranglethorn - Page 14）在客户端缓存里挂在荆棘谷一百四十多种怪身上，按”只要 1 件就给 100%“会变成任何怪都必掉。原版这类散页是全区随机低概率掉落，所以加了一条：一件物品挂在 8 种以上的怪身上，掉率统一给 10%。1–19 级那批里的 Elemental Goo（挂在 40 种怪上）也一并改回 10%。这一段还原了 32 件物品、205 条掉落，逐条核对过（sql-custom/2026_11_13_27_audit_pattern_a_loot_20_29.sql）。

名字对应的计数（模式 C2）。 只命中 1 个：28495 A Fighting Chance（奥特兰克山脉的小鹿，2026_11_13_28_audit_pattern_c2_20_29.sql）。

逐个修的：

文件：sql-custom/2026_11_13_29_dwarf_route_20_29.sql、2026_11_13_30_ashenvale_20_29.sql、2026_11_13_31_desolace_brazier.sql、2026_11_13_32_stonetalon_barrens_20_29.sql，各自都有 backup/*_20261113.tsv。

查 14213 时顺带确认了一件事：核心选法术目标时不检查”不可选中”标志（SpellInfo::CheckTarget 里没有），所以带这个标志的计数标记也能被打中。灭火任务那些标记就带这个标志，已经在游戏里确认能用。

没修的： 荆棘谷海角的祖尔格拉布系列（26550–26555），要进入祖尔格拉布的一段幻象，后几环的发任务人（Jeklik、Venoxis）都没刷，链条中间就断了，先跳过；灰谷 13982 In a Bind 要的 Kaliva 没有刷新点，原版位置不知道；凄凉之地 5943 Gizelton Caravan 的发任务人和交任务人都没刷，玩家接不到。另外这一段还有一批部落任务（奥特兰克山脉的”植物大战僵尸”小游戏等），矮人路线用不到，暂时没管。

4.15 批次十一：30–39 级（第一部分）

掉落表（模式 A）。 还原 41 件物品、58 条掉落，逐条核对过（sql-custom/2026_11_13_33_audit_pattern_a_loot_30_39.sql）。

同名换编号（模式 B，新规则）。 30–39 级里常见的一种情况：任务要杀的有名字的敌人，这个编号没有刷新点，但库里另有一个同名、刷着的编号（同一个 NPC 在不同版本里换过编号）。规则（tools/fix_pattern_b.py）：只看敌对、可攻击、还没设 KillCredit1 的同名编号，把它的 KillCredit1 设成任务目标，杀它就算数。全库只命中 11 个任务（覆盖各个等级），一次应用（sql-custom/2026_11_13_34_audit_pattern_b_killcredit_twins.sql）。

辛特兰（鹰巢山一线，sql-custom/2026_11_13_35_hinterlands_30_39.sql）：

还没修的： 27626 The Highvale Documents 的 3 个文件物体模板是空壳（类型 0，名字”unk name”），也不知道原版位置。30–39 级剩下的大多是整段剧情或载具战（东瘟疫之地血色十字军的一串头目、荆棘谷海角的 Brashtide 海盗船系列、千针石林、西瘟疫之地 Andorhal 的攻防战），而且要杀的敌人普遍没有刷新点、模板是占位数据，重建要大量猜位置。

4.16 批次十二：30–39 级（第二部分）

这一段剩下的大多是整段剧情或载具战，要杀的敌人没有刷新点、模板是占位数据（1 级、友好阵营）。我问了一下处理方式，定下来的是：全部逐个重建，位置、等级靠推测也要把玩法还原出来；只有内容已经被版本删掉的才禁用。

禁用旧版通灵学院的 3 个任务。 27140 Alexi’s Gambit、27142 The Lich, Ras Frostwhisper、27143 Barov Family Fortune：通灵学院在熊猫人版本里改版了，这些 Boss 和宝箱都不在了（sql-custom/2026_11_13_36_disable_old_scholomance.sql，热加载生效）。

刷新高度的教训。 这一批我先验证了地形高度工具：拿 Andorhal 防御者、Quel’Danil 守卫、卡拉诺斯 NPC 的实际刷新高度去对比，空地上都吻合（误差 0.5 码以内）；但 27171 那个任务物体周围的破武器箱都在 z 31，比地形低 30 码——那里在山体下面。所以以后在建筑里、洞里刷东西，一律用附近已有物体的高度，不用地形。

西瘟疫之地（sql-custom/2026_11_13_37_western_plaguelands_30_39.sql）：

26938 Combat Training 是部落任务，没有动。

4.17 实测反馈：Solanian’s Belongings（一次误判）

在游戏里随手抽查了血精灵新手村的 8330 Solanian’s Belongings：三件物品之一 Solanian’s Scrying Orb，地图标记的位置不对。

我先误判了。 我只看了数据：水晶球刷在 z 16.67，那里的地形（池底）是 5.1，地图文件里的水面是 11.77，于是认定它悬在水面上方 5 码，把它连同头上的黄色光柱挪到了 12.3。结果到了现场——让服务器 saveall 后读出实时位置——角色就站在水晶球旁边、高度 16.2：池塘中间有一块岩石平台，是模型，地形数据里看不到。原来的高度是对的，我反而把水晶球埋进了平台里，只剩光柱。已经恢复原位（sql-custom/2026_11_13_38_solanian_scrying_orb.sql 现在就是这次恢复）。

教训： 只凭地形和水面数据，判断不了物体脚下有没有东西（建筑、岩石、巨型蘑菇、船都是模型）。我顺手写的高度扫描（tools/go_height_audit.py）也因为这个原因误报太多，不可用。以后挪物体之前，要么请玩家报实地位置，要么用服务端的碰撞数据（vmap）。

地图标记的真正原因： 这个任务 quest_poi 里三件物品的 objIndex 是 4、5、6，这是旧版的编号（0–3 是要杀/互动的目标槽，4–9 是物品槽），而熊猫人客户端认的是 quest_objective.index（这里是 0、1、2）；服务端原样发出（QueryHandler.cpp:617），客户端就对错了标记。全库有 3289 个任务是这种情况，换算脚本已经写好，还没执行。

另一个怪现象： 东西都拿齐后交不了任务。服务器记录里”日记”那一条进度不见了（背包里有日记）。核心登录时只在内存里按背包重数物品（AdjustQuestReqItemCount），不更新任务日志上的计数，也不重新判断任务是否完成，所以一直卡在”未完成”。扔掉日记再捡一次就好了。这条进度是怎么丢的还没查清楚，期间我在玩家在线时重启过两次，暂时先放着。

4.18 批次十三：地图标记编号全局换算

接着 4.17 的发现做了全局换算（tools/fix_poi_index.py，sql-custom/2026_11_13_39_quest_poi_objindex_remap.sql，原值备份在 backup/quest_poi_objindex_20261113.tsv）。

先空跑，再验证。 一开始的规则是”旧版第 k 个物品槽 → 新表里第 k 个物品目标”。用实际位置验证（地图标记的区域离哪个目标的真实位置最近：怪的刷新点、掉这个物品的怪、宝箱）时，揪出了问题：转换后的任务目标是按物品/生物编号从小到大排的，不是旧版的槽位顺序。比如 101 The Totem of Infliction，说明里是”食尸鬼尖牙、骷髅手指、蜘蛛毒液”，新表却是尖牙（1129）、毒液（1130）、手指（2378）。Solanian 那个任务恰好编号顺序和原顺序一致，所以看不出来。

最后的判断顺序：

1. 同类目标只有一个，直接对应（1999 组）；
2. 任务说明（Objectives）里能找到所有同类目标的名字（允许复数和 “Chunks of” 这类变形），按出现的先后对应旧槽位（380 组）——说明的顺序基本就是旧版的槽位顺序；
3. 说明里找不全，才按地理：在所有一一对应方式里，选标记区域到真实目标总距离最小的那种（64 组）。

说明顺序和地理判断在 84% 的槽位上一致；不一致的多在怪物混居的区域（比如丹莫罗到处都有野猪和熊，317 Stocking Jetsteam 用地理就会配反），那种情况下说明顺序更可靠。

结果： 3289 个对不上的任务里，2225 个、3993 条标记换算好了；924 个没动：650 个根本没有任务目标（多是废弃的旧任务），其余用的是 10、16 这类含义不明的编号。reload quest_poi 热加载，不用重启；客户端可能要重新登录才会重新请求标记。

4.19 碰撞数据检查工具

Solanian 那次误判以后，补了一个能看到”模型”的位置检查工具。

vmapcheck（tools/vmapcheck/）。 一个独立的小程序，直接复用服务端自己的碰撞代码：只编译 VMapManager2、MapTree、ModelInstance、WorldModel、BoundingIntervalHierarchy 和 G3D 数学库；服务端其他部分用 4 个几行的替身头文件代替（日志、断言、DisableMgr 永远”不禁用”、液体类型），TileAssembler.cpp 里的 readChunk 照抄一份。单独的 Dockerfile 第一步和主 Dockerfile 完全相同，直接复用缓存的编译环境，一分钟编完，镜像 119 MB。输入”地图 x y z”，输出这一点脚下最近的碰撞面、头顶的碰撞面，以及一条短视线是否被挡。

先用已知的点验证：

poscheck（tools/poscheck.py）。 把三样东西合起来判断：地形高度、水面高度（都从 .map 文件读，注意 −500 表示”没有水”）、碰撞面。离最近的支撑面（不在头顶上的最高的那个）超过 2.5 码算悬空，低于地形或被模型压着、附近又没有可站的面算被埋；会飞的生物和水里的生物不算悬空。

用它复查我们自己刷的 73 个 NPC 和物体，查出 3 处错误：

• 26228 Jangolode 矿洞的施法点在两条矿道之间的岩体里（脚下没有碰撞面，地形在头顶 80 码）。原来是按狗头人的平均位置算的点。改放到最深处那只狗头人挖掘者的位置——工具显示所有狗头人都正好踩在矿道地面上，头顶 7–8 码是矿道顶；
• 26532 Shadra 悬空 3 码：我照抄的祭坛标记本身就比神庙地面高 3 码，降到 113.8；
• 27171 的 8 个骷髅里有 5 个在山体里：在破武器箱周围按 2 码网格采样，找到洞底那片平地（x 1046–1074，y −1912 到 −1898，高 30.7–31.1），8 个都挪进去。

修正后复查，73 个全部通过（sql-custom/2026_11_13_40_poscheck_fixes.sql）。以后每次刷新东西之前都先过一遍这个工具。

4.20 怪物掉落太多：掉落表全库整理（实测抽检）

熊猫人新手岛打几只小怪就把背包捡满了。掉落倍率配置全是 1，问题在掉落表本身：很多怪的掉落行全部放在”不分组”（groupid 0）里，每一行都独立判定。以 Plump Virmen 为例：药水、泉水、苹果、亚麻布、孔雀石各 100%，30 多件灰色武器护甲各 35–58%，概率加起来 1835%，平均每只掉十几件。全库有 1397 张这样的表（不分组的概率加起来超过 150%）。

修法（tools/fix_loot_overflow.py，sql-custom/2026_11_13_41_creature_loot_overflow.sql）：

• 范围：只改刷在野外地图、不刷在任何副本里、不是 Boss 的怪用的表，一共 469 张。副本、Boss，以及没有刷新点的表都不动；
• 灰色物品和白色武器护甲并成一组，每只最多掉一件，总概率 = min(原合计, 100%) × 50%；
• 其他普通物品（药水、食物、布、矿石、绿色物品）另成一组，每只最多掉一件，单行先封顶 50%，总概率 = min(原合计, 100%) × 40%；
• 蓝色/紫色物品一般不动。只有一种情况例外：这些物品本身合计就超过 100%，这时并成一组，总概率 10%。永恒岛上的怪就是这样，每件永恒套装部件都是 100%；
• 任务物品、引用表、金币都不动；组内各物品之间的相对比例保持原样。

结果：这 469 张表平均每只怪的期望掉落从 6.6 件降到 0.67 件（不算任务物品和金币），最高的一张约 1.45 件。原数据整表备份在 backup/creature_loot_overflow_20261113.tsv。掉落表支持热加载（reload creature_loot_template），不用重启。

4.21 接下来

30–39 级段继续逐个重建：东瘟疫之地、荆棘谷海角、千针石林、南贫瘠之地、菲拉斯、尘泥沼泽、凄凉之地，以及辛特兰的 27626。

还没解决的问题

• 重建会丢修复。 数据库修复都在 sql-custom/，重新导入世界库后必须按顺序重跑一遍。源码改动只在工作区和 patches/ 里，git pull 之前要先想好怎么合并。
• 多人同时做同一个任务从没测过。 每个修复都只用一个角色验证过，像 29799 这种全场共用的事件，中途加入或者几个人进度不同步，都还是未知数。
• 其他种族已知做不了的任务： 地精的 14113、14153 Life of the Party（派对客人一个刷新点都没有），14110 The New You（物品没有任何来源）。这些暂时搁置。
• 攒着等下一批编译的小 bug： 放弃 29423 后，Huo 还会一直跟着玩家，重新登录可以解决。
• 全局审计剩下的问题。 联盟这边还有约 1000 个任务需要重建内容（第四章），按等级段从低到高逐批修。
• 11 月 9 日那次崩溃还没有结论。 后来抓到的两个 core 都是关机时的另一个 bug（见 1.8 节，已修复）。GetQuestStatus 那次一直没有再出现，还在等它的 core。

熊猫人岛和矮人这两条新手线目前都能完整做完。接下来继续往后玩，遇到问题再接着修，这篇文章也会跟着更新。