⭐ 12💚 赞助 · Sponsor

Deer and Cauldron World (Xi'an Station)

✅ 可玩

鹿鼎天下（游戏内实际品牌：雄霸天下『西安站』）

ldtx

🔑 fluffos / Mud@2026 更新 daa63e1 2026-09-01 源码 下载 ZIP

▶ 开始游玩 · Play Now

info.html · 介绍 · play.html · 游玩 · llms.txt · 下载与本地运行 · ZIP · GitHub

"世纪(Century)/adm-single" 引擎家族的一支（与本项目的 `shiji`、`shujian2008`、`xjcq2000`、`xkxz2`、`xiakexing100` 同源），远祖为 ES II，是一部金庸武侠跨小说世界观的门派养成类泥巴。新角色从客栈开局，固定 NPC 韦小宝（《鹿鼎记》主角）与一位插科打诨的店小二、一只小白狗一同迎接玩家，游戏还明确提醒玩家不要选用金庸小说里已有人物的姓名。除膂力/悟性/根骨/身法四项基础属性外，另有隐藏的福缘/容貌属性影响解谜与拜师判定；拜师对话里会提到风清扬（《笑傲江湖》），可达的远方地区还包括大理、雪山寺庙，以及由韦一笑、成昆等头领坐镇的明教总坛——是一个真正横跨多部金庸小说的江湖世界，而非单一原著的换皮之作。死亡机制是原地击倒＋属性惩罚后自动苏醒，不走分阶段的鬼魂/冥界流程。档案压缩包本身叫"鹿鼎天下"，但登入画面品牌其实是"雄霸天下『西安站』"，`quit` 退出提示又写着"离开了鹿鼎天下"——品牌换了一半没换干净；这个"雄霸天下"品牌名同时也被本项目另一份完全不相关的代码库 `xbtxiii` 独立使用，逐行核对确认两者只共享更早的 ES II 共同祖先，并非直接血统关系。

English

A Jin Yong wuxia crossover mudlib in the "Century (Shiji) / adm-single" engine family (sharing lineage with this project's shiji, shujian2008, xjcq2000, xkxz2, and xiakexing100), itself descended from ES II. New characters land in an opening inn where a fixed NPC named Wei Xiaobao (the hero of The Deer and the Cauldron) greets arrivals alongside a bantering shopkeeper and a small white dog, and the game explicitly asks players NOT to name their own character after an existing Jin Yong novel figure. Beyond the four core attributes (strength, aptitude, bone-structure, agility) there are hidden fate/appearance stats that gate puzzles and master-apprentice acceptance; apprenticeship dialogue name-checks Feng Qingyang (of Laughing Proud Wanderer), and distant regions reachable from the city include Dali, a Snow Mountain temple, and a Ming Cult mountain gate with named leadership NPCs (Wei Yixiao, Cheng Chaofeng) -- a genuine multi-novel Jin Yong crossover world, not a single-book reskin. Death knocks a character out in place with a stat penalty rather than sending them through a staged ghost/underworld sequence. The archive itself is named "Deer and Cauldron World," but the login banner brands the game "Xiongba Tianxia (Hero's Dominion), Xi'an Station" and the quit message still says "you have left Deer and Cauldron World" -- an incomplete historical rebrand. That same "Xiongba Tianxia" brand name is also used, independently, by this collection's unrelated xbtxiii codebase; a line-by-line check confirmed they only share a distant ES II ancestor, not a direct lineage.

README

内容亮点

血统澄清：游戏内品牌"雄霸天下"同时也是另一份完全不同代码库 xbtxiii（雄霸天下III）的品牌名，但逐行核对 master.lpc/ securityd.lpc/config.fluffos 后确认两者不是同一份代码—— ldtx 的 master file 指向 /adm/single/master（档头明确写着 "for ES II mudlib... modified by Xiang for XKX"，securd.lpc+ securityd.lpc 两文件分工），xbtxiii 指向 /adm/obj/master（无 该血统注释，securityd.lpc 是单一文件）。两者 connect() 函式体 确实一字不差相同，说明共享更早的"东方故事 ES II"共同祖先（AGENTS.md §11），但各自独立演化，不属于同一具体分支——"雄霸天下"是被至少两 个互不相关的分支各自沿用的品牌名，与本项目已反复验证的"共享品牌 名≠共享血统"规律（§5.1）再添一例。ldtx 真正的血统伙伴是下面已 记录的 Century/adm-single 家族。详见 NOTES.md 深度功能测试小节。

注册流程

选择编码 GB 或 BIG5（本地/浏览器测试用 gb）→ 按 Enter 跳过跨服 Mud 列表 → 英文名字（3-8 个小写英文字母）→ 确认建立新角色（y/n） → 中文名字 → 密码（至少 5 位）→ 确认密码 → 天赋分配（输入 0-4，0 代表全部交给系统随机产生，1-4 代表自己指定该项数值再随机其余项； 一般直接用 0）→ 是否接受这组天赋（y/n）→ 电子邮件地址 → 性别 （m/f）→ 进入游戏世界。

本次 WASM 验证修复的关键 bug

没有发现 Chinese 姓名判断、宏定义或指令表相关的 bug。

另外发现一个内容缺失（d/city/npc/xiaobao.lpc 的 create() 引用 了不存在的 /u/rhxlwd/cloth.lpc）——WASM 阶段曾误判为"被房间自己 的 catch() 接住、无害"，后续 §10.7 深度功能测试追查发现并不是 这样：这个未捕获的例外实际会打断开局客店房间 create() 里紧接 在后面的留言板加载语句，导致这份档案的开局留言板每次开机都不会出 现。已用标准防御性守卫修复（不补内容，只挡例外），详见 NOTES.md 和 AGENTS.md §7.73。

移植修复（详见 NOTES.md）

姊妹档案 ldtxii 深度测试时在 logind.lpc 发现两个 bug，逐行核 对后确认这份档案在完全相同的行号有一字不差的同一段代码——已移植 过来：调试残留 printf("%O\n", ob)（AGENTS.md §7.34）和食物/饮水 满值初始化误读 ob->query("age")（应为 user->query("age")， AGENTS.md §8.9）。两处均已修复并用新角色验证。

在线试玩

https://mudlibs.fluffos.info/ludingtianxia/

管理员账号 / Admin account

警告：对外公开架设前请务必修改此密码。

本地运行

cd libs/ldtx
~/src/fluffos/build-debug/src/driver config.fluffos

游戏端口：40105。

NOTES · 移植与修复记录

鹿鼎天下.rar → ludingtianxia

Status: DONE — boots clean, full registration with a real Chinese name verified, playable

What was fixed

1. Systemic encoding artifact, not caught by convert_lib.sh's normal GB18030→UTF-8 pass: nearly the entire tree (3903 of ~5960 .lpc/.h files) shipped with doubled \r\r\n line endings (CRCRLF, doubled — worse than the single-CRCRLF quirk convert_lib.sh's own comments already document). This silently broke every subsequent string-literal edit (exact-match tooling can't find \r-embedded lines). Fixed with a blanket sed -i 's/\r//g' across every .lpc/.h file before doing any further hand-edits. 2. §7.1 class, simpler variant: adm/single/master.lpc's valid_read/valid_write did if (ob = find_object(SECURITY_D)) ... return 0; — no lazy load_object() attempt at all, just permanent deny until securityd happens to already be loaded. Real driver boot preloads securityd first so this never bit in practice, but it made lpcc_check.sh's single-VM compile sweep (which doesn't preload) deny-everything (2/5960 pass). Added the standard re-entrancy-guarded load_object(SECURITY_D) fallback from AGENTS.md §7.1 to both functions — jumped to 5793/5960 passing. 3. §8.1 class: adm/simul_efun/chinese.lpc's is_chinese() (GBK byte-range test) and adm/daemons/logind.lpc's check_legal_name() (byte-oriented length bound 2-10 + i%2==0 sliding window) — same fix pattern as every other lib in this catalog entry. Verified: real Chinese name 秦风六 registers correctly end-to-end. 4. /adm/daemons/network/dns_master and /adm/daemons/ftpd were actively preloaded (not already commented out, unlike most other libs in this collection) — commented out per the standing no-sockets- package policy (§1.3c). Confirmed harmless at runtime: login flow prints "网路精灵并没有被载入" (network daemon not loaded) and continues normally. 5. Admin seeding (§1.5): registered fluffos through the normal flow, appended fluffos (admin) to adm/etc/wizlist (same mechanism as the Century family generally — / is in securityd.lpc's trusted_write for (admin)). Verified: recompiling /adm/single/ master via update succeeds as fluffos (shows the driver's variable-clear side effect, no ACL denial).

Known issues, NOT fixed (logged, matching the "content bugs" bar)

167 of 5960 files fail lpcc_check.sh's compile sweep, none of them core-system files (master/simul_efun/logind/securityd/chinesed all compile and run correctly). Three observed failure shapes, all isolated to individual content files:

None of these affect the core registration/look/score/quit loop verified above; logging here rather than auditing all 167 individually.

Not yet done (out of scope for this pass)

WASM export / GitHub Pages packaging — deferred to a later batch pass.

移植修复（2026-08-03，来自姊妹档案 ldtxii 的深度测试）

ldtxii 深度功能测试（§10.7）在其 logind.lpc 里发现两个 bug， 逐行核对后确认 ldtx 这份档案在完全相同的行号上有一字不差的同一 段代码——是共享血统里从未修过的祖传问题，不是 ldtxii 自己引入 的。按 AGENTS.md §2.1 的"跨手足档案移植已验证修复"惯例，直接把两 个修复移植了过来：

1. get_name() 里紧跟在中文名字设定之前的调试残留 printf("%O\n", ob)（AGENTS.md §7.34）——删除。 2. 食物/饮水满值初始化误读 ob->query("age") 而不是 user->query("age")（AGENTS.md §8.9）——已改正。

用一个全新角色（ldtxdive）验证：注册流程无调试残留输出， score显示食物/饮水槽创建时即为满值（16/16格），look/score/ quit均正常。重启后 debug.log 里出现的两条报错都是本档案早就记录 过的既有内容缺口（xiaobao.lpc 引用不存在的 /u/rhxlwd/cloth.lpc 的老问题，以及和 ldtxii一样的 chatroom.lpc//u/mouse/ 缺口）， 不是这次改动引入的新问题。未做完整的第二轮深度功能测试（本次是移 植已验证的修复，不是从头深挖这个档案）。

WASM 修复摘要（迁移自 meta.json 的 group_note）

Century/adm-single 家族（shiji/shujian2008/xjcq2000/xkxz2/xiakexing100），游戏内标题为"雄霸天下『西安站』"。WASM 修复：把 adm/daemons/network/dns_master.lpc 的 startup_udp()/send_udp()/send_shutdown() 里那行 socket_close() 掏空（§7.52 socket 精灵掏空）——这个 WASM 构建下 socket_create()/socket_bind() 是未定义的 efun，导致编译失败，进而破坏了每一个中途呼叫进这个档案的 call_other()，包括每次连线在英文名字提示之前就会跑的 encoding_to_mudlist() 步骤。没有中文名字/宏定义/指令表相关的 bug（is_chinese() 本来就是正确的码点判断）。管理员账号"fluffos"/"Mud@2026"其实早在这份档案更早、WASM 之前的一轮里就已经播种进 adm/etc/wizlist 了（这份档案的 README 里已经提到过一个真实上线过的部署）——已验证既有凭据依然能登录并正确显示 (admin)，不需要新账号（一开始误以为这是 §1.5 那种引导 id 冲突的模式，多加了一个多余的并行账号"fladmin"，后来发现这份档案自己既有的 README 早就记录过可用的 fluffos 凭据，已撤销这个多余的添加）。留下一处真实存在、不阻断的内容缺口未修：d/city/npc/xiaobao.lpc 的 create() 引用了一个不存在的 /u/rhxlwd/cloth.lpc（这个巫师目录在整个档案里根本不存在）——对结果为 0 的物件做 call_other() 会抛出"Bad argument 1 to EFUN call_other()"，但被房间自己的 setup()/reset() 包装函式捕获了，从未传到玩家那里；按"不凭空捏造内容"的先例保持原样（和 ffxymud/jhfy2/jhfy3 的 d/city/sj.lpc 是同一类情况）。完整的注册（选 gb 编码→id→确认→中文名字→密码→确认→天赋选'0'→接受'y'→电子邮件→性别）和 look→score→quit 流程在排版格式化前后都验证过；格式化工具没有引入任何损坏（三类盲点检查都干净）。

§7.86 跨库扫描修复（留言板 post 崩溃）

深度功能测试（§10.7，2026-08-08）

之前的 WASM 阶段和 §7.86 扫描都只做过编译检查/浅层注册测试，没有真正玩过。这次用原生驱动（build-debug/src/driver）通过 scripts/tmux_mud.sh 完整走了一遍。

与 xbtxiii 的血统关系：确认为"同源但非同支"，不是同一份代码

本次深挖前先核对了 xbtxiii（雄霸天下III）——两者游戏内品牌都叫"雄霸天下"，但直接比对 master.lpc/securityd.lpc/config.fluffos 的结构后确认不是同一份代码：

结论："雄霸天下"是被至少两个互不相关的具体分支各自沿用的品牌名，不是同一血统的确凿证据——与本项目反复验证过的"共享品牌名≠共享血统"规律（AGENTS.md §5.1）再添一例。ldtx 真正的血统伙伴是 README/NOTES.md 已经记录的 Century/adm-single 家族（shiji/shujian2008/xjcq2000/xkxz2/xiakexing100）。

xbtxiii 姊妹发现逐项核对（均不适用——不同代码库）

本次新发现并已修复的 bug

完整游玩验证（一次连续会话，原生驱动）

用全新角色 ldtxqa（中文名"云飞扬"）走完整套注册流程：gb 编码 → 英文 id → 确认 y → 中文名字（无 §7.34 调试残留输出）→ 密码 → 确认密码 → 天赋 0（系统随机）→ 接受 y → 电子邮件 → 性别 m → 进入游戏世界（客店），过程干净无报错。

全程 debug.log 无任何异常记录（唯一出现过的执行时段错误就是本次修复的 §7.11 nosave 问题本身，修复前后各测了一遍）。

未覆盖

商店/购买、正式门派拜师、邮件系统本轮时间有限未继续深挖；本档案的开局区域是围绕客店/北大街/中央广场展开的城市地图，未继续往更远的地图区域探索。

§7.100 sweep (2026-08-19): redundant replace_program(ROOM); landmine

Same corpus-wide bug as documented at AGENTS.md §7.100: rooms inheriting ROOM (/inherit/room/room) had a redundant, harmful replace_program(ROOM); call right after inherit ROOM; in create(), setting a permanent "pending replace" flag that crashes the object the first time anything binds a closure to it. This lib had 1,516 live occurrences (survey-ranked #87 of 166 candidates >=100, tied with and sharing a lineage with ldtxii). Fixed with the sweep's binary-mode script (fix_710_room.py); git diff --numstat totals (0 insertions, 1516 deletions) match the survey's live-occurrence count exactly. This lib's clone/misc/roommaker.lpc room-building tool never had the factory-bug variant at all — its generated-room code templates (both the mkroom-style heredoc and the str += string-builder path) never included a replace_program(ROOM) call to begin with. No work/data/ room-source false-negative found. Verified via a clean build-debug boot (zero "cannot replace"/"cannot bind" debug.log lines, port 40105 listening) plus a live admin login (fluffos/Mud@2026, GB encoding selection, Press Enter to Continue banner) — entered the game world normally, look/quit both worked, debug.log stayed clean throughout. Incidental admin save-timestamp drift from the spot-check reverted before committing (pre-existing untracked ldtxdive.o/ldtxqa.o/data/board/ save files left untouched, not part of this change).

``§7.112`` residual-gap closure (2026-08-20)

Corpus re-scan (grep -rl 'call_out("death_stage"' ... | filter for missing guard) found unguarded init()-scheduled death_stage() call_out chain(s) in d/death/wgargoyle.lpc that the original two-wave sweep (see AGENTS.md §7.112) missed -- same reconnect-triggered duplicate-chain bug, different filename/lineage. Added the standard query_temp("death_stage_active")/set_temp/delete_temp re-entry guard, adapted per file's own exit points. Compile-verified via lpcc --batch.

§7.30 uninitialized-mapping accessor sweep (2026-08-20)

Corpus-wide mechanical sweep of the feature/skill.lpc shared-lineage bug (confirmed independently on xiakexing2017/jqxz2015/haiyang2 via round-four testing): 4 accessor(s) in this file returned a raw never-initialized mapping instance variable (defaults to int 0, not ([]), until first assigned), crashing any unguarded keys()/sizeof()/indexing caller for a fresh/untrained character. Fixed at the accessor level (mapp(x) ? x : ([])) per the documented remedy. Verified via lpcc --batch static compile check only (not a live boot) as part of a large mechanical sweep; not individually functionally re-tested live on this lib.

深度功能测试（§10.7，2026-08-21）：商店购买 + 门派拜师首次实测

之前几轮测试（§7.86 扫描、2026-08-08 那轮深度测试、§7.100/§7.112/§7.30 扫描）都验证过注册/移动/留言板/战斗死亡复活/quit重连，但商店购买和 正式拜师流程一直没有真正跑过（2026-08-08 那轮 NOTES 里"未覆盖"一节明 确记录了这一点）。这次原生驱动（build-debug/src/driver）+ 两个并行 telnet 会话（一个测试角色、既有 fluffos(admin) 账号）补上这两项，并 用真实 kill 指令对"中央广场"的"流氓头"重新走了一遍战斗/死亡/复活流 程（与 2026-08-08 那轮结果一致，无回归）。

1. 战斗与死亡复活：复测无回归

新角色 ldtxwyf（中文名"石中玉"）对"流氓头"使用真实 kill 指令（非 切磋指令），多回合真实攻防判定后被打倒昏迷，look/score 短暂返回 "什麽？"（指令封锁），随后自动苏醒，score 显示"你共死亡：1 次"、 "最后一次死于：[流氓头] 之手"，精/气从满格降到 2/16。全程 debug.log 无异常。

2. 商店购买：首次实测，通过

用 admin clone /clone/money/gold + give gold to <角色> 的标准套路 给测试角色注资（一两黄金＝10000 铜板），在开局房间"客店"内向既有的 d/city/npc/xiaoer.lpc（店小二，inherit F_VENDOR＝/feature/dealer.lpc） 执行 buy huo，成功买下"火把"（五两白银＝500），扣款后找零"九十五两 白银"（10000-500=9500，换算白银单位正确），物品正确出现在角色物品栏。 debug.log 全程无异常。

3. 门派拜师：首次实测，发现并修复一个真实的执行时段崩溃（新增 6 个文件）

用 admin goto+summon 把测试角色传送到少林寺广场（d/shaolin/guangchang1w）， 对"清为比丘"（kungfu/class/shaolin/qing-wei.lpc）执行 bai qingwei， debug.log 立即记录一条真实的执行时段崩溃：

执行时段错误：*Value being indexed is zero.
程式：/kungfu/class/shaolin/qing-wei.lpc 第 74 行
呼叫来自：/cmds/skill/bai.lpc 的 main() 第 106 行
呼叫来自：/kungfu/class/shaolin/qing-wei.lpc 的 attempt_apprentice() 第 74 行

根因：attempt_apprentice(object ob) 里 mapping ob_fam = ob->query("family"); 对一个从未拜过师的新角色而言，query("family") 返回的是裸 int 0 （不是 mapp() 检查过的空 ([])），随后 if (ob_fam["family_name"] == "少 林派" && ...) 不经任何 mapp() 守卫直接对这个 int 0 做下标索引， 触发驱动级"Value being indexed is zero"。这意味着任何全新角色第一次 在这个 NPC 面前 bai，一定崩溃——门派拜师这个核心玩法在这份档案里 从代码提交以来大概率从未在这个 NPC 身上真正跑通过。

同一份坏代码的姊妹实例：全档案 grep所有 attempt_apprentice() 里出现 ob_fam[ 下标的 24 个文件，绝大多数（少林/明教/峨嵋各支）已经 用 if (!(ob_fam = ob->query("family")) || ob_fam["family_name"] != "...") 这种"赋值同时判空、||短路"的写法正确守卫；但另外 6 个文件是同一处 逻辑的裸下标变体，同样会在全新角色面前崩溃：

修复：统一在下标之前补一个 mapp(ob_fam) && 短路守卫，与本档案其余 安全写法保持同一防御性风格，不改变原有的"同门派、辈分不够"拒绝逻辑。 现场重新用另一个全新角色（xiaolong/"小龙女"）对丘处机执行 bai qiu 验证：不再崩溃，正确走到下一条资质检查（"六根清静...资质似乎不适合 当道士"，因为膂力/根骨未达 30 的门槛，这是既有的、正常的游戏内拒绝 逻辑，不是 bug）。用 ldtxwyf 对清为比丘重新 bai qingwei 验证：正 常完成拜师，score/goto 均显示"少林派第四十一代弟子"称谓，无崩溃。

顺手修复同一个 bai.lpc 里紧邻的另一处已确认会崩溃的括号写反 bug： bai.lpc 第 56 行原文 me->query("family/master_id" == "feng qingyang") ——括号位置写反，实际变成对 query() 传入一个恒为 0 的布尔比较结果 （me->query(0)），而不是比较查询结果字符串。这条分支只有当"师父一 方先用 recruit 指令主动收徒、徒弟后用 bai 补礼"这个顺序（而不是 本档案 203 处 attempt_apprentice() 里全部采用的"徒弟先 bai，NPC 自动 attempt_apprentice→recruit"顺序）时才会走到；用 qiangpo <师 父NPC> to recruit <全新角色> 强制模拟这个顺序，配合静态追踪 /feature/dbase.lpc 的 query(string prop, int raw) 实现（prop 为 int 0 时 strsrch(prop, '/') 必然抛"Bad argument 1"）确认这条 分支一旦触发必定崩溃，但由于该分支要求一个真人巫师/门派掌门角色主 动使用 recruit 指令，两次现场复现都因为测试脚本自身的时序问题 （角色状态残留、新角色未过 15 分钟存档保护期）没能触发到这一具体路 径本身。鉴于这是与已确认崩溃同一函数、同一提交范围内、语义上明显写 反的逻辑错误（不是内容缺失），且修复风险极低，一并改成 ob->query("id") == "feng qingyang" || ob->query("name") == "风清扬" （ob 才是即将成为新师父的一方，语义上也更正确）。这份档案里没有任 何 NPC 叫"风清扬"/"feng qingyang"，所以这条分支本身的实际效果依旧是 空操作，此次修复只消除潜在崩溃，不改变游戏内容。

4. 顺手发现并修复的第三个真实崩溃：d/city/npc/dog.lpc（小白狗）问候函式参数不匹配

在多次测试过程中 debug.log 反复出现：

执行时段错误：*Bad argument 1 to EFUN call_other()
Expected: object, string, array,  Got: int(0).
程式：/d/city/npc/dog.lpc 第 58 行
呼叫来自：/d/city/npc/dog.lpc 的 greeting() 第 58 行

init() 用 call_out("greeting", 1, ob) 只传了一个参数（进入客店的 玩家），但 greeting(object who, object ob) 的函式签名要两个参数， 第二个 ob 因此永远是没绑定的 int 0。当 who->query("gender") == "女性"（即女性角色进客店）时，紧接着 if (ob->query("per") > 25) 对这个 int 0 做 call_other()，必然崩溃——任何女性角色第一次进 入开局房间"客店"，小白狗的问候 call_out 都会崩溃。用女性角色 gongsun（"公孙绿萼"）现场复现确认。修复：补 objectp(ob) && 守卫。 因为 call_out 本身的参数缺口没有配套的"礼物物件"创建逻辑（很可能 是原作者裁剪掉的半成品功能，不是这次改动引入的），修复后女性角色进 客店时这条"亲热"分支会被安全跳过而不是崩溃，符合"不凭空捏造缺失内 容，只消除崩溃"的既定尺度；用另一个女性角色重新验证：干净无报错。

标准巡检结果

未覆盖

邮件系统、其余城市外的更远地图区域（大理/雪山/明教/桃花岛等支线内容） 本轮仍未深入探索；商店/拜师验证仅覆盖各一个代表性 NPC（店小二、清为 比丘/丘处机），未逐一走遍全档案数十个门派/商人 NPC。

深度功能测试（§10.7，2026-08-24）：邮件系统 + 大理/雪山/明教/桃花岛地图补测

这次补上上一轮明确标记的两项未覆盖内容：玩家间邮件系统、开局城市以外 的四个支线地图区域。原生驱动（build-debug/src/driver）+ 全新 Python socket 脚本（scripts/mudclient.py，规避 tmux 多字节传输失真的已知 误报模式）实测。

1. cmds/skill/apprentice.lpc 的 §7.117 姊妹文件缺口（真实崩溃，已修复）

先按任务清单顺手复查 bai/apprentice 拜师指令族：cmds/skill/ bai.lpc 的 §7.117 类"背叛师门"判断已在 2026-08-21 那轮修好（ob-> query("family") 前有 mapp() 守卫），cmds/skill/apprentice.lpc 是同目录下几乎逐字重复的姊妹文件（同一段 main()），但第 56 行仍是 未修的原始写法：

if (((string)me->query("family/master_id" == "feng qingyang")) || ((string)me->query("family/master_name" == "风清扬"))) {

括号写反（me->query("family/master_id" == ...)，实际是对 query() 传入一个恒为 0/1 的布尔比较结果），与 2026-08-21 那轮在 bai.lpc 里 发现并修复的同一个 bug 一字不差，只是那一轮的修复没有同步应用到这个 姊妹文件——与 AGENTS.md §7.117 记录的 sjshv150 "姊妹文件漏改"缺口是 同一类问题。按同样写法修复：

if (((string)ob->query("id") == "feng qingyang") || ((string)ob->query("name") == "风清扬")) {

lpcc_check.sh 编译确认 /cmds/skill/apprentice 通过（本档案 5960 个文件里既有的 148 个失败与本次改动无关，改动前后失败总数不变）。

2. 邮件系统：首次实测，功能完整，未发现 bug

clone/misc/mailbox.lpc（信箱道具，mail/forward/from/ readmail/discard 五个指令）在 adm/daemons/logind.lpc 第 731-732 行每次登入都会自动 new() 一份塞进玩家物品栏（含离线玩家的"有你的 信哟"到站提醒、new_mail 标记），是真实可达的核心功能，不是需要 NPC 额外授予的隐藏内容。

用两个全新角色实测端到端流程：ldtxmt（田伯光，在线）对离线的 ldtxml（岳灵珊）执行 mail ldtxml，标题"问候一下"，正文通过内建 行编辑器（~q/./~e 语义与留言板编辑器一致）输入后选择不留副本， 返回"Ok."确认发送成功（send_mail() 内部用 FINGER_D-> acquire_login_ob() 找到收件人的登入档，因为对方离线所以走 new (MAILBOX_OB) 建立信箱、写信、destruct() 释放这条路径）。之后用 ldtxml 重新登入，from 正确显示 1 封未读信件（寄信人"田伯光 (ldtxmt)"），readmail 1 正确显示标题、寄信人、正文全文，编码无损、 无乱码（用裸 socket 脚本交叉验证过，排除 tmux 多字节传输失真的已知 误报模式）。全程 debug.log 无任何异常。未逐一测试 forward/ discard，但 receive_mail()/send_mail()/do_read() 这条端到端 主路径干净可用，判定为功能完整、无需修复的既有内容。

3. 远地图区域：大理/雪山/明教/桃花岛，发现并修复一个真实的、几乎

必现的执行时段崩溃

用既有 fluffos(admin) 账号 goto 四个区域各自的入口房间（/d/dali/ yamen衙门、/d/xueshan/shanmen雪山寺山门、/d/mingjiao/shanmen明 教山门、/d/taohua/damen桃花山庄正门），逐一 look 并各走一两步验 证出口，四个区域均正常加载、出口指向正确、无断链。

但在明教山门 east 走进下一个房间时，debug.log 立即记录两条真实 崩溃：

执行时段错误：*Value being indexed is zero.
程式：/kungfu/class/mingjiao/weiyixiao.lpc 第 6 行
呼叫来自：/kungfu/class/mingjiao/weiyixiao.lpc 的 greeting() 第 6 行

执行时段错误：*Value being indexed is zero.
程式：/d/mingjiao/npc/chengchaofeng.lpc 第 6 行
呼叫来自：/d/mingjiao/npc/chengchaofeng.lpc 的 greeting() 第 6 行

根因：明教各级 NPC（法王级用 fawang.h，坛主/香主级用 tanzhu.h /tangzhu.h/zhangqishi.h/menzhu.h 等）都在文件末尾 #include "mingjiao.h"，这个共享头文件定义的 greeting(object me, object ob) 在玩家走近时由 call_out 触发，里面直接对 ob->query("party") 的返 回值做下标：

if ( ob->query("party")["party_name"] == HIG "明教" NOR )

任何从未加入过帮会/门派"party"的角色，query("party") 返回裸 int 0（不是空 ([])），对 int 0 做 ["party_name"] 下标必然触发驱动 级"Value being indexed is zero"——这意味着任何普通新角色第一次走 近任意一个明教 NPC 都会触发这个崩溃（本档案的门派"party"系统与 "family"拜师是两套独立的属性，绝大多数角色终身都不会有 party）。 这个头文件在整份档案里有两份byte-identical 拷贝 （kungfu/class/mingjiao/mingjiao.h 与 d/mingjiao/npc/mingjiao.h）， 通过 fawang.h/shizhe.h/menzhu.h/zhangqishi.h/tanzhu.h/ tangzhu.h 六个中间头文件被 15+ 个明教 NPC 文件间接引入（青翼蝠王韦 一笑、青龙坛主程嘲风等），覆盖面很广。

修复：在下标前补 mapp() 守卫（两份拷贝同步修复）：

mapping party;
if ( environment(ob) != environment(me) ) return;
if ( !mapp(party = ob->query("party")) ) return;
if ( party["party_name"] == HIG "明教" NOR ) {
  if ( party["level"] < me->query("level"))
    message_vision(..., me, ob );
}

现场用一个刚注册、从未加入任何门派的角色重新走进明教山门并 east 穿过程嘲风所在的房间验证：不再崩溃，debug.log 全程干净（只有既有 的、与本次改动无关的启动期 nosave 声明警告）。

顺带发现 zhangqishi.h/tangzhu.h（间接经由 mingjiao.h）里已经 存在一个编译期失败（HIG "明教" NOR 这种宏与中文字符串字面量相 邻拼接触发 unexpected L_STRING 语法错误），在本次改动前后都存在、 不受影响——用 git stash 交叉核实过修复前该错误就已独立出现在 zhangqishi.h（yanyuan.lpc/tangyang.lpc/wensong.lpc 等）里， 是与本次运行时崩溃无关的既有内容缺口（148 个既有编译失败之一），未 处理。

标准巡检