xlqy_early — 仙侣情缘 (early/incomplete "driver test" snapshot)

Archive: xlqy-解压看readme.rar (archive #27). Port: 40076. Status: done (boots clean, full registration flow verified end-to-end multiple times incl. real Chinese names, score/look/quit all confirmed working post-login).

What this is / lineage confirmation vs xlqy_new2007 (#26)

Extracts cleanly (no password/special step needed despite the xlqy-解压看 readme.rar "unzip and read the readme" filename) to a root xlqy/ directory. readme.txt's own text (translated): *"start with startxlqy64.bat... this lib is very incomplete, mainly used to test the driver... you can open the rzr channel, it's mostly rzr [artificial NPCs] running around... configure the number of rzr in /adm/daemons/manmade_npcd's max_npcs... the underlying engine has been heavily rewritten, many things are incompatible, no tech support provided."* — an unpolished, pre-#26 snapshot of the same "仙侣情缘" codebase, explicitly shipped for driver-compatibility testing rather than play.

Lineage confirmed via diff, not assumed from the shared title (this project's own repeated lesson: similar Chinese titles are not a reliable lineage signal — see xianlvqiyuan vs xlqy_new2007, sjpl2 vs shujian2008):

• adm/simul_efun/chinese.lpc — identical logic to xlqy_new2007's copy, differing only in whitespace/brace style (diff shows only reformatting, confirmed with diff -bw too — same GBK-byte is_chinese() bug, same §15h fix needed).
• adm/obj/master.lpc — same story: diff -bw shows only brace-style/ whitespace reformatting, not a content fork; same valid_read/ valid_write/valid_override/get_root_uid/get_bb_uid shapes as #26.
• adm/daemons/logind.lpc, adm/daemons/chinesed.lpc — do differ substantially in content (1957 and 309 diff lines respectively) — this is a genuinely earlier/rougher build of the same game, not a byte-clone.
• File counts: 9177 raw .c files here vs 9060 in xlqy_new2007's raw archive (matches the pre-existing TODO.md note of "9174 vs 9060").

Net conclusion: same base engine/authorship (bugbug & alading @ 缥缈水云间, 2003-4-5 credited in nearly every file header), an earlier development snapshot with a rougher/smaller logind.lpc/chinesed.lpc, NOT a duplicate archive. xlqy_new2007's proven master.lpc/chinese.lpc fixes ported directly and worked unchanged; logind.lpc's check_legal_name needed its own independent §15h fix since that file's content differs.

Fixes applied

1. AGENTS.md §15h (chinese.lpc): is_chinese()'s GBK lead-byte range check (str[0] > 160 && str[0] < 255, strlen(str) >= 2) replaced with a CJK Unicode codepoint range check (str[0] >= 0x4e00 && str[0] <= 0x9fff, strlen(str) >= 1). Ported the same shape already proven on xlqy_new2007. 2. AGENTS.md §15h (logind.lpc check_legal_name): byte-calibrated bound strlen(name) < 2 || > 12 → < 1 || > 6 (message already says "必须是一到六个中文字" — 1 to 6 Chinese characters — halving the byte bound just makes the code match what the message already promised); dropped the i%2==0 && GBK-lead-byte-alternation gate from the sliding-window loop so every character position is checked, not every other one. 3. AGENTS.md §14 (valid_override): upgraded from the 2-arg (file, name) signature to the documented 3-arg (file, name, main_file) form, checking main_file == SIMUL_EFUN_OB/MASTER_OB too — free insurance for #include-composed simul_efun fragments (confirmed this specific gap causes an lpcc-sweep-only failure on adm/simul_efun/object.lpc, see lpcc section below; never actually surfaces on a real boot). 4. AGENTS.md §8d/§15o (get_include_path()): added to master.lpc (was entirely absent) — prepends the compiling file's own directory to the include search path so #include "local.h"-next-to-its-user resolves for compiles triggered live mid-connection (this lineage has several such local headers: d/city/workroom.h, d/obj/misc/ message.h, d/obj/quest/quest.h, d/*/npc/reporting.h, d/city/misc/banned.h). 5. AGENTS.md §15w (log_error): gated the player-facing broadcast on the message NOT containing "warning:" (this driver funnels every compile *warning* — e.g. the harmless nosave-function warnings that static→nosave renaming produces — through the same apply as real fatal errors; without the gate, any lazily-compiled file with a cosmetic warning would flash the scary default-error message at whichever player happened to be online). 6. AGENTS.md §8h (convertd.lpc Greek-table typo): one instance, line 258, "α\", → "α", (plain LF file, verified with cat -A before choosing the non-CRLF sed pattern per the documented lesson). 7. niu.lpc disallowed ..-relative include (§15t #2): d/ourhome/honglou/npc/niu.lpc had #include "../honglou.h" — this driver disallows .. in #include paths outright. Fixed to the real absolute quoted path "/d/ourhome/honglou/honglou.h". 8. eventd.lpc fixed-width extension-strip bug (AGENTS.md §2's [0..<3]→[0..<5] nitan-family-shaped variant, found independently here in a non-nitan-lineage lib): collect_all_event()'s map_array(get_dir(EVENT_DIR+"*.lpc"), (: $1[0..<3] :)) was correct for stripping the original 2-char .c extension but left a stray trailing .l after the .c→.lpc rename ("emei.lpc"[0..<3] → "emei.l", not "emei") — every event failed to resolve (call_other() couldn't find object '.../emei.l', one per preload, non-fatal since wrapped in the daemon's own catch()). Widened to [0..<5] per the established +2 formula. 9. d/city/workroom.h broken __FILE__ usage (new finding, not yet in AGENTS.md): this header is #included (not inherited) into 3 sibling rooms (workroom1/2/3.lpc), and used __FILE__ inside a start_busy() closure intending "the room that's actually running this code" — but __FILE__ is a preprocessor macro that expands to whatever file is textually being *scanned* at that point, which for a #included fragment is always the header's own path (/d/city/workroom.h, never a loadable object on its own), not whichever of the 3 rooms actually included it. This produced ~130+ call_other() couldn't find object '/d/city/workroom.h' runtime errors per test session (the highest-volume error category by far, generated continuously by autonomous NPCs' "work for money" AI behavior in these rooms). Fixed by replacing both __FILE__ uses with file_name(this_object()) (resolves correctly at runtime regardless of which of the 3 rooms is actually executing). Worth adding to AGENTS.md as a new catalog entry — this is a generic trap for any lib with a #included (not inherited) fragment that uses __FILE__ expecting "the including object," since standard C-style preprocessor semantics (this driver's __FILE__ genuinely matches plain C here, confirmed by reading lexer_rules_pp.cc) never behaved that way. 10. daemon/skill/dao/taijitu.lpc — AGENTS.md §15aa-shaped same-file forward-reference bug (new instance, different mechanism than §15aa's original "same name as a real efun" trap): cast_person() (defined early in the file) calls remove_effect_using(me, target) before the file's OWN 2-arg (object me, object target) override of that name is defined later in the file. Because the base class std/sserver.lpc (reached via inherit FAMILYSKILL) already defines an INHERITED remove_effect_using(object me, string file), the compiler bound the early call to that inherited (wrong-arity) version instead — error: Bad type for argument 2 of remove_effect_using ( string vs object ). A first attempt at a fix (changing the call site to pass __FILE__ instead of target, matching every sibling skill file's convention) compiled but was WRONG: it silently changed behavior to call the generic inherited cleanup instead of this file's own invisibility-removal/room-restoration logic. Corrected fix: moved the actual function body (not just a prototype — a bare forward *declaration* alone was insufficient here, still bound to the wrong inherited version) to appear before cast_person()'s first call to it. Confirmed clean via lpcc before and after. This skill is only reachable via actual "太极图" (taijitu) spell casting in combat, not the registration/boot path, but was a real semantic bug worth fixing correctly rather than papering over. 11. adm/daemons/cndd.lpc — THREE separate undeclared-variable/ forward-reference bugs in the condition-tracking daemon, found via the lpcc sweep, all pre-existing in the raw archive (confirmed by grepping the raw .c file directly — none of these declarations were ever present, not something our conversion dropped): - clear_condition(object me, string cnd) used a bare conditions mapping throughout with NO declaration/fetch at all. Every sibling function in the same file (query_entire_conditions() right above it) fetches the equivalent value via me->query_temp("conditions") — added the same fetch as a local declaration at the top of the function (unambiguous fix, not a guess, matching an existing sibling idiom in the same file). - clear_conditions_by_type(string required_type) had the identical conditions-undeclared bug, but this function takes NO me parameter (unlike clear_condition) — fixed via this_object()->query_temp("conditions") instead. - A SEPARATE, parallel hb_conditions mapping (heartbeat-scoped condition store, used by update_hb_condition()/ apply_hb_condition()/query_hb_condition()/ clear_hb_condition()) was used identically across all four functions with no declaration anywhere in the file at all (not even a query_temp fetch — this one is genuinely meant to be a persistent per-object global, since it needs to survive across calls with no explicit save-back). Added nosave mapping hb_conditions; as a real file-level global, resolving all four call sites at once. - Bonus: clear_condition() calls clear_hb_condition() (defined much later in the same file) before that definition appears — "Undefined function clear_hb_condition" (AGENTS.md §8b's classic "same-file forward reference" shape). Fixed with a one-line forward declaration near the top of the file (this one DID work as a bare declaration — unlike the taijitu.lpc case above, since there's no competing inherited function of the same name to shadow it). - Verified compiles clean via lpcc after all four fixes. 12. Uppercase .C rename (AGENTS.md's "watch for uppercase .C" check): 3 files missed by convert_lib.sh's lowercase-only glob (d/obj/drug/YUNDAN.C, d/guzhanchang/obj/{DIAMOND,BAG}.C) — manually renamed to .lpc; all three were already UTF-8 (not GBK), so no additional encoding pass was needed. Confirmed no dangling .c/ .C-suffixed string references to these three basenames anywhere else in the lib (only stale .bak/timestamp-suffixed backup copies reference the related zone, none of them live .lpc code). 13. Created missing save-data directories (not present anywhere in the raw archive — data/ shipped completely empty): data/{login, user,npc,fabao,gold,pet}/{a..z}/ — this driver's save_object() (vm/internal/base/object.cc) does a plain fopen() with no mkdir, so saving to a nonexistent sharded directory throws an uncaught error() ("Could not open ... for a save"). Since enter_world()'s user->save(); ob->save(); calls have no catch() around them, this would have silently killed every new registration right after gender selection (the same failure shape as AGENTS.md §15ah, just for save_object() rather than log_file()). Also created log/nosave/ (referenced by master.lpc's crash handler and several log_file("nosave/...") calls, same §15ah pattern, lower-impact since only reachable on an actual crash).

Confirmed NOT needed (checked via source reading, not assumption)

• §4 (lazy load_object(SECURITY_D) recursion in valid_read/ valid_write): master.lpc's versions only do find_object(), never load_object() — same as xlqy_new2007, not the recursion-prone shape.
• §7 (get_root_uid/get_bb_uid missing): both already present.
• §15n/§15o func-allowlist for a custom securityd.lpc ACL: this lib's valid_read/valid_write already use an allow-by-default- unless-a-known-data-op pattern (if (func != "read_file" && func != "file_size" && func != "stat" && func != "read_bytes" && func != "tail" && func != "ed_start") return 1;) that already implicitly allows load_object/recompile_object/include without needing an explicit allowlist addition — confirmed by reading the function body, not by hitting the crash.
• §8c (this_player()-override-in-valid_read footgun): get_status() is called directly with the passed user, no this_player() substitution anywhere in securityd.lpc.
• §15p (dns_master preload exclusion): adm/etc/preload never listed dns_master/network/dns_master to begin with — nothing to exclude. The adm/daemons/network/ tree exists (intermud daemons, mail/ping/telnet services) but is entirely unreachable from registration/normal play; its own missing headers (post.h, uid.h, priv.h — genuinely absent from the archive) only surface as lpcc-sweep noise (see below), never a boot/connect issue.
• §15l (destruct(SIMUL_EFUN_OB) in master's create()): no such call anywhere in master.lpc.
• §15ae (private nomask command_hook breaking post-login commands): feature/command.lpc's command_hook is already nomask int command_hook(...) with private commented out in the source (// private nomask int command_hook(string arg)) — already fixed by whoever last touched this codebase (or never had the bug). Confirmed both by reading the source AND empirically: score/look/quit all produced correct real output in every test run.
• §15ag (ed_start/ed_cmd/query_ed_mode): only appears as a string literal inside securityd.lpc's func-name comparison list (classifying which read ops are "sensitive"), never actually called.
• §15al (crypt(str, 0) random-hash trap): logind.lpc uses crypt(pass, 0) only to set a NEW password at registration time (the resulting hash string itself, containing its own embedded salt, is what gets compared against on subsequent logins via crypt(pass, my_pass) — the stored hash IS the salt for verification, so a fresh random salt at set-time is completely fine here). This is the ordinary password-hashing idiom, not the client-challenge-handshake shape §15al actually warns about (no client-side independent computation of the hash is expected anywhere in this lib).
• §15am (file_size()==-1 truthiness trap): the two `file_size(...)

>= 0 checks in logind.lpc` are already written correctly.

• §8e (tail() missing efun): only reachable from cmds/wiz/tail.lpc (an admin command, confirmed non-fatal, not on the boot/simul_efun compile path) — never touches the fatal adm/simul_efun/file.lpc case some other libs hit.
• LONELY_IMPROVED / count() bignum family: zero hits — this is not a nitan/Lonely-lineage lib, no efun::set/query/delete-family simul_efun architecture bug applies either (this codebase's feature/ dbase.lpc already implements real per-object set/query/delete).
• §15u dormant anti-piracy self-destruct: no shutdown()/mass-delete pattern found in securityd.lpc/master.lpc.
• §15z #define nosave static/#define protected static shim collision: no such compatibility macro present anywhere.

Interactive test results — full registration + post-login commands

Registration shape (read from logind.lpc's actual callback chain, not inferred from prompt text): GB/BIG5 selection → "are you a student" age-gate (any non-"no" ends the session) → English id prompt (new must be typed literally) → English id → no y/n confirmation step → Chinese name prompt → password → password confirmation → email → gender (m/f) → an always-instant, non-interactive "gift allocation" step (the d/wiz/ init.lpc room's own input_to("get_input", ...) line is commented out in the source, so get_start() calls do_finish() synchronously via a call_out(0) right when the player enters — no real stat customization ever happens, matching the archive's own "not fully finished" nature) → drops the new character into an actual starting room (聚见亭, chosen at random from several candidates per d/wiz/init.lpc's own logic).

Verified successfully in FOUR independent full continuous sessions, each incl. a real Chinese name reaching the actual game world and at least one post-login command producing correct output:

• 秦风 (Qinfeng, male) — fast/clean run right after a cold boot. look → room description (聚见亭) with correct NPCs listed; score → full, correct character sheet (仙衔/职称/attributes/gender all correct); quit → correct farewell flavor text. Zero debug.log errors this session.
• 秦岭 (Qinling, female) — same result, incl. correct female honorific/gender fields on the character sheet.
• 秦天 (Qintian, male) — same result again after a full driver restart with every fix above applied (including the corrected taijitu.lpc/cndd.lpc fixes), confirming a clean state from a fresh boot: score produced the correct sheet, quit the correct farewell, zero debug.log runtime errors for the whole session.
• 秦水 (Qinshui, male) — registered successfully under heavy background CPU load (see below); confirmed via the actual saved data/user/q/qinshui.o/data/login/q/qinshui.o files (correct name, gender, stats, SHA-512 password hash) even though the live telnet transcript itself got cut short by the test script's own timeout budget before showing the final room — not a functional failure, see next section.

One recurring, understood-and-benign cosmetic quirk: get_name() in logind.lpc has a leftover debug statement, printf("%O\n", ob);, printed right after a Chinese name is accepted — shows the raw login object reference (e.g. /obj/login#16) to the player. Pre-existing in the original source (not something this pass introduced), purely cosmetic, does not block anything. A second cosmetic-only artifact seen once: sending an early command (9/look) in the split-second window between entering d/wiz/init and its call_out(0)-triggered do_finish() firing can get silently swallowed by d/wiz/init.lpc's own add_action("do_block", "", 1) catch-all (which only allows look/ help/story/say while in that room) and shows the driver's generic default fail message ("什么？") once — harmless, and the very next line in every affected transcript is the correct room entry/gift completion; not a registration or command-dispatch defect.

Known characteristic, not a bug: heavy CPU load from autonomous "rzr" NPC roaming

This archive ships with adm/daemons/manmade_npcd.lpc's max_npcs = 100 — per the readme's own description, up to 100 autonomous "rzr" (人造人/ artificial-human) NPCs wander the ~9,177-file map continuously from boot, lazily compiling every room/NPC/item file they touch for the first time. Observed: driver CPU climbed from ~7-20% right after boot to a sustained 75-85% within a few minutes and stayed there for the ~12+ minutes this pass kept the driver running, visible in debug.log as a continuous stream of "In file included from ..." compile-cascade lines across every zone in the map. This is a genuine, intentional feature of this particular "for driver testing" snapshot (explicitly what the readme describes), not a conversion defect — no crash, no fatal error, the driver stayed fully responsive to new connections throughout (confirmed: a fresh registration completed correctly even while this was happening, just with higher latency on some responses since this driver's game-tick processing is single-threaded and a heavy background lazy-compile pass competes for the same thread). Two of the six test connections in this pass hit this slowdown directly (the qinbao/qinchuan/qinhuai runs issued in the middle of this pass, while the storm was in full swing, never actually completed within their allotted test-script timeout budgets — confirmed via the absence of a corresponding data/user// data/login/ save file for those three ids, i.e. these were test-harness timeouts, not silent registration failures). Not fixed/tuned down since it's original game-balance content, not a driver-compat defect; flagging here so a future session isn't surprised by it.

lpcc sweep

9177 files, 9070 pass / 107 fail (98.8%) (libs/xlqy_early/ lpcc_batch_raw.log / lpcc_fail.log, both left in place per the established per-lib convention). Triaged by category rather than fixing all 107 blind, per AGENTS.md §6b:

• ~26 files (d/kaifeng/npc/**/quest*.lpc, incl. .../backup/ and a d/dntg/yunlou/npc//quest.lpc sibling): Cannot #include colors.h / reporting.h, cascading into Undefined function query/Unable to find inherited function 'setup' etc. Root cause: these files live one directory level below (.../kaifeng/npc/kaifeng/) where colors.h/ reporting.h actually reside (.../kaifeng/npc/), so a plain quoted #include fails to find them specifically when compiled via bare lpcc** — the newly-added get_include_path() (fix #4 above) computes exactly the right parent directory for real mid-connection compiles, but per AGENTS.md §15o's documented caveat, get_include_path() is never consulted for lpcc-batch/no-VM-context compiles at all, so this category is expected sweep noise, not a live defect — confirmed absent from every real boot/interactive-test debug.log in this pass (grepped for both header names, zero hits). Not independently proven at true runtime (none of our test sessions happened to visit this specific Kaifeng zone), but matches the well-established pattern from many prior libs closely enough to trust without further chasing.
• ~16 files in directories literally named old/backup (d/baoshi/ obj/old/{bs,js}_{b,g,r,y,z}1.lpc, d/kaifeng/npc/{old,backup/old}/ {bei,shan,zhi}.lpc): missing build_gold.h/similar shared headers. Confirmed via grep -rl that nothing outside these old/backup directories references any of these files by path — genuinely dead, superseded content, not reachable in play.
• 6 files under adm/daemons/network/ (mail_serv, netmail, pingd, pingtcp, telnetd, userid): missing post.h/uid.h/ priv.h — confirmed genuinely absent from the whole archive (not a local-include-path issue), an entire never-fully-shipped intermud/mail subsystem. None of these files are in adm/etc/preload and none are reachable from registration/ordinary play.
• 7 files with genuine raw pre-existing byte corruption (Illegal character errors decoding to garbage/mixed CJK+control bytes): quest/xunbao/obj/shuijingqiu.lpc (+ its d/obj/quest/ duplicate), d/moon/obj/poem.lpc, d/obj/books-nonskill/hmeng014.lpc, d/shendian/obj/niepan.lpc, d/wiz/angell/hp.lpc, story/ pifeng2.lpc. Confirmed for shuijingqiu.c by inspecting the RAW pre-conversion bytes directly (locate_quest(this_player(),arg followed immediately by \xab\xc9\x85w)\xf6\xe6\xbb6o~m#\xa3y\x9e\xf4\x8a) — this garbage is already present in the original archive, not introduced by our GB18030 conversion (iconv just decoded already-corrupt bytes into equally nonsensical but valid UTF-8). Not reconstructed/guessed at; documented as pre-existing archive bit-rot.
• 2 genuine bugs found and FIXED (see Fixes #10/#11 above): daemon/skill/dao/taijitu.lpc (same-file forward-reference mis-binding) and adm/daemons/cndd.lpc (3 separate undeclared-variable/ forward-reference issues). Both now compile clean, verified via individual lpcc re-checks (a full re-sweep was not re-run afterward to conserve host resources given other agents were sweeping concurrently — memory stayed healthy throughout this pass's own sweep, 15-19GB available the whole time, well clear of the danger zone).
• adm/simul_efun/object.lpc: Invalid simulated efunction override — this is precisely AGENTS.md §14's documented "only ever surfaces when lpcc compiles the fragment as a standalone top-level object" false positive; the 3-arg valid_override() fix (#3 above) is already in place and this error is confirmed absent from every real boot's debug.log.
• cmds/wiz/tail.lpc: Undefined function tail — AGENTS.md §8e's documented benign case (admin command only, not the fatal simul_efun-compile-path variant).
• cmds/adm/{socket,dumpsocket}.lpc: Undefined function dump_socket_status — peripheral admin socket-debugging tools, never reached by registration/ordinary play, not chased further.
• Remaining ~40 files: a long tail of individual NPC/item/room content, one example fully diagnosed (d/city/npc/aluoben.lpc — the file itself compiles with ZERO errors, but its create() calls carry_object("/d/city/npc/obj/sengpao") for a monk's-robe item that doesn't exist anywhere in this archive — a genuine, narrow missing-item content gap, AGENTS.md §13/§15e's category, not a driver-compat bug). The rest were not individually opened given the sample already confirmed the expected mix (missing-content gaps and isolated pre-existing content typos) rather than a shared systemic cause, per §6b's explicit guidance not to exhaustively diagnose every last item on a lib this size once the failure categories are understood.

Suggested new AGENTS.md catalog entries (not added — instructed not to edit AGENTS.md directly)

• A #included (not inherited) fragment file using __FILE__ to mean "whichever object actually included me" is always wrong on this driver — __FILE__ expands to the file currently being *lexically scanned* (standard C-preprocessor semantics, confirmed in lexer_rules_pp.cc), which for an #included header is the header's own path, never the includer's. Fix: file_name(this_object()) instead, which resolves correctly at runtime. Found in d/city/workroom.h, the highest-volume single error source in this lib's own testing (100+ runtime errors per session from autonomous NPCs repeatedly triggering the broken path).
• A same-file forward-reference to a locally-overridden function name that ALSO exists on an inherited base class can bind to the WRONG (inherited) version even with an explicit forward *declaration* present — only moving the real function body (not just a prototype) above its first caller fixed it in this instance (daemon/skill/dao/taijitu.lpc's remove_effect_using). This is a stronger/different failure mode than §15aa's original finding (which was specifically about a same-named-as-a-real-*efun* wrapper); here the name collision is with an ordinary *inherited* function, and a bare prototype-only forward declaration was NOT sufficient insurance the way it normally would be for an unrelated new name.

2026-07-23: driver rebuild retest + LPC formatter + WASM check

• Formatter: ran tools/lpc-syntax's format-corpus.mjs over all 9177 .lpc files in work/; 9168 written, 9 already-conformant, 0 errors (a clean, error-free run — unusual for this batch's messier libs, consistent with this codebase's otherwise-tidy source).
• Native retest: rebuilt ~/src/fluffos/build-debug/src/driver booted this lib clean (zero fatal errors in log/debug.log, only the routine Unknown #pragma/unused-local warnings already known from earlier passes). Full registration flow verified end-to-end with a fresh real Chinese name (秦月) — gb/no/new/english-id/Chinese name/password/email/gender/gift-allocation all completed, landed in 聚见亭; look showed the correct room+NPCs, score produced a correct full character sheet, quit gave the correct farewell text. Zero debug.log errors this session. The reformat did not disturb anything — same clean result as prior passes.
• WASM: booted cleanly under build-wasm (only the expected non-fatal preload warnings, no fatal errors). Full registration flow (gb/no/new/english-id/Chinese name 秦波/password/email/gender) also completed successfully under WASM, reaching the same 聚见亭 starting room; look and quit both worked correctly. This lib's registration does not gate on query_ip_number() format, so it is unaffected by the known WASM IP-formatting limitation — however, the "上次连线的地址" (last-connected-address) display line, which normally prints an IP, printed a garbled/misformatted value (a timestamp-looking string) under WASM instead. This is a purely cosmetic manifestation of the same known query_ip_number()-under-WASM driver limitation (see AGENTS.md's WASM section) — not a functional blocker, registration/login/commands all still work. Verdict: fully playable under WASM, one cosmetic IP-display glitch noted, not fixed (driver-side, out of scope).

WASM-enablement pass (loopback-allow / gate bypass / admin seed)

Standard WASM-first pass per AGENTS.md §1.3b/e and §1.5. Gates patched:

• adm/daemons/band.lpc — added is_loopback_site(string) helper (loopback / empty / malformed-IP → treated as local) and short-circuit return 0; at the top of is_banned(), create_char_banned(), is_strict_banned() (the three IP ban gates the login flow calls).
• adm/daemons/logind.lpc — added is_loopback_conn(object) helper (same test on query_ip_number(ob)), and:

- logon() reconnect-flood throttle (last_ip==ip && time+5>time, ~line 79) — now !is_loopback_conn(ob) && ..., loopback exempt. - logon() "too many from this IP" cap (logon_cnt > 10, ~line 98) — loopback exempt. - encoding() !ip_name destruct + the dotted-quad char-loop format validator (~lines 163-173) — whole block now guarded by if (!is_loopback_conn(ob)) { ... }, so loopback/garbage-IP connections skip both. This was the WASM-fatal gate (query_ip_name/number return garbage under WASM). - No uptime() < N startup-grace *destruct* gate exists in this lib; the uptime() use at ~line 132 is the newid registration-throttle window (game content) — left intact.

Admin account seeded: id fluffos, pw Mud@2026, name 浮浮, granted (admin) by adding fluffos (admin) to adm/etc/wizlist. Verified via real registration flow (gb/no/new/fluffos/浮浮/Mud@2026/.../m → entered world) then relogin + update /adm/daemons/logind → "成功" and status line shows (admin). Retest: fresh normal registration still works, zero new debug.log errors. Save file: work/data/user/f/fluffos.o (tracked, NOT gitignored — no force-add needed).

Fail-closed retrofit for the loopback-allow gate (2026-07-24)

The loopback helper above was originally written matching the project-wide convention at patch time (AGENTS.md §1.3b), which also treated an empty/non-string/malformed query_ip_number() result as loopback, defensively, because the WASM driver used to return garbage there. That underlying driver bug is now fixed (fluffos commits e33bb5da "fix: query_ip_number() returned uninitialized garbage under WASM" and 007bb863 "feat: synthetic resolve() on WASM instead of raising an LPC error", both 2026-07-23; the locally-built build-debug/build-wasm binaries already postdate both commits), so treating unparseable IPs as trusted is a fail-open gap with no remaining justification. Retrofitted to fail-closed: loopback is now strictly ip == "127.0.0.1" || ip == "::1" || ip[0..3] == "127." (with a stringp() guard before the slice) — a malformed/empty IP now falls through to the NORMAL gate instead of being treated as local. Retested after tightening: fresh driver boot clean, fluffos loopback login and its wizard update command both still work; zero new debug.log errors.

深度功能测试 / Deep functional test (2026-08-06/07)

第一次完整游玩测试（原生驱动 build，ASAN/UBSAN debug 构建）。测试角 色 id xlqytstb，中文名 小仙女。本轮 WASM 未重新验证：emsdk 工具链 下载硬编码指向 storage.googleapis.com，本次会话的出口代理策略性拒 绝该域名（403，已用 curl $HTTPS_PROXY/__agentproxy/status 确认是策 略拒绝而非临时故障），本地无法构建 WASM 驱动。

发现并修复：maximum evaluation cost 过低，开机预载阶段真实崩溃过一次（AGENTS.md §7.90 新实例）

• 症状：驱动首次启动（未做任何修复前），debug.log 出现 Eval interrupted: object adm/daemons/leveld cost limit reached, limit: 500000 usec. 以及更严重的一条*Can't catch eval cost too big error.（连 catch() 都拦不住的版本），栈追踪指向 adm/obj/master.lpc:139 的 preload("/adm/daemons/leveld") 调用。
• 根因：config.fluffos 的 maximum evaluation cost : 500000 比 这个项目常见的 700000 模板默认值还低。leveld.lpc 的 create() 内建一个真实的、合法的双层循环（为每个等级预计算升级所需经验/道行 表，levelup_cfg 有多个等级分段），本身不是死循环或 bug，只是这份 预载计算的开销天然超过了 500000 usec 的预算。
• 修复：提高到 5000000（本项目 30+ 份档案验证过安全的数值，与 xyj2000f/xiyouji450/xiyouji2006 系列同一处理方式，虽然血缘家 族不同）。
• 验证：修复前重启驱动，debug.log 稳定复现上述两条错误；修复 后重启，同样的预载流程（含这份档案自带的 100 个自动游走"人造人" NPC 在开机后几分钟内陆续触发全图房间编译，是这份档案的已知特色负 载）全程无任何 eval-cost 中止或"can't catch"错误，即使在这个持续 高负载窗口内也没有复发。

发现并修复：注册流程遗留的 printf("%O", ob) 调试输出（AGENTS.md §7.34 已知模式的又一实例）

adm/daemons/logind.lpc 中文名确认成功分支有一行未加注释的 printf("%O\n", ob);，同一文件里没有找到第二条并行路径的重复实例。 按 §7.34 既定修法直接删除。修复前用第一个测试账号亲眼看到裸露的对象 路径（如 /obj/login#N）夹在提示语之间；修复后第二次注册未再出现。 §9 格式化自检通过。

发现并修复：中文名确认提示里的 GAME_NAME 宏字面量泄漏（新发现的模式，未见于此前任何一份档案的记录）

• 症状：注册流程走到确认中文名的提示时，玩家会看到字面的英文单 词 GAME_NAME 出现在原本应该显示游戏真实名称（"洪荒西游"）的地 方：请您给自己想一个符合〖 GAME_NAME 〗神话世界的中文名字...。
• 根因：adm/daemons/logind.lpc 的 confirm_id() 用 write(@TEXT ... TEXT) 多行原始字符串字面量输出这段提示，GAME_NAME 被直接打在字符串内部而不是像同一文件里其它十几处那样用 + GAME_NAME + 字符串拼接引用宏。LPC 的宏预处理不会展开多行字符串 字面量内部的标识符，所以这两处 GAME_NAME 从未真正被替换成 #define GAME_NAME "洪荒西游" 的实际值，从这份档案诞生起就一直原 样显示给每一个新注册的玩家。
• 修复：把这段 @TEXT 块改写成普通的 write() 字符串拼接（与文 件里其它 GAME_NAME 引用点写法一致），让宏值正确代入。
• 验证：修复前实测复现（提示语里的字面 GAME_NAME）；修复后同 一提示正确显示"洪荒西游"。已用脚本扫描全档案 adm/daemons/ 目录 下所有 @WORD ... WORD 多行字符串块，确认没有其它 GAME_NAME/ LIB_NAME 被同样错误地嵌入字符串内部的情况。这类"宏字面量嵌进多 行字符串导致原样泄漏给玩家"是一个新观察到的模式，值得在检查其它档 案的登录流程时留意（检测方法：grep 每个 @WORD ... WORD 块内容是 否含有已 #define 的大写常量名）。

测试内容与结果

• 注册：GB 编码 → 是否中小学生（no）→ new → 英文名（8 字符上限， 超长会被拒绝）→ 中文名（小仙女，确认了上面两个 bug 均已修复）→ 密 码 ×2 → 邮箱 → 性别（f），全程顺利进入起始房间〖聚见亭〗。
• 门派/技能捷径：驻留在起始房间的"发礼物的 小老头"（d/ourhome/ npc/laotou.lpc）——ask laotou about 礼物 一次性授予 9 项技能（等 级 100）及 100 万点战斗经验/道行/潜能，skills 命令确认发放正确， 与 bxsj/xiyouji2006 系的"赠礼 NPC"捷径同类设计，非 bug。附带触 发了一条"存款不够,需要一两黄金"的消息（疑似自动升级检查在零存款下 被部分拒绝）——未深究，属于经济系统内部逻辑，不在本轮"仅修程序 bug"范围内，如实记录为观察而非缺陷。
• 持久化：真实 quit（无反滥用二次确认，直接产生告别文字）后重 新登录，技能/经验/道行等级全部正确复原（score 显示 [驾轻就熟] 与 quit 前一致），但房间重置回了起始房间〖聚见亭〗而非 quit 时所在 的〖荒郊小店〗——与本轮之前测试过的 xyj2000f/xiyouji450/ xiyouji2006 三份档案（不同血缘家族）表现出的"固定登录入口"设计完 全一致，判断为这一批"西游"题材 MUD 共有的既定设计，不是位置持久化 bug。
• 管理员账号：fluffos/Mud@2026 登录，update /adm/daemons/ logind 热更新成功（含本轮三处修复），确认写 ACL 正常——本轮实测 中这份档案因为 100 个人造人 NPC 的持续后台编译负载，响应延迟明显 比其它档案更高，命令确认经常要等待数秒才能收到，属于已知的特色负 载而非 bug，测试时相应放宽了等待时间。
• 战斗、门派拜师（组织路线）、经济/商店：未覆盖——沿着起始 房间往北探索了数个房间（荒郊野外若干段、荒郊小店），全程未遇到任 何主动可挑战的敌对目标，源码里唯一疑似"安全陪练木人"的两份文件 （d/city/obj/muren.lpc、d/obj/misc/muren.lpc）在 work/d/ 里没 有任何房间引用它们，很可能是这份"半成品测试版"存档里从未真正接入 地图的遗留内容。如实标注为本轮未覆盖，而非默认"和同代码库的其它档 案一样所以没问题"。

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

同一套代码库，更早的一份粗糙快照。

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

• BBS_BOARD、BULLETIN_BOARD inherit + 多余 replace_program() 致命形状（AGENTS.md §7.86，post 命令崩溃）：全档案 40 处命中，已删除多余的 replace_program(...) 调用（保留 inherit），逐文件保留原有行尾格式（CRLF/LF 按文件原样）。本次为跨库 §7.86 扫描修复（触发原因：该 bug 已在 6+ 个互不相关的血统家族独立确认，属于近乎普遍的拷贝粘贴模式），仅做编译检查（驱动干净启动、端口正常监听），未做完整 §10.7 深度游玩测试。

§7.100 sweep (2026-08-19)

Fixed the corpus-wide inherit ROOM; ... replace_program(ROOM); redundant-replace bug (AGENTS.md §7.100). 332 live occurrences deleted: 331 via scripted sweep (fix_710_room.py), plus 1 hand-fixed roommaker-tool template (obj/roommaker.lpc, simple string-builder variant, same shape as sibling xlqy_new2007). 10 already-commented-out instances left untouched. No real .lpc source found under work/data/. Verified via build-debug driver boot: clean compile, port 40076 listening, zero new "cannot replace"/"cannot bind" debug.log lines.

§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): 3 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.

Round-four follow-up: combat / shop / sect apprenticeship (2026-08-24)

Closed the three gaps flagged as "未覆盖" above. Walking exploration from the starting room again turned up nothing (the only exits are north into a short dead-end path, and out into a fogged teleport) — reachable hostile NPCs, a working shop, and the three real sect masters all live in completely separate map regions (/d/dntg/hgs/*, /d/lingtai/*) with no room-file path connecting them back to the start area, so this pass used the admin account's goto to reach them directly, per the task's "map-reading tools" allowance.

• Combat: goto'd to /d/dntg/hgs/dongnei (水帘洞内) and fought 混世魔王 (attitude: "killer", one of the few genuinely aggressive NPCs in this archive — most d/dntg/hgs NPCs are "peaceful"/ "friendly"). Combat ran to resolution (the under-powered admin lost and was moved to a recovery inn with health restored) with zero new lines in debug.log — confirmed clean, no bug.
• Shop/economy: 吴家当铺 (/d/dntg/hgs/pownshop, HOCKSHOP/ std/room/hockshop.lpc). Cloned two mujian (木剑, value 100), sell'd both for 50 copper each (matches the coded 50% sell price), confirmed the shop's list then showed "木剑(mu jian)：一两白银：还 剩二柄" (100 = the item's real value, matches do_buy's full-price logic). Sell math, list math, and inventory bookkeeping all checked out — no bug found.
• Sect apprenticeship — real bug found and fixed. std/char/ familymaster.lpc's attempt_apprentice() (the function every NPC-initiated apprentice <master> call routes through, per cmds/std/apprentice.lpc's else ob->attempt_apprentice(me) branch) had:

`` if (who->query_family() != me->query_family()) { ... "我不收外门弟子" (reject) ... } ` query_family() returns query("family/family_name"), which is 0/undefined for any player who has never joined a sect — i.e. every single first-time applicant, always. Since 0 never equals the master's own family-name string, this check rejected 100% of fresh apprenticeship attempts at all three of the archive's real, reachable sect masters (master yunyang/方寸山三星洞, ma gu/月宫, tidu seng/南海普陀山 — all three inherit FAMILYMASTER directly and share this one broken method), making organic/in-person sect-joining completely unreachable game-wide. This is the same missing-existence-guard shape as AGENTS.md §7.117, just in a different file than that sweep covered (cmds/std/apprentice.lpc and cmds/std/recruit.lpc in this archive already had the correct who->query("family") && ... guard — only familymaster.lpc's independent copy of the same check was missing it). The file's other 4 occurrences of the identical-looking who->query_family() != me->query_family() comparison (expell_me, ask_mieyao, rank_player, ask_equip) were left untouched — those correctly gate "must already be a member" actions, where rejecting a family-less caller is the intended behavior. - Fix: if (who->query_family() && who->query_family() != me->query_family()). - Verified live: pre-fix, apprentice master yunyang (after using admin privilege only to satisfy the unrelated LEVEL_D-> can_apprentice() level-100 gate, and the documented starting-room gift NPC for combat_exp) reliably produced "我不收外门弟子，小兄 弟还是另寻他人吧！". After the fix + a full driver restart (an in-place update of the file recompiles the blueprint but not already-clone()d room NPC instances, so a hot-reload alone did not pick up the fix — worth remembering for future spot-fixes of files reached only through room-populated clones), the same command produced "云阳真人决定收你为弟子" / "你跪了下来...磕了四 个响头" and score correctly showed 门派：[方寸山三星洞], 师承：[方寸山三星洞云阳真人], 职称: 方寸山三星洞第四代弟子. - Test-account pollution (the level/family properties set on the admin account purely to reach/pass the prerequisite gates) was reverted via call me->delete("family") / call me->delete( "level") and saved before logging out; the granted skills/ combat_exp from the starting-room gift NPC were left as-is since that gift is the documented, already-tested normal early-game path and a prior session's save()` already carried the same values.

Driver-side observation (not a mudlib bug, noted for future testers of this specific archive): this lib's ~100 background rzr NPC objects create a genuinely heavy, growing memory/CPU load — an unconstrained boot reached ~21GB RSS (86% of a 23GB box) within ~14 minutes uptime, risking a real system OOM. A ulimit -v cap of 8GB was too tight (the driver aborted on bad_alloc under real background-NPC load); 18GB was sufficient for a short test session. Future testers of this lib should either boot under a generous ulimit -v or keep sessions short and watch free -h.

深度功能测试 round three batch 4 新角度测试 (2026-09-01)：战斗/拜师/经济角度补完

Dispatched specifically to re-verify combat/apprenticeship/economy for this archive, under the impression (from the original 2026-08-06/07 entry above) that these three angles were still "未覆盖". They were not — the "Round-four follow-up" section immediately above this one (dated 2026-08-24) already closed all three gaps and fixed a real bug (familymaster.lpc's attempt_apprentice()). This session's own findings, to avoid future duplicate effort:

• Map-connectivity correction to the 2026-08-24 entry: that pass states "no room-file path connecting them back to the start area" for /d/dntg/hgs/* and had to use admin goto. This is not quite right — /d/ourhome/xiaoting.lpc's (聚见亭, the fixed start room) out command (do_out()) directly ob->move("/d/dntg/hgs/entrance")s the player, no wizard privilege needed. A plain new player who types out (the room's own long-desc explicitly invites this: "跨出栏杆往外一 走(out)") lands in 〖仙石〗 (Huaguoshan) and can walk the entire real map — southdown→westdown→southdown→west→south→south→east→south→ south reaches 傲来国 (Aolai) and its 东方武馆 (a *second*, fully-independent apprenticeship system from the one the 2026-08-24 fix covers, see below). Re-tested this exact out path fresh this session and it works. Worth flagging since "no path, must use goto" in the prior entry could misdirect a future tester into assuming ordinary players can't reach the real content — they can.
• Combat — re-confirmed clean, real damage, real death: fought 小猴子 (monkey1.lpc, combat_exp 50) and 大马猴 (monkey2.lpc, combat_exp 5000) at /d/dntg/hgs/up1 with a fresh level-0 test character (xlqytsti/小仙女) — both died to real, narrated combat ("小猴子死了。"/"大马猴死了。"), score's 死亡 counter incremented correctly (杀死敌人：1 名 → 2 名). Zero new debug.log lines either fight.
• Player death + revival — new, not covered by either prior pass (2026-08-24's combat test only exercised the *admin* account losing a fight). Forced with smash xlqytsti from an admin session: "只见天上 一道闪电不偏不倚地击中你。你死了。" — character revived cleanly and immediately at 〖南城客栈〗 (a different, dedicated revival room from the fixed quit/reconnect start room), health bar back to full (〖气血〗 full/充沛), inventory fully intact (money + worn login clothes untouched), score's 死亡 counter unaffected (only affects 杀死敌人, not a death tally shown here). Zero debug.log errors across the whole death→revival sequence.
• Sect apprenticeship, second independent system — works, not the same code path as the 2026-08-24 fix. /d/dntg/hgs/wuguan/* (东方武馆, the Dongfang family's martial hall in Aolai) is a completely separate custom implementation (npc/zongguan.lpc's ask_join(), triggered by ask boyu about join) — it does NOT inherit FAMILYMASTER and does not call attempt_apprentice(), so it was never touched by the familymaster.lpc fix. Tested fresh: ask boyu about join (with a level-0, age-14 test character, both under the master's age>17/combat_exp>60000 reject thresholds) correctly set wuguan/join, and the previously-locked skills dongfang cong command (gated on query("wuguan/join")) immediately started working, printing the instructor's real 6-skill roster. No bug found in this second system either.
• Economy/shop — re-confirmed clean, exercised further than 2026-08-24's plain buy/sell. 吴家当铺 (/d/dntg/hgs/pownshop, same shop as the prior pass). This time funded the test character via admin clone+give (3 gold total, then a choupao robe) and exercised value/pawn/retrieve, not just list/sell: value choupao → "绸袍价值六两白银...典当可以拿到一张当票...卖断可 以拿到三两白银" (correct pawn-vs-sell price split); pawn choupao → correctly moved the robe out of inventory in exchange for a 当票 (pawn stamp), no destruct on a still-owned item; retrieve stamp → correctly returned the robe AND deducted a real 60-wen redemption fee from the character's own carried cash, with correct gold→silver→coin denomination-breaking change (3 gold → 2 gold + 99 silver + 40 coin after the 60-wen fee) — this is real, working multi-denomination currency math, not a stub.
• give <item> to <player> — real transfer confirmed, not the §7.199 pattern. This archive's cmds/std/give.lpc is a different, independent implementation from the one that had the §7.202-adjacent money-destruction bug on fysjmb — its whole-item path does a real obj->move(who) unconditionally for any userp(who) recipient, no query_is_money()+destruct() shortcut anywhere in the file. Live give gold to xlqytsti (admin→player) correctly moved a real, spendable 3-tael gold stack (confirmed via the pawnshop transaction above, and again after a real quit+reconnect — see next point).
• Currency persistence — independently checked, this archive is NOT in the AGENTS.md §7.199 fysjmb-lineage 16-lib list, confirmed why. work/std/money.lpc's query_autoload() is live/uncommented (string query_autoload() { return query_amount() + ""; }) — the exact opposite of the §7.199 bug shape. Verified live: a real quit while carrying 3 gold's worth of currency produced NO "你丢下" drop message for the money (only for an unrelated carried robe, see below), and a fresh reconnect showed the exact same currency (四十文钱/九十九两银子/二两黄金) still in inventory. Money persistence across quit is fully correct here.
• Investigated but NOT a bug — ordinary equipment (as opposed to money) does not survive a normal quit, by design. Carrying a cloned choupao (绸袍/robe, an ordinary CLOTH-class item, not a quest item) through quit produced "你丢下一件绸袍。" — dropped in whatever room the player happened to quit in, not saved. Traced to std/equip.lpc's query_autoload() being hardcoded return 0; (unconditional, not a disabled/commented accessor like the §7.199 money case) with no matching autoload(string param) receiver defined anywhere in the whole EQUIP class hierarchy — so even flipping this one return value would not actually restore anything (a freshly-new()'d item would come back blank, since there's nothing to call ->autoload(param) on). This is a structurally different shape from §7.199 (that class had BOTH an intact receiver and a merely-disabled accessor — a true one-line regression; this class has neither half of a working pair, so there is nothing to "restore"). Corpus-check: xlqy_new2007 and xyj2000f (both confirmed siblings/lineage-mates of this archive) carry the byte-identical int query_autoload() { return 0; }, and an unrelated lineage (rzrmud) has the same line too — while shzs (a genuinely different, unrelated codebase) has a real working query_autoload()/equip-state pair, proving the *concept* is a normal thing for this class of mudlib to support, just not implemented here. Strong evidence this is deliberate, not an oversight: feature/autoload.lpc's restore_autoload() unconditionally re-grants every female character a fresh /obj/loginload/skirt.lpc + /obj/loginload/shoes.lpc (male: linen.lpc) on every single login/reconnect regardless of what they were wearing before — a dedicated "you'll never end up literally naked" safety net that only makes sense to build if the designers already expected ordinary worn equipment to NOT survive a quit. Left untouched, documented as an observation per this project's "never fix content/design choices" rule — flagging for any future tester who finds it again so it isn't re-investigated from scratch.

- Narrower, separate anomaly noticed in passing, also left unfixed: d/obj/cloth/shoes.lpc and d/obj/cloth/skirt.lpc (a *different*, loot/shop-obtainable pair from the /obj/loginload/ login-freebie pair above) each carry a commented-out //int query_autoload() { return 1; } — the literal §7.199 shape (disabled override on a class with the base already at 0). But skirt.lpc has set("value", 0) (worthless) and both are female_only cosmetic items with no other special-cased state; uncommenting either alone would not achieve real persistence either (equip's base class still has no autoload() receiver, same problem as above) and would just make these 2 minor items behave identically to the several dozen *other* individually-opted-in special items already in the codebase (shen_cloth.lpc, gold_cloth.lpc, the obj/club/*_mark.lpc quest tokens, etc. — all return 1;, uncommented, and presumably each paired with its own bespoke restore logic this survey didn't audit). Not confident enough this is a real regression (vs. two dev leftovers with no functional difference from the base-class default either way) to touch; documented for anyone who revisits equip-persistence in this lineage.

• Testing-methodology finding, not a mudlib bug: scripts/ tmux_mud.sh's telnet launcher is not 8-bit clean in this environment — typing a literal multi-byte UTF-8 Chinese name (e.g. 小仙女) through it and reading it back via tmux capture-pane showed the correct characters (that's the local pty's own echo, not what actually reached the server), but the driver-side check_legal_name()/is_chinese() check reliably rejected the exact same name that a raw-socket client (scripts/mudclient.py, or nc launched inside the same tmux_mud.sh harness in place of telnet) accepted immediately, no rejection, first try. telnet -8 did NOT fix it. This is almost certainly BSD/inetutils telnet's classic NVT-ASCII high-bit stripping on the outbound half of the connection, unrelated to this archive's own AGENTS.md §15h UTF-8 fix (which is correctly in place and works fine once the bytes actually arrive intact). Actionable for future testers of any lib: if a Chinese name/input is spuriously rejected by is_chinese()-style checks through a tmux_mud.sh telnet session, re-test with nc in the same tmux pane (tmux send-keys ... "nc HOST PORT" in place of "telnet HOST PORT") before concluding it's a real mudlib bug — this cost significant time on this session before the raw-socket cross-check caught it.
• Boot-time responsiveness, amplifying the existing "heavy CPU load" observation above: this session's fresh boot took 15-20+ minutes before the socket layer was usably responsive to real player input — far worse than the "several seconds" the original 2026-08-06/07 entry reported, and the growing-RSS/OOM-risk entry above didn't measure responsiveness at all. Root cause confirmed via source read: manmade_npcd.lpc's generate_npc() call_out fires every 5 real seconds and spawns one new autonomous NPC into a random location from a ~70-entry sitewide list until max_npcs (100) is reached — each spawn's first-ever visit to its target room triggers a real lazy compile of that room and everything it pulls in, and under this ASAN/UBSAN debug driver those compiles are slow enough that the *entire* backend loop (including accepting new connections and servicing existing ones) stalls for the whole ramp. Confirmed the ramp is genuinely bounded (CPU dropped to idle and the socket layer became immediately responsive within seconds of a re-boot with the ramp's two call_out()s temporarily commented out, then reverted before committing — this was a throwaway local test edit only, never part of the committed diff). Not a bug — the ramp completing is the intended one-time-per-30-minutes behavior (shuffle_npc/generate_npc re-arm on a 1800s/5s cycle respectively) — but worth recording the real magnitude for whoever next needs a fast, usable boot of this specific archive: expect 15-20 minutes of near-unresponsiveness after every cold boot before testing normally, or temporarily comment out the two call_out() lines at the end of manmade_npcd.lpc create() for a fast local test session (revert before any commit).

No new mudlib bug found or fixed this session — this was a genuine, thorough re-attempt at the three flagged angles (plus a fourth, previously-untested apprenticeship variant) and all of it held up.

AGENTS.md §7.19 fix: enable_player() reentrancy from init()

feature/command.lpc's enable_player() (wrapper around enable_commands()) was reachable from an NPC's init() (via the shared std/char.lpc setup() chain), and enable_commands() is only safe to call from create() -- calling it again on an object already living() makes the driver re-invoke that same object's init() as a side effect, which recursed back into enable_player() on the same call stack until "Too deep recursion" aborted the boot on a room's first-ever visit. Fixed with a true reentrancy flag (in_enable_player_now, set at entry, cleared before every return), NOT a living()-gated guard -- disable_player() in the same file legitimately re-calls enable_commands() while already living() (sleep/wakeup via cmds/std/sleep.lpc, revive via feature/damage.lpc), which a living() guard would silently break. Verified via lpcc --batch single-file compile check (PASS). Part of the corpus-wide §7.19 sweep (Batch C).

深度功能测试（§10.7，2026-10-04）— negative range ends

scripts/lpc_fix_negative_ranges.py: 5 line(s) in 2 file(s) count a range from the end with < (x[a..-1] -> x[a..<1], x[-2..] -> x[<2..]; KB 06 §7.209). In this driver a negative constant end gave "" / ({ }) and a negative start the whole value, so each of these returned the wrong slice; the compile warning A negative constant as the second element of arr[x..y] is gone from the files that compile. Range lvalues (s[0..-1] = text, the prepend idiom) are left alone. A paired compile of the changed files at HEAD and in the working tree showed no new error.

深度功能测试（§10.7，2026-10-04）— undefined macro and simul_efun gaps

• 1 file(s) inherit F_SSERVER; and no header defines it (1 did not compile: syntax error, unexpected L_IDENTIFIER, expecting L_STRING or '('). #define F_SSERVER SSERVER in include/globals.h (KB 04 §6.2, scripts/lpc_alias_macro.py). 0 still fail.

深度功能测试（§10.7，2026-10-05）— here-document terminators

scripts/lpc_fix_heredoc_terminator.py --all --apply: 1 here-document block(s) repaired (1 with the terminator glued to the last text line, 0 with it indented), so End of file in text block no longer hides the room or object behind them: d/moon/bedroom.lpc. The terminator must start its line (the lexer's own test, KB 04 §6.10); a glued one lost its newline in the GBK -> UTF-8 conversion together with a half character, which stays out.

深度功能测试（§10.7，2026-10-04）— paths named in another case

The archive comes from a case-insensitive host: files are stored as BAGUA0.lpc, longjing.C, d/SHAOLIN/, the code names them in lower case (__DIR__ "bagua0", "tea/longjing", "/d/shaolin/..."), so the rooms, NPCs and items behind them could not be loaded (a .C file is not an .lpc file; KB 03 §4.5). scripts/lpc_case_paths.py --convert --apply xlqy_early: 1 file(s) renamed to lower case (.C -> .lpc, .H -> .h) and 2 path reference(s) in 2 file(s) rewritten to the new spelling; 0 skipped, 0 ambiguous. Load check of the 2 objects that were renamed, edited or name a renamed path (HEAD against the working tree, an object is the same under any spelling of its path): 1 PASS -> 2 PASS, 0 that loaded before fail now, 1 more load.

1 files moved (1 .lpc); mostly under adm/daemons/Diabloset.lpc (1). A rescan with scripts/lpc_warnings.py xlqy_early is still due: the renamed files are compiled for the first time.

深度功能测试（§10.7，2026-10-05）— room base survives a raising NPC

scripts/lpc_resilient_room.py --apply: make_inventory() of std/room.lpc loads each inventory object as if (catch(ob = new(file)) || !objectp(ob)) return 0;. new() of a file that is not there returns 0 (the room just lacks that NPC), but new() of a file whose create() raises (a skill file for set_skill() this archive never had, a carry_object() item that is not there, a header that never shipped) raised inside the room and the room did not load at all. The wrong-case renames of this lib (the section above) make the NPCs behind them reachable for the first time, so a room that holds one with such a content gap would have gone from "NPC missing" to "room missing"; now it loads without that NPC, as it did before. The room base compiles and loads with the change (HEAD against the working tree). KB 03 §4.5.

深度功能测试（§10.7，2026-10-05）— tail() simul_efun

scripts/lpc_add_tail.py --apply: cmds/wiz/tail.lpc calls tail(file), an efun of the MudOS this archive ran on that FluffOS does not have (Undefined function tail: the command did not compile). adm/simul_efun/file.lpc now defines void tail(string file): the last 10 lines of the file, written to the player. Load check (HEAD against the working tree): 1 of the 1 tail command file(s) failed to load at HEAD, all load now, and the simul_efun file loads. KB 04 §6.2.

深度功能测试（§10.7，2026-10-05）— 任务表里的 .c 路径与任务守护进程的防护

scripts/lpc_dynamic_rows.py：quest/xunbao/obj/dynamic_quest 里 74 行写的是原档案的 .c 路径。转档时文件已改名 .lpc，而显式后缀按原样解析，load_object("/d/x.c")、new("/d/obj/quest/x.c") 返回 0 且不报错（KB 03 §4.2，KB 06 §7.220），所以 quest/xunbao/npc/xunbaonpc.lpc 读到的每一行都加载不出来：随机任务和任务物品从未生成，在 create() 里直接对结果调用 tar->set() 的版本还会崩溃，连带加载它的 cron 守护进程和 give 的任务钩子。这些行已改为 .lpc。 scripts/lpc_dynamic_quest_guard.py：1 处 spread_quest() 调用（init_dynamic_quest() 的循环里）包进 catch()，缺失的任务物品或编译不过的房间只跳过那一个任务，守护进程照常加载、其余任务照常生成。 验证：quest/xunbao/npc/xunbaonpc.lpc和 cron 守护进程在新进程里加载（HEAD 一次，工作树三次，选房是随机的）：HEAD 通过 2 个，工作树三次分别通过 2、2、2 个（共 2 个），无回退。

深度功能测试（§10.7，2026-10-06）— 编译警告整理

scripts/lpc_warnings.py xlqy_early --fix：无用局部变量 2006 个、varargs 101 处、转义 10 处、裸 return 8 处、nosave 函数 18 个改 protected，共改动 974 个 .lpc 和若干 .h。scripts/lpc_fix_no_effect.py --apply：daemon/skill/xuanyuan-archery.lpc 的 practice_skill() 删去什么也不做的 (: throw_weapon :);，dns_master.lpc 把 #if PREF_* & SVC_TCP 移到 if 外面。 手工：d/shushan/npc/zhangmen.lpc kill_ob() 先找房间里的师父，然后 if (master) ; else {}（师父加入战斗那句早被注释掉了）；这段什么也不做，删去，留一行注释。 HEAD 与工作树分别加载（新进程）：952 -> 952 通过，无回退；改过的头文件的 401 个包含者 384 -> 384 通过。scripts/lpc_audit_removed_locals.py HEAD 的 18 条候选都是声明被重建或同名 efun。

启动时警告 123 -> 0；新进程登录（编码选择、新人物提问）正常。

• 2026-10-10：编译警告第二轮（按驱动报告逐条修）：按位 & 改逻辑运算 0 处，返回类型/原型 20 处，NPC+F_UNIQUE 的 init() 0 个，带初始化的未用局部变量 9 个，只在 #if 分支用的声明移进分支 0 个文件；改动 27 个文件，HEAD 与工作树各载入一次无回退（27 objects; HEAD PASS 27, tree PASS 27; regress 0; newly loading 0），这些文件的警告 51 -> 22。

• 2026-10-14：新驱动（FluffOS 970d9f09）报 Float value truncated to int（#1426）。17 个文件 39 处：赋值、初始化、return 改写成 to_int(...)（值不变，只是写明截断）。改动的对象新进程各载入一次，无回退（scripts/lpc_fix_float_trunc.py，KB 04 §6.10）。
• 2026-10-14（同一次重扫，手工部分）：

- d/dntg/yunlou/npc/yaoguai.lpc 灭妖奖励里的 reward 是倍率（0.8、1.2、1.8、2.6、3.8），却声明成 int，赋值时小数被丢掉，0.8 变成 0、1.8 变成 1。现改为 float，三项奖励用 to_int() 取整。玩家可见：七彩奖励按原设计的倍率发放。 - daemon/skill/dodge.lpc、parry.lpc 把基类 /std/skill 的 dodge_msg/parry_msg 再声明一次，结果基类那份一直是空的。现在改到 create() 里给基类那份赋值。 - manmade/npc/manmade_npc.lpc 自己的 tick 与 /std/char.lpc 心跳用的 tick 同名，两份本来就各数各的；改名 rzr_tick，行为不变。 - 其余与 wuhanzhan/hxxtjqb 同源的修法： - ground.h 加守卫； - jiasha.lpc 两个 init() 都调用； - colors.h 加防重复包含； - alias.lpc 的 last_time 改名 last_cmd_time； - yaoguai_type 重复声明去掉（含 yaoguai1.lpc）； - lijing/xiwangmu 的 die/unconcious 和 yutu 的 kill_ob 改 void； - 删去 reporting.lpc 各份未用的 str； - cmds/arch/make_npc.lpc 字符串里的 \#、\} 去掉反斜杠。 - 改动的 55 个对象 HEAD 与工作树各载入一次，无回退；原报警告的 54 个对象重编译后没有警告。

• 2026-10-14：2 个文件用了颜色宏（HIW、NOR）却没有 #include <ansi.h>（首个错误 syntax error, unexpected L_STRING）；开头补上（KB 04 §6.1、§6.3）。新进程比对 HEAD 与工作树：2 个对象，新增载入 2，回退 0。

内力/精力当作伤害种类（2026-10-15，KB 06 §7.241 第二类）

本库 feature/damage.lpc 的 receive_damage() 不接受 jingli/neili/force 等种类，me->receive_damage("jingli", 30) 之类在练功、绝招、吸取时报 F_DAMAGE: 伤害种类错误。2 处改为 add(type, -N)（scripts/lpc_fix_damage_calls.py 第二步）。

无门派玩家的 family 映射（2026-10-15，KB 05 §7.30 第三种）

mapping fam = ob->query("family"); 之后直接 fam["family_name"]：没有门派（新人或叛师后）的玩家在学习、练功、拜师、进入门派房间时报 Value being indexed is zero，而不是作者写好的提示。2 处在声明行加上 if (!mapp(fam)) fam = ([ ]);（scripts/lpc_fix_family_guard.py）。

转码吃掉的引号（2026-10-15，KB 03）

原档在右引号前有一个孤立的 GBK 前导字节，转 UTF-8 时连引号一起丢了（如 return name + HIM "发作身亡了;），字符串一直延续到后面，文件编译失败：/d/obj/books-nonskill/hmeng014。补回引号（scripts/lpc_fix_eaten_quote.py）。

iori-sword 取招越界（2026-10-15，KB 06 §7.243）

daemon/skill/iori-sword.lpc 只有 4 招却 action[random(7)]，改为文件里注释掉的 random(sizeof(action))（只有巫师区的测试 NPC 用到）。

空手使用兵器绝招（2026-10-15，KB 06 §7.246）

perform 指令允许直接点名招式（如 perform stick.ban），这些绝招读了 me->query_temp("weapon") 却从不检查，空手时 weapon->name() 报错（有的已先扣了内力）。在赋值后补 if (!objectp(weapon)) return notify_fail("你必须手持兵器才能使用这一招。\n");（scripts/lpc_fix_perform_weapon.py）：bainiao-jian/feijian、bainiao-jian/fengwu、bawang-qiang/qiangjian、bingpo-blade/ningxie、chixin-jian/haotan、dagou-bang/ban、dali-bang/shenli、fengbo-cha/fengbo、fumo-zhang/fuhu、ghostaxe/bianshen、ghostaxe/tiaozhan、hellfire-whip/lunhui 等 34 个。

技能名拼错（2026-10-15，KB 06 §7.249）

query_skill() 里的技能名拼错了，或用的是本库改名前的旧名；本库没有这个技能，调用永远得 0：门槛（< N 就拒绝）永远过不去，相关功夫或绝招学不了、用不了；内功互斥（> N 就拒绝）从不生效；公式里这一项一直是 0。经汉字名（提示文字或中文名词典）或纯拼写差异（_/-、少一个连字符、相邻字母颠倒）核对后，改为本库的技能名（scripts/lpc_fix_skill_typo.py）：pansi_dafa→pansi-dafa（/adm/daemons/family/pansi）；zuixian-steps→zuixiansteps（/d/shushan/npc/jiyin）。

技能名拼错：技能文件里拼错自己的名字（2026-10-15，KB 06 §7.249）

技能自己的文件（或它的绝招目录）里，query_skill() 读的是差一个字母的自己的名字，永远得 0：“基本功夫要高过本技能”之类的限制从不生效，按等级取招、计算伤害的那一项一直是 0。改为本技能的名字（scripts/lpc_fix_skill_typo.py 的 self 判据）：wanxi-spell→wanxi-spells（/daemon/conjure/dengxian-dafa/juanbi）。

用兵器的绝招空手施展时报错（内联写法）（2026-10-15，KB 06 §7.246）

绝招不存兵器变量，直接写 (me->query_temp("weapon"))->query("name")（或在拒绝判断里写 (weapon = me->query_temp("weapon"))->query("skill_type")），之前又没检查兵器：空手 perform 时报 Bad argument 1 to EFUN call_other()，内力等往往已经扣掉。在第一次用到它的那条语句前补上“你必须手持兵器才能使用这一招”的拒绝（scripts/lpc_fix_perform_weapon.py）：liangyi-sword/yin。

NPC 带着本库没有的物品，载入失败（2026-10-15，KB 06 §7.73）

11 个文件、15 处在 create() 里 carry_object("<本库没有的文件>")->wear()（或 wield()、set_amount()），多是从别的系统搬来的 NPC 用了原系统的物品路径（最常见：/d/city/npc/obj/choupao、/d/city/npc/obj/bingfu、/d/city/npc/obj/sengpao）。本库 NPC 基类 std/char/npc.lpc 的 carry_object() 第一句是 if (file->query_unique())，对不存在的文件直接 call_other，驱动在这里报 call_other() couldn't find object，new() 来不及返回 0，所以只要 NPC 带着一件本库没有的物品就载入不了（调用处加判断对它无效）。在它前面补 if (!objectp(load_object(file))) return 0;（--base），缺的物品就跳过，NPC 照常载入；上面那些调用处同样改成带判断的块（基类以后改回去也不怕）。载入检查：改动的文件改前能载入 1 个，改后 12 个（11 个原来载入不了），没有退步。

去掉的预定义宏 SAVE_EXTENSION（2026-10-18，KB 04 §6.11）

老版 MudOS 给每个 LPC 对象预先定义了 SAVE_EXTENSION（".o"）；FluffOS 的 ChangeLog（COMPAT_BUSTER 一条）把它删了，改用 __SAVE_EXTENSION__。本库没有自己 #define 这个宏，用到它的文件一律 Undefined variable 'SAVE_EXTENSION'，整个对象载入不了。改成 __SAVE_EXTENSION__（scripts/lpc_fix_predefined_macro.py）：adm/daemons/network/netmail.lpc。netmail 是网络邮件守护进程（本库缺 mailer.h 等头文件，改后仍载入不了）。改后用 lpcc 逐个载入这些对象：0 个通过，1 个还有别的错误（adm/daemons/network/netmail：/adm/daemons/network/netmail.lpc:18: error: Cannot #include mailer.h）。

d/moon/obj/poem 两句诗丢了收尾的引号（2026-10-18，KB 03 §4.6）

string *poem 数组里 "不放玉花飞堕地，留在广寒宫阙。, 和 "把酒送春春不语，黄昏却下潇潇雨。, 的收尾引号没了（转码时跟半个汉字一起丢了），下一行的开引号把字符串合上，后面的诗句成了代码：Illegal character 0xe6，整个物件载入不了。补回 ",。载入：通过。

d/shendian/obj/niepan 的收尾引号变成了私用字符（2026-10-18，KB 03 §4.6）

set("long", HIR"……五种符号<U+E4D4>NOR); 里本该是 " 的位置是一个私用区字符（转码时半个汉字加引号被换成了它），Illegal character 0xee，整个物件载入不了。换回 "。载入：通过。

set_skill() 遇到本库没有文件的武功不再抛错（2026-10-18，KB 06 §7.256）

feature/skill.lpc 里的 set_skill()、map_skill()、prepare_skill() 碰到没有武功文件的名字就 error("F_SKILL: No such skill (…)")，调用它们的 NPC create() 整个中断：NPC 载入不了，刷出它的房间也少一个人。本库有 2 个对象设了本库没有文件的武功（8 个名字，最多的是 eyesword、xuanzong-force、yuxu-spells）。三处都改成 return：这一门武功不给、不映射，对象照常载入，只是少了它（缺的武功本身仍是内容缺口）。抽样载入这些对象：2 个里 2 个通过。（scripts/lpc_guard_set_skill.py）

补回本库没有的基类文件（2026-10-18，KB 04 §6.15）

下面这些基类本库没有，继承它们的对象（房间、NPC、物品）整批载入不了（inherit XXX; 的宏没定义，或者 inherit "/std/…"; 的文件不在）。同系的库里有同名文件，两库有大量逐字节相同的文件（亲缘关系），所以从那边原样拷来，缺的宏补进全局头文件 include/globals.h：/std/weapon/unarmed（宏 UNARMED）←shenmo，1 个对象继承它，抽样 1/1 载入。每个基类补回后单独载入、再抽样载入使用它的对象，基类载不进来或者一个用户也载不进来的就撤掉（本库撤掉了它们，不再补）。（scripts/lpc_restore_bases.py）

武功名拼错的 NPC（2026-10-19，KB 06 §7.258）

set_skill("kunlun-shnfa", …)、map_skill("dodge", "shaolin-shnfa") 这样的调用把武功名拼错了：本库没有这个武功文件，有的是拼对的那个。以前这种 NPC 在 create() 里报 No such skill 载入不了；武功缺失时跳过之后它们能载入，可是少了那门武功（set_skill 被跳过，map_skill 映射不到，门派弟子用普通轻功/拳脚）。按核对过的对照表改正，共 23 处、22 个文件：dagonforce→dragonforce（6 处）、hellfire_whip→hellfire-whip（4 处）、lahua-shou→lanhua-shou（4 处）、yange_blade→yange-blade（2 处）、eyesword→eye-sword（2 处）、dragon-step→dragonstep（2 处）、moyunshou→moyun-shou（1 处）、changqaun→changquan（1 处）等共 9 个名字。（scripts/lpc_fix_skill_names.py）

调用了父类没有的函数的对象（2026-10-19，KB 06 §7.259）

::create();、::init();、return ::buy_object(who, item); 这类调用写的是父类里有这个函数的版本；本库的父类没有，旧驱动把它当空操作（返回 0），现在的驱动在编译时就报 Unable to find the inherited function，整个对象载入不了。单独成句的调用删掉，return ::f(...) 改成 return 0;（void 函数里是 return;），与旧驱动的行为一致。共 1 处、1 个文件：::buy_object()（1 处）。只改了出错原因全是这一类的文件；还带着别的错误（多半是父类本身没了）的文件没动，等父类补回后再看。（scripts/lpc_fix_dangling_super.py）

全局头文件丢了 1 个宏（2026-10-19，KB 04 §6.16）

/include/globals.h 里没有定义 WEAPON_OB，用到它们的物件（名单里 1 个）编译时报 Undefined variable/Undefined function，整个物件载入不了（编译器在第一个未定义的名字上停下，后面的错误和警告都看不到）。同系的库在各自的头文件里都有这几行：照其中和本库共有文件最多的那个库，原样补到 /include/globals.h 最后一个 #define 之后，宏体里出现的路径在本库里都存在。名单里的物件除了这几个宏之外还有别的错误，暂时仍载入不了。（scripts/lpc_restore_defines.py）

出口指向不存在的房间（2026-10-19，KB 06 §7.257）

下列房间的出口写的文件不存在，而对面恰好只有一个房间的出口指回本房间，所以按对面的房间改正（笔误、大小写、路径少了一级）：

• /d/qujing/wuji2/shandao3.lpc 的 west 出口：guankou → goukano
• /d/qujing/wuji2/shandao4.lpc 的 east 出口：guankou → goukano

改后房间照常载入（与 HEAD 逐个对比，没有退步），出口现在指向存在的房间。

RANK_D 对 0 的称呼（2026-10-19，KB 06 §7.273）

adm/daemons/rankd.lpc 的 query_respect()、query_rude()、query_self()、query_self_rude() 里 4 个函数开头补上 if (!objectp(ob)) ob = this_object();。NPC 在 create() 里写 "…" + RANK_D->query_respect(this_player()) + "…"（inquiry 对话、chat_msg），驱动自己跑 reset() 时没有人在场，this_player() 是 0。旧驱动里 0->query("age") 返回 0，称呼走默认分支；新驱动直接报 Bad argument 1 to EFUN call_other()，房间的 make_inventory() 吞掉错误，被打死的 NPC 再也刷新不回来。用 scripts/lpc_reach_census.py --walk 找到（xkx100 的武当弟子、一灯、汴梁书生…）；修在守护程序里，不动 1,800 个 NPC 文件。

补回丢失的标点，另一个版本的完好副本（2026-10-19，KB 03 §4.6 第四轮）

/d/jz/npc/jiang.lpc：set("daoxing", 1500000) 丢了分号；补回后载入，没有警告。完好副本在 dtxyzjb，只有文件头的署名注释不同，所以用 --diff --extra 补。

member_array('/', str) 改为 strsrch(str, "/")：字符字面量的 member_array 按字节搜索（2026-10-20，KB 06 §7.283）

member_array('/', str) 里的 '/' 是整数，驱动按 UTF-8 字节搜索，返回字节偏移（带第三个参数时起点也是字节）；最新的 FluffOS（923cdbc0）在字符串里有非 ASCII 文字时，对每个调用点警告一次（Warning: member_array(int, string) searches BYTES）。而 str[0..idx-1] 按字符切，中文字符串会在错误的位置截断。改为 strsrch(str, "/")（找不到同样返回 -1，按字符计数；scripts/lpc_fix_member_array_char.py，JSON 编码器等少数几处手改）。改动：/adm/daemons/vrm_server.lpc（1 处）。

call_out_info() 的每一项只有 3 个元素（2026-10-20，KB 06 §7.287）

驱动返回的是 ({ 物件, 函数, 延迟 })，不带 call_out 的参数，旧代码读第 4 项 info[i][3]（callouts 指令、calloutd、cod 工具）一读就报 Array index out of bounds，指令从第一行起什么也打印不出来。改为 (sizeof(info[i]) > 3 ? info[i][3] : 0)（scripts/lpc_fix_callout_info.py）。改动：/cmds/arch/callouts.lpc（1 处）、/cmds/wiz/callouts.lpc（1 处）。

浩劫系统 verdict_time()：领头玩家已经离线时 lead->name() 报错，戒严不解除（2026-10-20）

三十分钟后收场时 lead（接战书的玩家）若已退出游戏就是 0，lead->name() 在宣布战果的 message() 里报错，后面的 LOGIN_D->set_madlock(0) 不再执行，戒严一直保持，quit 指令因此对所有人关闭。改为 (lead ? lead->name() : "各派豪杰")。改动：/feature/disaster.lpc（2 处）。

if (x = 常量)：条件里写成赋值的比较（2026-10-20，KB 06 §7.290）

if (arg = "button" || arg = "按钮")、if (!arg || arg = "") return 0;、else if (check = 0 && tempB != "")：把 == 写成了 =，条件的值就是那个常量，分支对所有非零数和任何字符串（连 "" 都算）永远成立、对 0 永远不成立，变量还被覆盖；驱动对此没有任何警告。每一处 = 改成 ==（scripts/lpc_fix_cond_assign.py，共 14 处）。改动：/cmds/wiz/dns.lpc（1 处）、/d/city/mjlady3.lpc（3 处）、/d/shendian/babu/obj/longzhua.lpc（4 处）、/daemon/skill/pfm/NO.1_skill/fengyun.lpc（3 处）、/daemon/skill/pfm/NO.1_skill/lmsj.lpc（3 处）。

callouts：sizeof(info[i]) == 4 把每一行都挡掉了（2026-10-20，KB 06 §7.287）

驱动的 call_out_info() 每项只有 3 个元素，输出行前的守卫 if (sizeof(info[i]) == 4) 永远不成立，指令只打印表头。改为 >= 3。改动：/cmds/arch/callouts.lpc（1 处）、/cmds/wiz/callouts.lpc（1 处）。

socket / dumpsocket 指令：dump_socket_status() 驱动里没有（2026-10-20，KB 06 §7.291）

这些巫师指令 write(dump_socket_status());，MudOS 的 efun 在 FluffOS 里不存在，指令编译不过。在模拟 efun 文件里补了 dump_socket_status()：用 socket_status() 排出同样的表（没有 sockets 包的构建，比如 WASM，只有表头；scripts/lpc_add_sefun.py dump_socket_status）。

登录密码超过 255 字节：crypt() 抛错（2026-10-20，KB 06 §7.294）

驱动的 crypt() 对超过 255 字节的密钥直接报错（Error in crypt(), check your salt），老驱动则按任意长度散列。在登录提示符下输入 256 字节以上的密码，密码检查那一行就抛错，连线停在一个裸的 > 提示符上，登录走不完（password 指令的旧密码检查同样）；用 300 个 x 当参数的扫描发现的。/adm/obj/simul_efun.lpc 里补了一个同名的 simul_efun crypt(key, salt)：只有超长的密钥才被截短（先截到 255 个字符，再逐字符截到 sizeof(to_buffer(key)) <= 255，限制按字节算，一个汉字占三个字节），再交给 efun::crypt()；普通密码原样散列，已存的密码散列不受影响（scripts/lpc_add_sefun.py crypt）。

sefun cat()：缺文件时 write(0) 报错（2026-10-20，KB 06 §7.297）

void cat(string file) { write(read_file(file)); }：文件不存在（压缩包没带的欢迎/公告文件，或只有运行中的 mud 才会写的日志）时 read_file() 回 0，write(0) 在本驱动里报 Bad argument 1 to receive()，调用者（登录对话、cat 指令）被中断；老驱动什么也不打印。改成 write(read_file(file) || "");（scripts/lpc_fix_cat_unchecked.py）。改动：/adm/simul_efun/file.lpc。

NPC 的 chat() 在 chat_msg 为空数组时下标越界（2026-10-21，KB 06 §7.334）

NPC 基类的 chat() 是 if (arrayp(msg = query(...))) { if (random(100) < chance) { rnd = random(sizeof(msg)); if (stringp(msg[rnd])) ...，不检查列表是否为空。本库现有的 NPC 文件里没有字面写成空 chat_msg 的（扫描只认 set("chat_msg", ({ }))）；守卫挡的是运行时才为空的列表和以后新增的 NPC。在 random(100) < chance 前面加 sizeof(msg) &&（scripts/lpc_fix_chat_empty.py；if (random(100) > chance) return 0; 的写法是 !sizeof(msg) ||）。改动：/std/char/jobnpc.lpc、/std/char/npc.lpc（共 2 个文件）。

巫师命令不带参数时对 0 调用 efun（2026-10-21，KB 06 §7.336）

巫师（管理员）把命令敲成不带参数时，驱动把 0 传给字符串参数；下面的命令第一句就把这个 0 交给 efun，运行时报 Bad argument 1 to ...，这条指令从来没有用过。用 scripts/lpcc_bare.py 不登录、在一次 lpcc 求值里以 0 调用 main() 逐个确认后，由 scripts/lpc_fix_bare_arg.py 在第一处使用参数的语句前加守卫：文件自带 int help(object me) 的，守卫是 if (!arg) return help(me);（help() 定义在 main() 之后的 1 个文件补了原型 int help(object me);，否则编译报 Undefined function help）。改动（1 个文件，括号里是接住 0 的 efun）：/cmds/adm/dumpprog.lpc（new）。加载检查 HEAD 与工作树对照，没有退步。

观礼台 d/city/under.lpc：wait_and_start() 里的 fan 没赋值，比武开不了（2026-10-21，KB 06 §7.346）

接受挑战（defend）两秒后 wait_and_start() 调用 fan->command("chat ...比武开始")，object fan; 声明了却没有 fan = load_object(__DIR__ "npc/fan");（dtxywzxzb 的同一份文件有），抛错之后两条 kill 和 call_out("finish_match", 300) 都不执行，比赛不开始。补上这一句（npc/fan.lpc、ground.lpc 本库都有）。

拼错的 call_out() / input_to() 目标（KB 06 §7.349，2026-10-21）

计时器或输入提示给驱动的函数名和文件里定义的差一个字母；驱动对不存在的函数静默不理，所以对应的计时从来没有触发过。调用和配套的 remove_call_out() 改成已定义的拼法：find_seal：disapprear → disappear（法术产生的封印十分钟后从不消失）。改动：/d/jjf/obj/find_seal.lpc。

注册到不存在函数的 add_action（2026-10-21，KB 06 §7.349）

add_action("函数", "动词") 绑定的函数，在对象本身、它包含的头文件、它继承的父类和继承它的子类里都没有定义（scripts/lpc_scan_callout_targets.py 静态解析，子类用传递闭包复核，scripts/lpc_verify_handlers.py 运行时 function_exists() 复核）。驱动从玩家最新的一条动作往回找，遇到这样的句子就报 *Function for verb 'drop' not found.，同一个动词的其他处理函数不再尝试（不是最新的一条就悄悄跳过）。删除了 22 条注册（15 个文件，scripts/lpc_fix_dead_add_action.py），动词留给别的处理函数：/d/changan/pinqiting.lpc（do_pass、do_resign）、/d/city/npc/doctor.lpc（do_block）、/d/city/npc/duguoyin.lpc（do_vendor_list）、/d/city/npc/guan.lpc（do_improve）、/d/eastway/npc/petboss.lpc（do_cost、do_list、do_upgrade）、/d/eastway/petboss.lpc（do_cost、do_list、do_upgrade）、/d/jjf/npc/baifalaoren.lpc（do_improve）、/d/jjf/npc/luocheng.lpc（do_improve）、/d/lingtai/npc/puti.lpc（do_improve）、/d/pansi/npc/qingxia.lpc（do_yes） 等共 15 个文件。最多的函数名：do_improve 4 处、do_bian 3 处、do_cost 2 处、do_list 2 处、do_upgrade 2 处。

(: 函数 :) 指针指向对象自己没有定义的函数（2026-10-22，KB 06 §7.355）

item_desc / inquiry / chat_msg_combat 里的 (: 函数名 :) 指向本对象（含包含文件、继承的父类）没有函数体的函数：编译不报错，用到时驱动报 *Undefined lfun pointer called: 函数名（look 某物、ask NPC about 话题 直接出错，战斗 / 闲聊里的指针在 NPC 的 chat() 里出错，这一拍心跳的后半段被跳过）。scripts/lpc_scan_callout_targets.py --kinds=lfun。 还剩 2 个函数没有补（inquiry 1, chat_msg_combat 1）：原型还在函数体丢了、或者根本没写过，没有可以直接补回的捐赠（别的库同一路径的文件里没有这个函数，或者它还要用本库没有的辅助函数、签名不同），不编造：/d/quest/dajiu/jiangziya_bak.lpc:ask_jianxi、/d/xueshan/obj/hufabird.lpc:saysth。

汉字按字节切片的老写法没有换成按字符：改法名 "澄" + name[2..3]、辈分判断 name[0..1] == "澄" 等 2 处（2026-10-22，KB 06 §7.360）

原档按字节算字符串区间（一个汉字 2 字节）：name[2..3] 是名字的第二个字，name[0..1] == "澄" 问名字是不是以「澄」开头。转成 UTF-8 之后，这个驱动的区间和 strlen() 都按字符算（strlen("澄观") 是 2，"澄观"[0..1] 是两个字），老算术原样留着、意思全变：拜入少林 / 武当 / 峨嵋等派的玩家被改成错误的法名（二字名 张三 变成一个字的 澄，更长的名字取到第三个字）。

本库 2 处（1 个文件）：拼名字的赋值 2 处。例：name[0..1] → name[0..0]（/d/nanhai/npc/tidu.lpc:117）。scripts/lpc_fix_gbk_slice.py 把下标按字符重算（社区的 UTF-8 版 xkx100utf8 里就是同样的写法，作对照）；没有改的：截断（name = name[0..7]，现在最多 8 个字，只是放宽）、ASCII 的区间（fname[0..3] == "room"、ctime(time())[4..19]）和上下文看不出是汉字的区间。证明（scripts/lpcc_eval.py，bixiecanyang；其余各库是同一份文本）：让澄字辈掌门 attempt_apprentice() 一个名叫「张三」的访客，HEAD 的法名是 慧，改后是 慧三；抽样 28 个库的 HEAD / 工作树加载对比 0 退步。工具不幂等（[0..3] 折半得 [0..1]，又是对齐区间），改过的文件记在 scripts/gbk_slice_converted.txt，不要重跑。

长度检查按字节写，旁边的提示按汉字写：2 处（2026-10-22，KB 06 §7.362）

老档的 strlen() 数字节（一个汉字 2 字节），转成 UTF-8 后它数字符：提示写「必须是 2 到 6 个中文字」的检查还是 strlen(name) < 4 || strlen(name) > 12，于是两三个字的房名、帮会名、群名、聊天室名、称号被提示自己说允许的那句话拒绝，上限却是提示的两倍；留言板的标题检查 i < 4 || i > 24 || i % 2 还会拒绝所有奇数个字的标题（post 你好吗）。本库 2 处（1 个文件）：if ((strlen(name) < 2) || (strlen(name) > 12)) {（/d/city/npc/zhangsunwuji.lpc:164）。scripts/lpc_fix_strlen_gate.py 以提示为准：条件里每个 strlen 门槛都恰是提示所说数字的两倍才折半，存长度的变量（i = strlen(arg);）的门槛和 || i % 2 奇偶项、其后循环的 i % 2 == 0 && 一并处理；提示里有英文 / 字母 / 字节的不动。证明（scripts/lpcc_eval.py，bxsj 的留言板，求值对象继承 NPC 并重写 edit() 记录调用，command("post 标题")）：HEAD 拒绝「你好」和「你好吗」、放行 23 个字的标题；改后接受前两个、拒绝第三个；shenmo 的 named.lpc invalid_new_name("张三")：HEAD 回 名字只能是2-4个中文字。，改后回 0。抽样 24 + 15 个库的 HEAD / 工作树加载对比 0 退步。

按字节写的汉字循环、茶馆猜诗和同盟频道标题（2026-10-23，KB 06 §7.363）

老档按字节做「一个汉字」：while (i--) if (i % 2 == 0 && !is_chinese(name[i..<0])) 只检查偶数下标，奇数位上的拉丁字母（张a）会过；茶馆猜诗 mixup() 用 strlen(str)/2 再 j=j+j、str[k..k+1] 交换两字节；泥潭系 channeld 的 switch (strlen(fname)) case 4/6/8/10 和 strlen(family)==4/6 按字节长度给同盟 / 门派名加空格。本驱动的 strlen() 和区间都按字符算。scripts/lpc_fix_byte_char.py：去掉奇偶项、把区间改成 name[i..i]，按字符重写 mixup() 并把 strlen(first)>=14 折成 7，频道标题的 case / 门派长度改成字符数（对照 aoxiangtianji）。本库 汉字循环 / is_chinese 区间 7 个文件；茶馆猜诗 mixup 1 个文件。证明（scripts/lpcc_eval.py）：sjplii 的 check_legal_name 在 HEAD 接受「张a」、改后拒绝，两边都接受「张三」；xkx100 的 clubpoem->mixup("离离原上草") 得到「离离原草上」（真交换汉字）；nitan_san 两字同盟名得到 【 兄 弟 】。关键对象加载通过。

血条 / 表情标题按字节算显示宽度（2026-10-23，KB 06 §7.365）

老档把汉字当两字节：bar_string[0..(val * N / max) * 2 - 1] 把「格数」换成字节下标，半格血条在本驱动（按字符算区间）上会整条画满；巫师表情 edemote 的 repeat_string("─", 13 - (strlen(emotion) / 2)) 也会少减汉字宽度。scripts/lpc_fix_display_pad.py：去掉 CJK 血条 / 空白条上的 * 2（jings/qis 赋值和 blank_string3[0..(23-a)] 的 23→11 一并改），表情标题去掉 / 2；ASCII 空格的 none_string / empty_string 仍保留 * 2（一格两个空格）。本库 14 处（7 个文件）。证明（lpcc_eval.py hhsj）：tribar_graph(6,9,12) 在 HEAD 画出整条 12 个■，改后为 6 个■+3 个□；麻将 strlen(tempB)/2 是两字符牌码，未改。

巫师区出口 faceoff / rence / niulang / yihua（2026-10-23，KB 06 §7.372）

/u/f/faceoff/、/u/r/rence/、/u/onskyer/niulang/、/u/skinys/yihua/ 对应区域已在 /open/world1/faceoff/bird/、/open/prayer/、/d/niulang/、/d/yihua/。scripts/lpc_fix_wizard_area_exits.py 在目标存在时改写，仍缺失的出口行删除。本库 4 处。证明：dreamofseven wood5 四向可加载；xlqy_new2007 天河东西向 niulang；kxkj kitchen7 → prayer。

家丁 CLOTH_OB()/WEAPON_OB() 调用式宏（2026-10-27，KB 04 §6.16 Also）

d/wuguan/npc/jiading.lpc（及 jiading1，xlqy 系在 d/dntg/hgs/wuguan/npc/）写 carry_object(CLOTH_OB("cloth")) / WEAPON_OB("changjian")：库中没有带参的 CLOTH_OB，WEAPON_OB 在 globals.h 只是裸路径 "/d/obj/weapon/"，展开成 "/d/obj/weapon/"("changjian") 语法错误，NPC 无程序。同目录其它 NPC 用 __DIR__ "obj/cloth"；剑在 /d/obj/weapon/sword/changjian。改成这两条（目标文件均在树内）。证明：HEAD Undefined function CLOTH_OB；改后 new() 成功且 inventory 为 2。

黑风山 pusa1 用未声明的 ob 且函数外残留 call_out（2026-10-27，KB 06 §7.348 Also）

d/qujing/heifeng/npc/pusa1.lpc 的 announce_success(object who) 写成 if (!ob->query("obstacle/hf"))（Undefined variable 'ob'），同目录 pusa.lpc 是 who->query("obstacle/hf") == "done"；who->save(); } 之后还残留 call_out("die"...); return; }，落在函数外（unexpected L_STRING），对象无程序。改成与 pusa 相同的门，并删掉残留语句。证明：HEAD 加载失败；改后加载成功。

雪山 obj/hufabird set_level 缺 }（2026-10-27，KB 04 §6.28 Also）

d/xueshan/obj/hufabird.lpc 的 set_level 在 setup(); 后少了一个 }，后面的 int heal_up() / leave / invocation / die 都嵌进了 set_level（unexpected '('），对象无程序；同目录 npc/hufabird.lpc 正常关闭。顺带：messege_vision→message_vision，return : die()→return ::die()，以及无 saysth 的 (: saysth :) 按 7.355 注释掉。证明：HEAD 加载失败；改后加载成功。

洗衣盆 is_container 映射缺值编不过（2026-10-27，KB 04 §6.28 Also）

d/gao/obj/pen.lpc（或 d/qujing/gao/obj/pen）的 is_container() 写成 set("objects", ([ "/u/bula/gao/obj/kaoji" ]));：映射只有键没有值（unexpected ']'），对象无程序。同族 hy5 / xyj2000 已把该函数注释掉。改成标准的 return 1;。证明：HEAD 加载失败；改后加载成功。

月宫 quest/road 模板缺 index（2026-10-27，KB 06 §7.348 Also）

d/moon/quest/road.lpc（及误放在 npc/road.lpc 的副本）出口写 sprintf("%d", index ± 1)，却没有像 road1…road10 那样声明 int index = N;（Undefined variable 'index'），对象无程序。补上 int index = 5;（中间段，东西出口都能落到已有房间）。证明：HEAD 加载失败；改后加载成功。

星君/罗汉模板缺 ID 宏（2026-10-27，KB 06 §7.348 Also）

d/dntg/sky/stars/star.lpc 与 d/nanhai/luohan/npc/luohan.lpc 用 title[ID] / first_name[ID]，真正带号的副本是 #define ID N 再 #include 本文件；单独编译模板时 Undefined variable 'ID'。加 #ifndef ID / #define ID 0 / #endif，带号 include 仍用各自的 N。证明：HEAD 模板加载失败；改后模板与 stars/5、luohan5 均加载成功。

雷神 check 在 stop_fight 定义之前调用且 call_out 缺逗号（2026-10-27，KB 04 §6.28 Also）

d/qujing/start/24/1.lpc 的 check() 里调用 stop_fight(who)，函数却写在后面（Undefined function stop_fight）；call_out("lost", 1 who) 少了逗号（unexpected L_DEFINED_NAME）。把 stop_fight 挪到 check 之前，并改成 call_out("lost", 1, who)。证明：HEAD 加载失败；改后加载成功。

悬空 ::init / unique::init（2026-10-27，KB 06 §7.259 Also）

kugu-1/2/3、kunxian-suo 写 ::init();，tianyi 写 unique::init();，而 F_UNIQUE / ITEM / feature/unique 没有 init；本驱动编译报 Unable to find the inherited function 'init'（tianyi 带 in file 'unique'），物件无法加载。老驱动把空父调用当返回 0。lpc_fix_dangling_super.py 删掉这些语句；cloth::init() 保留。证明：HEAD 加载失败；改后加载成功。

dami 误调 init_unarmed（2026-10-27，KB 04 §6.25 Also）

d/obj/food/dami.lpc 继承 ITEM+F_FOOD 却调用 init_unarmed(5)（并 #include <weapon.h>），未继承空手兵器基类，驱动报 Undefined function init_unarmed。手足 hymud 已注释该行。删掉该调用与无用的 weapon 头。证明：HEAD 加载失败；改后加载成功。

深度功能测试（2026-10-27，§6.25 tell_object 参数顺序）

tell_object("…", me/who) 参数颠倒（消息当对象）；改为 tell_object(me/who, "…")（guest.lpc）。证明：残渣 0；抽样 guest/rukou/forest_c 加载。

深度功能测试（2026-10-27，§6.25 tell_object 缺 me（自动放弃/愿否））

一参 tell_object("…") 在已有 me 时改为 tell_object(me, "…")（city.lpc）。证明：抽样 city / xiaolongnv 加载。

深度功能测试（2026-10-27，§6.25 tell_object 路径当房间）

tell_object("/…", …) → tell_room(load_object("/…"), …)（去掉 .lpc）。

深度功能测试（2026-10-27，§6.25 one-arg message_vision）

message_vision("…") 补第二参（me / TP / this_player()）。

深度功能测试（2026-10-27，§6.10 未知 pragma save_binary/optimize）

删除本库中 FluffOS 不认的 #pragma save_binary / #pragma optimize… 行。