esI.rar → esI

• Archive: archives/esI.rar (10.2MB — "东方故事"/"Eastern Story", themed "屠龙之战"/"Dragon Slaying War" per the live banner; up since May 2001 per its own credits). Same 东方故事 lineage as archive #12 (es1_win), different snapshot/branch.
• Mudlib root: esI/ at archive top level. Config at top-level config.cfg.
• Port: 40010.

Status: DONE — boots clean, playable over telnet

Full flow confirmed: banner, staff/admin credits, uptime status, name-length validation, name-not-taken confirmation prompt.

What was fixed

Applied both fixes discovered on lib #12 (same lineage) proactively, before the first boot attempt, since a quick grep confirmed both patterns present in the raw archive: 1. std/object/prop.lpc's #include </std/object/prop_logic.c> (angle brackets, local directory, reached via preload) — convert_lib.sh's automated .c>→.lpc> fix only fixes the extension, not the bracket-vs-quote distinction, so this still needed the manual switch to quotes (#include "/std/object/prop_logic.lpc") per AGENTS.md §8d's preload-timing addendum. Worth teaching convert_lib.sh to convert local angle-bracket #includes to quotes automatically the next time this pattern recurs in enough libs to justify it (seen twice now). 2. master.lpc's domain_file() — same explode("/", "/") returning a zero-length array, !path guard not catching it — added || !sizeof(path).

Both fixes applied before ever attempting a boot; booted clean on the first real attempt. Plus the routine per-lib steps: encoding (8471 converted, 1741 already UTF-8/ASCII, 107 skipped binary, 14 lossy), .c→.lpc (7035 files, 1009 refs + 1 angle-bracket ref auto-fixed), static→nosave (121 files).

Known remaining issues (documented, not fixed)

• 1195 lpcc-sweep failures (of 7035) — not triaged past confirming the lib boots and plays; given the time budget across ~90 remaining archives, not chasing every failure category individually this time (same call as es1_win's NOTES.md documents for its own long tail).

How to run

cd libs/esI
~/src/fluffos/build-debug/src/driver config.fluffos
python3 ../../scripts/mudclient.py 127.0.0.1 40010 --timeout 10 --send "" --send "look" --send "quit"

Re-verification pass: driver rebuild + LPC formatter + WASM build

• Formatter: format-corpus.mjs over all 7035 .lpc files; 6986 reformatted, 5 unchanged, 44 refused (self-check errors, expected).
• Native retest against rebuilt driver — 2 regressions found + fixed (both pre-existing gaps from before this pass, only surfaced now by actually running look/score/quit to completion rather than just confirming boot + registration): 1. Same stray debug write("aadsaaaaaaaaaaaaaaaaaaaa\n\n") in std/user.lpc's setup() as es1_win (same lineage/root cause, absent from raw/) — deleted. 2. quit crashed with *Inherited file '/std/room' does not exist! the first time, then *No program in object '/d/std/IRC/lobby'! after a partial fix — both trace back to the same §8d get_include_path() gap: this lib's TODO.md entry claims "both known fixes applied proactively" (referring to es1_win's §8d fix), but adm/obj/master.lpc was actually *missing* get_include_path() — only es1_win's copy has it. Two symptoms stacked: (a) include/globals.h's ROOM macro is stale ("/std/room", real file is std/room/room.lpc) while include/mudlib.h's is correct ("/std/room/room") — files that #include <mudlib.h> are fine, files relying only on the auto-included globals.h (e.g. logoutd.lpc's room lookups) got the wrong path; fixed by correcting globals.h's value to match mudlib.h (single point, matches the pattern of every other macro in that file). (b) once that was fixed, d/std/IRC/lobby.lpc (lazily compiled mid-connection during logoutd's post-quit cleanup, not during preload) still failed with Cannot #include irc.h — the exact §8d/§15o symptom (angle-bracket same-dir #include needs master.lpc's get_include_path() for compiles triggered live, not preload/bare-lpcc); fixed by adding the standard get_include_path() shape to master.lpc (identical to es1_win's). Re-verified: full registration + look/score/ quit all clean, zero debug.log errors, with two separate real Chinese names (乔峰, 阿朱).
• WASM test: boots cleanly (only the expected non-fatal Undefined function socket_create et al. in /adm/daemons/network/cmwhod.lpc during preload, and the same cmwhod-related *No program in object at quit-time cleanup — both are the documented "no sockets package under WASM" limitation, caught by the existing error handling, non-cascading). Full registration with a real Chinese name (慕容), look, and quit all worked end-to-end — this lib's IP-check is non-blocking, so it is unaffected by the documented query_ip_number() WASM limitation.

WASM-enablement pass (loopback / admin seeding)

Identical to sibling es1_win (ES II family, 008).

• Loopback ban bypass (§1.3b): adm/daemons/banish.lpc check_banned_site() (~line 75) — short-circuit at top for loopback / empty / non-string / localhost / 127. names (returns 0). Gate is fed query_ip_name(), called from logind.lpc:242 and :577.
• Uptime gate: none rejecting. logind.lpc:87 uptime()<43200 only grants extra user slots (content, kept).
• Anti-flood throttle: none (per-session password retry cap only).
• Admin account (§1.5): fluffos / Mud@2026, display 浮浮. Added to (root)+(admin) in /adm/etc/groups; wizard 1 + domains (archwizard) in data/std/connection/f/fluffos.o. Verified update /adm/daemons/statsd loads OK.
• Fail-closed retrofit (2026-07-24 security correction): the loopback check(s) above originally also treated an empty/non-string IP as loopback (defensive fallback for the then-broken query_ip_number()). Since the driver's IP-reporting bug is now fixed upstream (WASM reports a clean 127.0.0.1 like native), that fallback was removed — loopback is now strictly stringp(ip) && (ip=="127.0.0.1" || ip=="::1" || ip[0..3]=="127."); anything unparseable/empty is untrusted/remote and goes through the original gate logic. Retested: fluffos login + look/quit still clean over loopback.
• Save files to force-add (untracked, NOT gitignored): libs/esI/work/data/std/connection/f/fluffos.o, libs/esI/work/data/std/user_ob/human/f/fluffos.o.

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

Round-two pass (AGENTS.md §10.7) on the native driver, one continuous session per checklist item, with several deliberate net-dead disconnect/reconnect probes (both prompt and after a real ~80s wall-clock wait) plus a fresh-boot verification of every fix. Test characters (both kept, not cleaned up, as evidence):

• Jiangfeng / 江枫 (id jiangfeng), password TestPass456, human male adventurer. Primary walkthrough character: registered, trained unarmed via guild train, explored 远风镇, confirmed join at an already-joined guild replies correctly, quit cleanly. Currently parked in /d/adventurer/hall/adv_guild after a clean quit. Save: work/data/std/user_ob/human/j/jiangfeng.o.
• Muyunhe / 穆云鹤 (id muyunhe), password TestPassZ7, female elf adventurer. Created specifically to reproduce the net-dead-during- registration bug (disconnected at the "[请按 RETURN 键继续]" prompt, before ever being placed in a room) — see bug #1 below. Also used for the full combat/shop pass: fought a level-1 野狗(dog) at 远风镇西门 for 40+ real combat rounds (no crash; both combatants have very low hit chance so it never concluded — fled cleanly with east), admin-granted 50 gold + 50 silver coins (see "Not verified live"), bought a torch for 5 silver at /d/noden/farwind/shop, confirmed wield torch correctly rejects a non-weapon, quit cleanly. Currently parked in /d/adventurer/hall/adv_guild. Save: work/data/std/user_ob/elf/m/muyunhe.o.

Ported from sibling es1_win (§11 lineage, byte-identical files confirmed via diff before porting)

Both fixes below were previously found+fixed on es1_win's own §10.7 pass and explicitly flagged there as "sibling esI has byte-identical unfixed copies of both files". Confirmed via diff against es1_win's pre-fix commit (92be845f197^) that esI's copies were indeed byte-identical (module trivial pragma/comment differences), ported the same fix, and live-verified both work on esI specifically.

1. Net-dead disconnect during registration permanently strands the account (§7.21 variant) — std/user.lpc restart_heart(). Same root cause as es1_win: net_dead() only records linkdead_room if (env), so a player who disconnects between finishing the registration Q&A and pressing RETURN at the MOTD prompt (i.e. before complete_setup() ever places them in a room) has no linkdead_room to restore and gets stuck in LINKDEAD_ROOM forever on every future login. Fix ported verbatim: in restart_heart(), when linkroom is unset but the player is currently sitting in LINKDEAD_ROOM, call this_object()->complete_setup("") to finish the interrupted setup. Live-verified on esI: registered Muyunhe through to the "[请按 RETURN 键继续]" prompt, let the connection close without answering it, reconnected with the correct password — landed correctly in /d/adventurer/hall/adv_guild (the real start room), not /d/std/rooms/netdead. look/score both correct, zero debug.log signal either before or after the fix (matches §7.20's "zero log signal" warning).

2. #include <compress_obj.h>'s set_default_ob(__FILE__) — §7.14 class. __FILE__ inside the pasted-in fragment always resolves to /include/compress_obj.h itself, not whichever of the ~40 objects it was pasted into, so every affected clone's fallback property lookup throws *call_other() couldn't find object '/include/compress_obj.h' the first time it's needed (e.g. a shop's list command reading an item's price). Fix ported verbatim: base_name(this_object()) instead of __FILE__. Live-verified on esI: pre-fix, walking into /d/noden/farwind/shop and typing list (or the room's own first-ever reset(), see bug #4 below) would have hit this on the very first item lookup; post-fix, list renders the full item list with prices cleanly (油灯/绷带/魔法地图/火把), and a real purchase (buy torch) completed without error (see "What was tested" below).

New bugs found on esI (not present/not reproduced on es1_win)

3. Leftover developer debug checkpoints printed to every player on every real login — adm/daemons/logind.lpc (~line 477-490). Five tell_object(player, "ttt\n") / "ttt1\n" / ... "ttt4\n" calls, interleaved between the real ENTER_D/TOPPLAYER_D login-chain calls, unconditionally print literal ttt/ttt1/ttt2/ttt3/ttt4 lines to every player's screen on every ordinary login (confirmed reproducible — not the net-dead-reconnect path, which goes through restart_heart() instead and doesn't show them). Confirmed present in the raw archive (/bin/grep -a ttt raw/esI/adm/daemons/logind.c — same 5 lines, byte-identical), i.e. original author debug instrumentation that was never cleaned up before this snapshot shipped, not a conversion artifact. Same class as this lib's own already-documented "aadsaaaaaaaaaaaaaaaaaaaa" stray-debug-string bug (see "Native retest" section above) — zero player-facing content value, unambiguously leftover instrumentation, not a game-content/design question. Not present on es1_win (grep ttt es1_win/.../logind.lpc — zero hits; this snapshot's own addition, so no sibling port needed in that direction). Fix: deleted the 5 tell_object() lines, kept the 5 original comments and the real calls they were checkpointing. Verified: re-logged in as both Jiangfeng and Muyunhe post-fix — no more ttt* lines anywhere in the transcript, login chain output otherwise unchanged.

4. Uncatchable eval-cost abort on a room's cold first compile — another instance of §7.22's general shape, config-level fix — the farwind shop's reset(). /d/noden/farwind/shop.lpc's create() calls reset() synchronously (this shop's own explicit choice, matching a lib-wide convention — 1553 files across the tree call reset() directly from create(), not just relying on the inherited std/room/room.lpc's async call_out("reset", 0)). On this snapshot's shop, that synchronous reset() populates FOUR objects on the room's very first compile, one of which — "woodman": "/d/zeq/woodman" — is a heavily-decorated level-19 guard NPC (85350 HP) that equips 10 armor pieces plus a weapon in its own create(), each an independent first-time compile+clone. On a fresh boot, the FIRST player to walk east into the shop hit a real, on-screen, cascading crash:

执行时段错误：*Too long evaluation. Execution aborted.
程式：/adm/obj/master.lpc 第 349 行
...
呼叫来自：/d/noden/farwind/shop.lpc 的 create() 第 35 行，物件： /d/noden/farwind/shop
呼叫来自：/std/room/room.lpc 的 reset() 第 47 行 ...

cascading into log_error()/domain_file() themselves (each hitting the SAME already-exhausted eval budget as soon as execution resumed), ending in *Can't catch eval cost too big error. The player's move() into the shop simply failed (they stayed in the previous room — not left environment-null, unlike §7.22's original START_ROOM instance), but the crash is loud and repeats identically every time the shop's FIRST-ever visit this boot is attempted. Confirmed first-visit-only: after the aborted attempt, east a second time succeeded cleanly (shop and all 4 NPCs already resident in memory from the partial first attempt). Root cause confirmed by direct test, not guesswork: rebooting with maximum evaluation cost raised from the shipped 300000 to 5000000 and repeating the exact same fresh-boot east into the shop now succeeds cleanly with zero errors — i.e. this is genuinely "legitimately a lot of synchronous first-load work", not an infinite loop. Worth noting the archive's OWN config comment (config.fluffos:72-73, "Because of the heavy load on the Power PC, made it larger to pass the bad time. (By Annihilator)") shows the original author already had to raise this exact value once, on their own era's hardware, for what is plausibly this same class of problem. 5000000 is also already the single most common maximum evaluation cost value across this project's other converted libs (30 of them, per grep -rh "^maximum evaluation cost" libs/*/config.fluffos), so this is a precedented, low-risk config fix, not a one-off value pulled from nowhere. Fix: libs/esI/config.fluffos, maximum evaluation cost : 300000 → 5000000. Live-verified: fresh reboot, fresh character, east into the shop on the very first attempt this boot succeeds cleanly (全部 4 只 NPC 正确显示), zero debug.log errors.

5. §7.12 tell_room() 2-arg wrapper bug — adm/simul_efun/tell_room.lpc, hit from a self-rescheduling call_out with no enclosing catch() (the severity-escalation shape, not just cosmetic). varargs void tell_room(mixed room, mixed msg, mixed exclude) passes exclude straight through to the real message() efun; called with only 2 args (the overwhelmingly common case throughout this lib), exclude defaults to int 0, which message() rejects (Bad argument 4 to EFUN message() Expected: object, array, Got: int(0)). Reproduced live: adm/daemons/weather_d.lpc's change_phase() — a self-rescheduling call_out ("it call_outs to itself recursively so there's always one version in the call_out queue", per the file's own comment) — calls tell_room(notifications[i], msg) with only 2 args inside a loop, with no catch() anywhere in the function. The uncaught throw aborts change_phase() at that exact statement, meaning the function's OWN tail — call_out("change_phase", day_phases[current_phase]["length"]) — never runs, so the entire day/night phase cycle daemon permanently stops forever for the rest of that boot, with the single runtime-error line in debug.log as the only trace (no crash, no other visible symptom; weather/ambient broadcasts and phase-change text simply never happen again). Trivially reachable: WEATHER_D->request_weather_notices() is called by every outdoor room's set_outside() (std/room/room.lpc), so registering even ONE outdoor room (any ordinary walk outside) arms the crash for whenever the phase timer next fires — some phases in adm/etc/daytime.data are as short as 1 second, so this fires quickly in practice, well within a normal play session. Confirmed via diff: es1_win's copy of tell_room.lpc is byte-identical and carries the same unfixed bug (not caught by that lib's own §10.7 pass — plausibly a timing/room-visited difference between sessions). Fix (matching AGENTS.md §7.12's documented remedy exactly):

// BEFORE
message("tell_room", msg, room, exclude);
// AFTER
message("tell_room", msg, room, exclude || ({}));

Live-verified on esI two ways: (a) played normally afterward with an outdoor room registered for ~15 real seconds, zero new debug.log errors; (b) direct proof via the fluffos admin account's eval command — eval tell_room(environment(this_player()), "TESTBROADCAST_2ARG\n"); return 1; (the exact 2-arg shape that crashed weather_d.lpc) broadcast cleanly with Result = 1 and zero debug.log error, both pre-fix (reproduced the crash directly this way too) and post-fix (clean). Ported to es1_win (libs/es1_win/work/adm/simul_efun/tell_room.lpc, same one-line fix, comment cites this lib's finding) and sanity-checked there with a fresh boot + existing test-character login/look/quit (clean, zero new errors) — not a full independent replay of es1_win's own §10.7 checklist, since that lib was already marked done; flagged here for whoever next touches es1_win to note in ITS OWN NOTES.md.

What was tested and confirmed working

• help start read first (doc/help/c_start) — same TMI/ES house style as es1_win's c_start, documents the guild cost/advance/ train/list/join organic skill path (no NPC-dialogue teacher in this lineage) and the real starting layout (远风镇/冒险者公会).
• Registration: full flow (English id → confirm new → Chinese name → password/confirm → gender → race → email → real name → MOTD/RETURN) reached /d/adventurer/hall/adv_guild correctly, twice (Jiangfeng, Muyunhe). Both got the "自动获得巫师权限" (automatic wizard status) message this snapshot's config grants every new character — cosmetic only in practice: west from adv_guild into /d/wiz/wiz_hall (wizard-only gate) still correctly rejected both test characters with "对不起，只有巫师才能进去。", and the eval wizard command was only reachable as the separately-seeded fluffos admin account, not either test character — documented as an observation, not "fixed" (a gate correctly rejecting a character despite a registration banner that implies it shouldn't is at most a content/messaging inconsistency, not a crash or obviously-wrong efun call).
• look/score/i: correct at every state change (registration, post-training, post-combat, post-shop-purchase, post-reconnect, post-relogin).
• Guild training (organic path, no NPC teacher — cost/advance/ train/list in the guild room itself, std/guild.lpc): list showed the 7 trainable adventurer-guild skills with real costs; train unarmed correctly deducted exp and printed "你的空手搏斗技能现在提升到 1 了。".
• join: tested at the already-joined adventurer guild — correctly replied "你已经是本公会的成员了！" (matching es1_win); no separate sect/faction system beyond the documented guilds (adventurer/mage/ healer/knight/monk/thief/scholar, each gated behind the same join-in-guild-room mechanic reached via real travel this pass didn't budget time for beyond the starting adventurer guild).
• Safe-sparring mechanism: this lib DOES have one, unlike es1_win — a scripted "doll" combat tutorial at /d/noden/school/basic3-doll.lpc (kill doll sets a flag, waits 3 real seconds, then cease_all_attacks() — genuinely no real combat resolution happens, confirmed by code read; grep -r accept_fight across the whole tree is empty, same as es1_win, so nothing in this lib implements a real damage-mirroring practice dummy). Reaching it requires completing a lengthy multi-room, command-specific tutorial gated by school1/school2 flags (get/give/put/search/ask/ say/hp/who/look sequences across ~14 rooms) — not traversed this pass given the time budget, AND because it wouldn't have exercised real combat resolution anyway (per the code read above). Used a real level-1 野狗(dog) at 远风镇西门 instead (same choice es1_win's own pass made, for the same reason — no functioning accept_fight()-style dummy exists in this lineage).
• Combat: consider/kill both worked; 40+ real turn-by-turn combat rounds resolved correctly (hit/miss/damage messages, hp mid-fight status, score reflecting HP/SP loss) against the level-1 dog — both combatants have minimal stats (character starts at 1 in every attribute) so hit rates are low and neither side reliably wins; fled cleanly with a direction command (战斗结束了。). No crash, no eval-cost error, no stuck state.
• Shop purchase — completed live: admin-granted Muyunhe 50 gold + 50 silver coins via the fluffos account's eval (see "Not verified live" for why admin-assisted, not organic), then buy torch at /d/noden/farwind/shop correctly charged 5 silver ("你花5枚银币　买下一枝火把。"), added the torch to inventory, and score's money breakdown updated correctly (50 金币 / 45 银币). wield torch correctly rejected ("那并不是武器。" — not a weapon). This also re-exercises bug #2's fix (the shop's list/item-property lookups) and bug #4's fix (the shop's first-ever reset()) together in one real transaction.
• quit + debug.log: every quit in this pass (multiple, across both test characters and the admin account) was followed immediately by a grep of libs/esI/log/debug.log — all clean except for the bug #5 crash line itself (found this way, per §10.7's own worked lesson: never trust a normal-looking on-screen quit/interaction without checking the log).
• Net-dead reconnect — both edge cases tested, not just the ported one: (a) the registration-interrupt case (bug #1, above); (b) the ORDINARY case — a player already properly placed in a real room (Muyunhe in adv_guild) disconnected uncleanly (no quit) and reconnected PROMPTLY: 重新连线完毕, landed back in the exact same room with exact same HP/exp state; repeated with a real ~81-second wall-clock wait (via a foreground polling loop, not a backgrounded sleep) before reconnecting — identical correct result, zero new debug.log lines either time. (Did not wait through the full WIZ_LINKDEAD_DUMP/LINKDEAD_DUMP force-quit timer — 20-60 real minutes per include/body.h — out of this pass's time budget; the es1_win sibling's own pass didn't either.)
• Clean-quit relogin: quit cleanly (Muyunhe), reconnected fresh (full login-shaped relogin, not net-dead reconnect) — correctly restored to adv_guild with all state (HP/exp/inventory/money) intact.

Not verified live (explicitly)

• Death and respawn: not reached — the one real fight run this pass (40+ rounds vs. the level-1 dog) never concluded either way given both combatants' minimal stats; deliberately seeking a losing fight wasn't pursued within this pass's time budget. Same as es1_win's own pass.
• The shop purchase used admin-granted money, not organically-earned money: Muyunhe started with zero gold (身无分文, same as every new character) and no in-session path to earn any was pursued (same situation es1_win's pass documented); coins were cloned directly via the fluffos account's eval command (new("/std/coins")/set_type()/set_number()/move()) rather than earned through gameplay. The actual buy transaction itself — ACL, price deduction, inventory update, the shop's own sell/value logic — IS real and live-verified; only the money's ORIGIN is admin-assisted rather than organic.
• Other guilds (mage/healer/knight/monk/thief/scholar): not travelled to and joined — only the starting adventurer guild's join (already-a-member case) was exercised live. Code review of std/guild.lpc suggests the same mechanism handles all guilds uniformly, but this is not the same as a live-verified join into a DIFFERENT guild.
• Full tutorial-school traversal / the "doll" scripted sparring mechanism: not completed (see "What was tested" above for why — time budget, plus it wouldn't exercise real combat resolution anyway).
• A broader lib-wide sweep for other rooms sharing bug #4's shape (a room whose create() synchronously reset()s a first-time-heavy NPC roster): 1553 files share the "direct reset() in create()" convention lib-wide; only the farwind shop was actually walked into and crashed this pass. The maximum evaluation cost config fix is lib-wide (protects every such room, not just the shop), but no attempt was made to enumerate or pre-visit every other room that might carry an equally-heavy first-load NPC.

Deep functional test round two (2026-08-14)

Independently re-verified all 5 round-one fixes against current code and live behavior rather than trusting the writeup above. All 5 confirmed still holding; no new bugs found or fixes needed this pass.

• Fix 1 (net-dead-during-registration restart_heart()): code-confirmed the complete_setup("") fallback branch is still present. Not re-walked live this pass (same reasoning as es1_win's own round-two pass — expensive relative to a small, previously thoroughly-verified conditional).
• Fix 2 (compress_obj.h §7.14 base_name(this_object())) and fix 4 (§7.90 eval-cost, 300000 → 5000000): both live-verified together in one test, matching the exact original crash scenario — walked 冒险者公会 → east → east into 商店 on this boot's genuinely first-ever visit (fresh reboot, first attempt). Landed cleanly, full item list rendered (油灯/绷带/魔法地图/火把 with prices), the level-19 woodman NPC (皇家护卫团四将 怒, the original crash's heavyweight first-load trigger) present and correct, zero new work/log/debug.log lines (checked the line count before and after: unchanged at 2693).
• Fix 3 (leftover ttt/ttt1-ttt4 debug prints in logind.lpc): code-confirmed zero ttt matches remain, then live-confirmed by watching a full fresh admin login transcript end-to-end — no stray ttt* lines anywhere.
• Fix 5 (§7.12 tell_room() exclude || ({})): code-confirmed still present with its explanatory comment. Not re-triggered live via the original weather_d.lpc/outdoor-room mechanism this pass (would require registering an outdoor room and waiting for a phase-change call_out), but the same underlying tell_room() code path was exercised indirectly during ordinary movement/room-entry broadcasts throughout this session with zero errors.

Also verified: real admin write access via update /adm/daemons/logind (succeeded, "Updated and loaded.") — used as the actual privileged-action check rather than trusting any login banner. One reconnect exercised (the connection's own quit is gated behind okip for wizards, same as es1_win's sibling architecture — a genuine safety feature, not a bug — so the reconnect went through the silent net-dead body-reattach path, landing back in the shop with identical state, which is itself valid reconnect-stability evidence).

Verification method

Booted native build-debug driver (zero eval-cost/preload errors this boot, confirming fix 4 holds from cold start), admin login (fluffos/Mud@2026). Driver killed by exact PID after testing; incidental fluffos.o/d/noden/log/d/zeq/log save churn reverted before commit (no code changes this pass — nothing else to stage).

§7.100 sub-threshold instance (2026-08-20)

Found during the §7.100 tail-sweep (the original 166-lib corpus sweep only surveyed libs with >=100 live occurrences; this lib was below that threshold and never checked). 1 live replace_program(ROOM); occurrence in d/noden/6,8.noden.lpc's create(), immediately after inherit ROOM; — same fatal shape as the rest of the §7.100 family (sets a permanent "pending replace" flag that crashes the object the first time anything binds a closure to it). No roommaker.lpc-style room-building tool exists in this lib, so no factory-template copy of the bug. Fixed by deleting the redundant line. Verified via a clean native driver boot (zero new debug.log errors, port listening, killed by exact PID after ~8s).

Deep functional test round four (2026-08-20)

Targeted re-test of the two things every prior round explicitly left unverified: a real death→respawn cycle, and a real join into a non-starting guild. Per the project's current scope rule, only pursued actual programming bugs (crash / debug.log error / stuck state) — not content or balance.

Method note: both tests needed a wizard-controlled second connection alongside the test character, run as a two-socket Python script (not tmux_mud.sh/single-connection mudclient.py) so the admin account could eval state changes on a character that stayed connected and interactive throughout. Two real methodology traps hit and resolved along the way, worth flagging for whoever does this next on another lib: 1. The eval command's underlying _set() (std/object/prop_logic.lpc) has an intentional security guard that silently no-ops any set() call from a /open/-rooted script onto a non-wizard living object's properties (blocks /open sandboxes from writing player state directly) — so ob->set("hit_points", 0) from eval does nothing, with no error, no exception, query() afterward just returns the unchanged old value. This is by design, not a bug. The correct way to deal admin-driven damage is ob->receive_damage(N), which is a real gameplay API that mutates the property mapping directly from the target's own context, bypassing that guard exactly as real combat damage does — and it independently no-ops (also by design) if the target is currently linkdead (receive_damage()'s own guard), so the test character's socket must be kept open/connected throughout, not closed between steps. 2. A genuinely fresh (non-net-dead) login stops at the "[请按 RETURN 键继续]" MOTD gate (setup()'s input_to("complete_setup", 2)) before complete_setup() actually places the character in a room — a *reconnect* (net-dead resume) skips this entirely via a different code path (restart_heart()/"重新连线完毕"), which is why earlier rounds' sessions never hit this. A command sent into that still-armed input_to() slot (e.g. look) gets silently consumed as the RETURN-prompt's answer instead of dispatching as a real command, and complete_setup() then places the character at their *default* start room, silently overriding anything done to them (e.g. an admin move_player() teleport) in between. This produced two confusing false leads before being root-caused: an apparent "teleport didn't stick" (character 's join replied "you're already a member" because they'd been silently routed back to the adventurer guild, their real default start room) and an apparent unexplained second death (almost certainly the same mechanism misfiring on a different test character, though not re-isolated as precisely — a clean, admin-untouched 60-second silent-watch re-run with a fresh character never reproduced any second death, so this is recorded as a methodology artifact, not a mudlib bug). Fix for future sessions: after a fresh (not reconnect) login, send one more blank line and wait for the actual room description — not just the OKIP-check line — before sending any other command or doing any admin-side manipulation of that character.

Real bug found and fixed: die() crashes forever (never completes) when the character has no living last attacker

std/user.lpc's die() sets killer = query("last_attacker"); if (!killer) killer = previous_object(); and then, in the un-fixed code, used killer in two places without checking it might still be 0:

// BEFORE
if (!wizardp(this_object()) && killer->query("npc"))
  ...
if (this_object()->query_level() < 5 && userp(killer) && query("last_attacker")) {

last_attacker is only set by std/body/attack.lpc's receive_damage() when the damage's previous_object() at the time of the call is itself a living() object — i.e. real melee/spell combat from another living creature. Any OTHER damage source (poison, bleeding, sickness, drowning/suffocation, desert exposure — all real, reachable status-effect conditions in std/conditions/, each calling receive_damage() from a non-living condition-daemon caller — or an admin-applied receive_damage() call) never sets last_attacker, and previous_object() *at the point die() itself runs* (called from heart_beat()→continue_attack(), with no calling object in that chain) is also 0. killer then stays int 0, and killer->query(...) /userp(killer) both throw a driver-level call_other/efun-argument error on this exact line, every single time, since continue_attack() re-invokes die() on every subsequent heart_beat() tick as long as hit_points < 1 — the crash never lets execution reach the link_data("dead") early-return guard further down (line 1009, *after* the crash site), so the character never actually dies: no corpse, no ghost, just an infinite repeating on-screen runtime-error spam and a permanently stuck negative-HP body. Reproduced live twice (once via the crash itself, once again confirming the SAME crash recurred one line further down after the first fix, until both call sites were guarded) using receive_damage(9999) via the fluffos admin account against a real, fully-connected test character (蜘蛛精/ testdieb's predecessor characters 夜寒霜/testmage, 白骨精/ testdie — see method notes above for why an artificial admin damage source was needed to reach this branch, since ordinary NPC combat sets last_attacker correctly and never hits it). Confirmed byte-identical unguarded code in sibling es1_win's std/user.lpc (same lineage, not yet fixed there — flagged for whoever next touches that lib).

Fix: added killer && short-circuit guards to both call sites, matching every other killer-using line in the same function (lines 1012-1014, 1084, 1089-1095, 1109-1117 were already correctly guarded with if (killer) — only these two were missed):

// AFTER
if (!wizardp(this_object()) && killer && killer->query("npc"))
  ...
if (this_object()->query_level() < 5 && killer && userp(killer) && query("last_attacker")) {

Live-verified end to end, twice, on a fresh driver boot with a fresh test character each time (testdie, then testdieb — testdie's run additionally included the admin eval diagnostic that reproduced the raw crash text on-screen pre-fix and confirmed its absence post-fix): receive_damage(9999) → 你死了。 → ghost creation → the full black_wuchang/黑无常 narrative (death1 at +10s, death2 at +30s more) → revive() restoring the character to a real living body in /d/noden/farwind/cemetery (露天英雄纪念馆) with reduced stats (10/30 HP, matching the documented "skills reduced on death" mechanic) — zero crashes, zero new lines in work/log/debug.log or work/log/log throughout. testdieb (id testdieb, password TestPassD2, human female adventurer) is left parked alive in the cemetery room as evidence; testdie and the earlier testmage mage-guild character were cleaned up (redundant once testdieb/ testguild cleanly demonstrated the same things without the methodology-artifact confusion).

Real guild join into a non-starting guild — verified twice (mage, healer)

Code review in every prior round noted std/guild.lpc's do_join() / each guild's own join_player() looked uniform across all 7 guilds but was never live-exercised for anything but the starting adventurer guild's already-a-member branch. This round completed real joins into two different non-starting guilds, both via a wizard move_player() teleport (d/mage/tower/mage_guild, d/healer/building/healer_guild) followed by the character's own real join command — matching the project's established "sect-joining needs wizard goto, not on-foot exploration" precedent (guild rooms aren't exit-reachable from the starting hall within a reasonable test budget):

• Mage guild (夜寒霜/testmage, human female adventurer, since cleaned up): join correctly triggered d/mage/mage.lpc's join_player() — race-check passed (human isn't in the lizardman-only exclusion list), spellbook token moved to the character, welcome text and guild-wide announcement both printed ("拉修帝说: 欢迎加入魔法师公会..." / "[魔法师] 拉修帝 : 欢迎 夜寒霜(testmage) 正式加入我们的行列!"), and score afterward correctly showed the class change ("人类魔法师", title "魔法仰慕者").
• Healer guild (紫霞仙子/testguild, human female adventurer, password TestPassG1 — kept, parked in the healer guild room as evidence): same mechanism, different guild — d/healer/healer.lpc's join_player() (race-check against a different exclusion list: orc/lizardman/vampire/beholder, also passed for human) correctly granted membership ("欢迎加入行医者公会..." / "[行医者] 刑老爹 : 欢迎 紫霞仙子(testguild) 正式加入我们的行列!"), score showed "人类行医者" / title "草包看护生", and a follow-up admin eval independently confirmed ob->query("class") returns "healer".

Both joins used the SAME std/guild.lpc→per-guild-file→std/guild_ob.lpc mechanism the prior rounds' code review predicted (the guild token object, moved into the player, sets owner->set("class", class_name) via guild_ob.lpc's move hook) — this round's live tests confirm that prediction was correct, generalizing cleanly to at least 2 of the 5 previously-unverified guilds (mage, healer). Knight/monk/thief/scholar remain code-reviewed-only, not live-verified, though there's no reason to expect them to differ given the shared mechanism.

Standing bug checklist sanity pass

All checked via direct code read against the CURRENT work/ tree (no live re-trigger needed for any of these — either already fixed, or confirmed the vulnerable shape was never present):

• §7.90 (eval-cost): config.fluffos's maximum evaluation cost confirmed still 5000000 (the round-one fix holds).
• §7.100 (replace_program(ROOM)): confirmed fixed per this file's own dedicated section above; re-confirmed no new occurrences via a fresh grep this round.
• §7.111 (standard_trace() null-object file_name()): adm/obj/master.lpc already carries the guarded form (objectp(error["object"]) ? file_name(error["object"]) : "none object") — was fixed in the corpus-wide sweep, still intact.
• §7.112 (init()-scheduled call_out duplicated by reconnect): N/A — a corpus-wide grep for call_out("death_stage" (the pattern's signature) across this lib's whole work/ tree returns zero hits.
• §7.113 (netdead reconnect never restores heart_beat): confirmed clean — adm/daemons/logind.lpc's reconnect() calls body->restart_heart(), and std/user.lpc's restart_heart() unconditionally calls set_heart_beat(1) in the correct this_object() (player-body) context at the end of the function.
• §7.114 (private input_to() callback through an inherited mixin): N/A — this lib's edit-flow mixin (std/living/edit.lpc) has no private input_line-shaped function; a corpus grep for private.* input_line across the whole work/ tree returns zero hits.
• §7.115 (QUEST macro pointing at a non-existent file): N/A — this lib's quest daemon macro is QUEST_D (/adm/daemons/quest_d, a real, existing file), not the standalone /std/quest shape that bug is specific to; confirmed via grep that no file in this lib references a bare QUEST macro at all.
• §7.79 (bare 2-arg addn/addn_temp): N/A — this lib doesn't use addn/addn_temp anywhere; grep -rn "addn_temp(\|addn(" across the whole work/ tree (excluding the simul_efun shim's own definition) returns zero hits.

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

同一血统（屠龙之战）。

深度功能测试（§10.7，2026-10-04）— compile warnings: 3795 -> 4, none in a file that compiles

scripts/lpc_warnings.py esI: 5859 files compile, 1176 do not; 4462 distinct diagnostics (3795 warnings, 667 errors). Now 5918 / 1117; 598 diagnostics: 594 errors in the files that still do not load (missing ../hole.h-style includes, set_closed_long and other functions of another lib, syntax errors) and 4 warnings, all in three of those files (adm/daemons/mailmesg.lpc, d/eastland/mumar/monster/cook_master.lpc, d/noden/asterism/monster/gnome_archelder1.lpc). 1208 files edited.

Mechanical (--fix): 603 #pragma save_binary lines (two more spelled #pragma save_binary ;), 385 nosave functions (364 protected, 21 left public because another object calls them), about 1100 unused locals, 8 range ends ..-N] -> ..<N], 31 escapes. 438 stray backslashes after the Big5 characters whose second byte was 0x5C (功, 许, 摆, 缕, 髅, 盖, 枯, 豹 ...; KB 03 §4.4): the driver prints Unknown escape sequence at the end of the string or statement, not at the backslash, so the fixer now cleans every \ before a multi-byte character in a file that reports one. 24 macros the old globals.h and the ES headers both define get an #undef before the later #define (the later one was already in effect).

By hand:

• std/npc.lpc declared a second mapping alias (the body's alias module has its own) and only ever stored ([]) in it: 1099 of the warnings. Both lines are gone; the module initialises its table lazily.
• Reserved words used as names, so 59 files did not load: class -> cls (17 files: guards, pets, the war mob, the Chi Yu NPCs, std/body_npc.lpc, /cmds/adm/_setnews.lpc), ref -> refl (adm/daemons/ref_d.lpc and five NPCs), new -> new_mud (adm/daemons/network/services/mudlist_a.lpc). Two missing ) in d/std/social_guild/wolf_killer.lpc.
• == typed for =, a lost return, a lost assignment (these are gameplay): d/adventurer/cmds/_bribe.lpc (13 charm == N;: charm stayed 0 for every race), cmds/std/_who.lpc (wiz_only == 1: who -w filtered nothing), the three _acupunct*.lpc (targetname == "自己"), d/noden/moyada/sand_square.lpc (for (i == 0; ...)), the two shield spells' query_need_skill() ({ 40 + 15 * level; }: casting needed no skill), both jousting.lpc ({ 50; } for dam = 50: the top tier did no extra damage), std/room/std_storage.lpc (the AMOUNT < 0 floor was never stored), d/std/IRC/lobby.lpc (else ("...") never printed), a stray ; after if (str == "none") in std/lock.lpc (unreachable code).
• Two parents, one init(): vendor, medic, patolas inherit /std/seller beside the NPC base and shepherdess inherits /std/teacher; the later inherit's init() replaced the other, so buy and the teaching commands were never added. They call both now, as obj/vendor.lpc and lulu.lpc always did; d/eastland/yogor/room4.lpc does the same for reset() (seller's restock had replaced the room's). Seven coinvalue()/cointypes() diamonds (stateless) and the two Saulin towers' clean_up() from STATS_D are named, nothing changes.
• Return types made to agree: create_ghost() prototypes are object like the body's, shop.lpc clean_up() is int like its leaf, die(), remove() and reset() of three leaves are void like their bases, and five prototype/definition pairs (stats_npc.lpc, courthouse.lpc, _operate.lpc, _su.lpc, new.lpc). levels of the mage and monk books is sort_levels (nosave), _goto.lpc !where | !objectp(where) is ||, _less.lpc's header no longer nests /*.

Pristine tree, HEAD against the working tree, same driver: look, score, who, skills, help answer identically for the admin; the HEAD console prints 769 compile warnings while it boots, the new one none. scripts/lpc_audit_removed_locals.py HEAD checked 2149 deleted declarators: none is read afterwards.

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

scripts/lpc_fix_negative_ranges.py: 8 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）— <../x.h> includes resolve: 184 more files load, 0 warnings left

#include <../hole.h> (185 files under d/) names a header relative to the including file. The driver refuses .. in a <...> name and resolves only a quoted include against the including file, so every one of those NPCs, weapons and armours died with Cannot #include, and so did everything that used the macros the header defines (the earlier section's "missing ../hole.h-style includes" was this, not missing headers: 178 of the 184 headers are where the name says). A wizard's goto /d/deathland/dwarf/center answered No program in object, as did the Deathland fog, palace and troll rooms, cook_master, the island vampire and the dragon-bone amulet. adm/obj/master.lpc now answers include_file() with "./" + path for a name that starts ../ (KB 04 §6.1). lpcc --batch (it runs create()) loads 178 of the 186 files that carry such an include (HEAD: 1), and a live session against HEAD and the working tree shows the rooms and clones working where HEAD printed the error. The 8 that still fail are content gaps, left: liang_shan/monster/guard2.lpc wields gurad_sword that no weapon directory has, mumar/monster/temp.lpc is a draft with a broken if, d/island/monster/{feller,old_feller}.lpc include ../hole.h where the header lives in d/island/hole/, d/scholar/demand/where/{fire_beast,princess}.lpc include the headers of two other areas, and mumar/UNDER/MONSTER/{armor,weapon}_smith.lpc sit in a directory of upper-case DOS names (*.C) that is no part of the game. d/noden/drow/mob/ghost.lpc had lost the ); after its set_long here-document and the () of my_tactic; both are back.

Newly loading files showed what they had been hiding (24 unused locals and 11 stray backslashes, mechanical), and the hand-fixes: obj/shells/shsh.lpc used buffer and class as names (both are types here: the saved colour pair is now buffer1, so a shell saved with the old name loses that one colour setting; class -> cls) and 50 of its functions were nosave; adm/daemons/mailmesg.lpc had //#include <config.h> commented out and no SAVE_EXTENSION, so the daemon never compiled; d/noden/asterism/monster/gnome_archelder1.lpc used ref, and its die() is the body's varargs void die(int silent); goomay/monster/army.lpc remove() is void. scripts/lpc_warnings.py esI: 5918 files compile, 1117 do not -> 6102 / 933; 0 warnings and 246 errors, all in files that still do not load. scripts/lpc_audit_removed_locals.py HEAD found nothing a function still reads.

深度功能测试（§10.7，2026-10-04）— stray backslash before a closing quote

A Big5 character whose second byte is 0x5C was written with one extra backslash after it (the old driver read 5C 5C as one backslash and so completed the character) and the UTF-8 conversion kept it (KB 03 §4.4). Before a closing quote it escapes the quote, the string runs into the next line and the file does not compile. scripts/lpc_fix_big5_quote_backslash.py deletes it when the character before it encodes to cp950 with 0x5C as second byte and the quote ends an expression. Here: d/eastland/saulin_temple/obj/vege_food.lpc (set_name and set_short end in 素食大餐\"; 餐 is cp950 C0 5C), which did not compile.

深度功能测试（§10.7，2026-10-04）— the files that still did not load, read one by one: 177 of 7036 left

lpcc --batch over every .lpc (KB 08 §10.4; scripts/lpcc_real_fails.py): 6136 load, 723 only hit the batch's call_out(0) nesting limit, 177 do not load. The same classes as in es1_win (its section of today has the reasons), read here file by file:

• Lost includes: 31 files (adm/daemons/network/{netmail,services/{gchannel,tcp}}, std/board/archive, cmds/std/_orglv, the d/zeq armour and tokens, island and Moon/Boss files ...) name MONSTER, ARMOR or SAVE_EXTENSION without the header that defines them (scripts/lpc_add_missing_include.py finds it), and dagger1 and plate got the <mudlib.h> es1 has.
• inherit below a global (captain1, wiz_elder1, obj/tools/barney, std/npc2); stale paths (the five island war mages' i_warvalue, saulin_temple/workshop, d/wiz/hallway, d/island/monster/{feller,old_feller} -> ../hole/hole.h, liang_shan/obj/fish_plate -> ../takeda.h, the IRC rooms' IRC -> RM); typos (string *compared in 8 sewer rooms, _yubi, the saulin board, flamen, old_feller's [BB, the war mages' object victim, fire_hammer/shopkeeper/bubble_metal_slime return types, bitflags status).
• Reserved words: ref in cmds/file/_changelog and gnome_archelder1, in in cmds/ghost/_llook (in_item), new in cmds/wiz/_shell (new_shell), class in std/npc2, and the shell's buffer/class (the shell's saved colour pair is buffer1 now, so a shell saved under the old name loses that one colour). adm/daemons/mailmesg.lpc had //#include <config.h> commented out, so SAVE_EXTENSION was undefined and the daemon never compiled; adm/daemons/mailer_d casts (string)this_player(1)->QUERY_NAME against a mixed * (the cast is gone, as in es1_win).
• get_dir(x) == -2 in cmds/std/_bug.lpc and praise.lpc -> file_size(x) == -2 (KB 06 §7.218); tail() as a simul_efun.

Left as content gaps (not invented): 40 inherits of files that are not in the archive, 30 NPCs that wield or wear files that were never shipped, wizard-home headers, drafts, the upper-case DOS directory d/eastland/mumar/UNDER (*.C), a stray std/user/复件 bitflags.lpc ("copy of bitflags"), and the same commands saved without the leading underscore (flee, praise, typo).

深度功能测试（§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 esI: 72 file(s) renamed to lower case (.C -> .lpc, .H -> .h) and 0 path reference(s) in 0 file(s) rewritten to the new spelling; 0 skipped, 0 ambiguous. Load check of the 75 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 -> 5 PASS, 0 that loaded before fail now, 4 more load.

72 files moved (63 .C, 6 .lpc, 2 .H, 1 .h); mostly under d/eastland/mumar (71), d/DONY/VALLEY (1). A rescan with scripts/lpc_warnings.py esI is still due: the renamed files are compiled for the first time.

深度功能测试（§10.7，2026-10-05）— 主控 author_file()

驱动的 mudlib_stats 包在主控载入时调用一次 author_file(<主控文件>)，要求返回字符串，否则每次启动都打印 author_file() in the master file does not work, using root_uid as fallback 一行，网页版每位访客的终端里都看得到。本库 adm/obj/master.lpc 的 author_file() 只为 /u/<字母>/<名字>/ 下的文件返回作者，其余返回 0。而且驱动传入的路径是 "/" 加上配置里的 /adm/obj/master，即 //adm/obj/master，sane 模式的 explode() 会保留一个开头的 ""。praise 和 find -author 直接调用 master()->author_file()，把 0 当作“没有作者”，所以没有把 0 改成字符串。现在先去掉空段（explode(...) - ({ "" })），/adm 下的文件返回 ROOT_UID（与同文件 domain_file() 的 adm 分支一致），这样也回答了开机探测；/u 分支加了长度检查（原来 /u/<x> 这样的短路径取 path[2] 会越界出错，而 author_file() 在每个对象载入时都会调用）（KB 06 §7.222）。用 lpcc config.fluffos /nonexistent.lpc 前后对比（主控和 preload 全程），只少了这一行。

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

编译警告收尾（2026-10-13）

scripts/toolkit_fix.sh 一轮：std/adt/body.lpc 多余的继承去掉；std/npc2.lpc 的 nosave 函数改 protected（外部调用的 die() 只去掉 nosave），没用的局部变量删去；cmds/ghost/_llook.lpc、std/npc2.lpc 字符串里 BIG5 转换留下的 功\能、许\多 多余反斜杠去掉；d/eastland/liang_shan/obj/fish_plate.lpc 没用的局部变量删去。能编译的文件警告清零；改动的对象在 HEAD 与工作树各载入一次，regress 0。

• 2026-10-14：新驱动（FluffOS 970d9f09）报 Float value truncated to int（#1426）。6 个文件 10 处：赋值、初始化、return 改写成 to_int(...)（值不变，只是写明截断）；x op= 浮点 先把浮点转成整数再运算（系数小于 1 时 x 直接变 0），改为 x = to_int(x op ...)：/d/monk/guild/train_room.lpc（exp -=）、/d/thief/hall/monsters/taylers.lpc（exp -=）、/d/thief/hall/monsters/taylers.lpc（exp -=）、/d/thief/hall/monsters/taylers.lpc（exp -=）。改动的对象新进程各载入一次，无回退（scripts/lpc_fix_float_trunc.py，KB 04 §6.10）。
• 2026-10-14：67 个存档文件（其他 67 个；d/adventurer/data/attic/adventurer_board_798460167.o, d/healer/data/attic/healer_board_780485145.o, d/healer/data/attic/healer_board_781540005.o …）还是原档案的 GBK 编码，没有转成 UTF-8，restore_object() 报 Invalid utf8 string 后对象以空数据启动（表情守护进程没有表情、留言板没有帖子、玩家无法载入）。scripts/lpc_save_encoding.py 逐个按 GB18030 解码，结果按存档格式解析通过才写回（KB 03 §4）。

• 2026-10-14：2 个文件因 Illegal to inherit after defining global variables 整份不编译：FluffOS 要求所有 inherit 写在第一个全局变量之前，MudOS 不管。scripts/lpc_fix_inherit_order.py 把写在 inherit 之前的全局变量（以及声明全局变量的头文件的 #include）挪到最后一个 inherit 之后（KB 04 §6.3）。

• 2026-10-14：1 个文件因 Type of returned value doesn't match function return type ( int vs void ) 整份不编译：声明为 void（或没写类型）的函数却返回值，旧驱动照样把值交给调用者。调用者要用返回值的（add_action 处理函数、命令、辅助函数）改为它实际返回的类型：report()。新进程比对 HEAD 与工作树：4 个对象，新增载入 2，回退 0（scripts/lpc_fix_void_return.py，KB 04 §6.3）。

• 2026-10-14：d/deathland/deathworld/hole1-7.lpc 写成 #include <DWORLD.h>，实际文件是 dworld.h（大小写），整份不编译；改为小写。

储藏室东西过多时清不掉（2026-10-15，KB 06 §7.245）

std/room/std_storage 的 my_clean_func() 在物品超过上限一半时从最后一件往前清：for (i = number; ; --i) 从 inv[number] 开始，第一次就越界，报 Array index out of bounds，储藏室从来没有被清过；循环也没有下界。改为 for (i = number - 1; i >= 0; --i)。跳过玩家的判断写成了 ->querry("npc")，一并改为 query（原意是留下玩家、NPC 也清）。测试里六件物品、上限二：改前越界报错，改后剩两件。

去掉的预定义宏 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）：include/net/oldftp/ftpdsupp.h。

d/noden/asterism/monster/dwarf_healer 的台词里引号错位（2026-10-18，KB 03 §4.6）

台词那一行 "……只记得那个东西叫" 优 波 罗 花 "。\n"：“叫”和“花”两侧的引号把字符串断开，中间的 优 波 罗 花 成了代码（Illegal character），NPC 载入不了。改成 '优波罗花'。载入：通过。

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

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

区域物件的零碎修正（2026-10-19，KB 06 §7.267–§7.271）

• std/npc.lpc 的 wield_weapon()/equip_armor() 在 new() 找不到文件时不再对 0 调 move()（d/noden/hawk/monster/elder 拿的武器在巫师目录里，整个 NPC 载入不了）

逐个物件与 HEAD 对比载入，没有退步。

补回丢失的标点（2026-10-19，KB 03 §4.6）

转换时丢掉的分号、逗号、引号或文件末尾的 }，共 1 个文件，修前 HEAD 载入失败。别的库里同路径的完好副本只比这里少几个标点，按它补回（括号里是那个库）：/d/eastland/saulin_temple/board.lpc（es1）。修后与 HEAD 逐个对比载入：这 1 个物件全部载入，没有退步（scripts/lpc_restore_from_twin.py、lpc_fix_eaten_quote.py --comma、lpc_fix_eof_braces.py）。

x != "a" || x != "b" 和 x == "a" && x == "b"：同一个值的比较链永远成立/永远不成立（2026-10-20，KB 06 §7.282）

if (arg != "wan" || arg != "丸") return notify_fail(...) 对任何 arg 都为真，dir == "south" && dir == "north" 永远为假：条件下面的守卫要么永远拦、要么永远不拦。作者要的是“既不是 A 也不是 B”（&&）或“是 A 或 B”（||）。!= 链的 || 改成 &&（仅当条件下面是 return 的拒绝/守卫），== 链的 && 改成 ||（scripts/lpc_fix_cmp_chain.py）。改动：/d/eastland/yogor/room37.lpc（1 处）。另有 /d/island/obj/box.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/xtra/_callouts.lpc（1 处）、/obj/tools/cod.lpc（3 处）。

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，共 7 处）。改动：/cmds/xtra/_graph.lpc（1 处）、/d/adventurer/hall/obj/salt_bottle.lpc（1 处）、/d/adventurer/hall/obj/test.lpc（1 处）、/d/eastland/yogor/mob/paladin.lpc（4 处）。

登录密码超过 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）。

advance：5 级以上时 check_explore() 除以零（2026-10-21，KB 06 §7.331）

公会的 advance 在等级 5 以上要问 EXPLORE_D->check_explore(me)，它对每个区域算 探险点 * 100 / query_total_explore(区域)。区域总数是巫师用命令 explored 登记的探险点数，登记数据（存档）不在归档里；公会自己的 explore 指令对 max < 1 的区域写了 continue，check_explore() 没有，所以新树里只要有一个区域没有登记点数，advance 就抛 Division by zero。先取总数，总数小于 1 的区域当作没有可探索的东西（mark++; continue;），与 explore 指令一致。三个库（es1、es1_win、esI）的 explore_d.lpc 逐 token 相同，同一处改法。只做了加载检查（没有 5 级的角色可测）。

idea：CMD_PRAISE 指向不存在的 _praise（2026-10-21，KB 06 §7.325）

include/commands.h 的 #define CMD_PRAISE "/cmds/std/_praise"，而归档里（raw/ 也是）这个基类文件叫 praise.c，没有下划线（typo.c 也没有）。_idea.lpc 和 typo.lpc 都 inherit CMD_PRAISE;，敲 idea 时命令守护进程按 /_ + 命令名找到 _idea，编译时 Inherited file '/cmds/std/_praise' does not exist!，玩家的命令作废。宏改成 "/cmds/std/praise"，_idea、typo、praise、_bug 四个都加载（HEAD 2、树 4），实测 idea 打开编辑器（"Begin writing your idea report."）。typo.lpc 没有下划线，守护进程的命令表只认 _命令名，typo 仍然是 "什麽？"，和归档一致，没有改文件名。

存档里的 .c 文件名改成 .lpc（2026-10-21，KB 03 §4.2 第 9 项）

存档里写着 "/d/city/npc/wei.c" 这样的文件名；extract 时源文件已经全部改成 .lpc，而驱动对带扩展名的路径只认字面，new() / load_object() / move() 都找不到它，调用方多半把失败当成「没有这个东西」悄悄跳过。本库 2 个存档共 2 处按 scripts/lpc_fix_save_dotc.py 改成 .lpc（只改 .lpc 存在而 .c 不存在的字符串；玩家存档、备份、留言板、巫师目录和文件索引缓存不动）。改动：/adm/daemons/languages/normal.o（1 处）、/data/std/user_ob/human/p/pdyx.o（1 处）（共 2 个存档）。

当铺 hochshop：赎回物品后“记住的物品”往前挪的循环用错了下标（2026-10-21，KB 06 §7.347）

当铺在玩家身上记着最多十件当出去的东西（REM_ITEM_PROP_ + DIGITS[n]），赎回一件之后后面的往前挪一位：for (j = i; j < my_item_num - 1; j++) me->set(REM_ITEM_PROP_+DIGITS[i], me->query(REM_ITEM_PROP_+DIGITS[i+1]));，循环变量 j 没用上，一直在写第 i 格，后面的格子根本没动，记录就乱了。改成 DIGITS[j] / DIGITS[j+1]。

工匠 artisan.lpc：my_tactic(int damage) 里的 victim 没赋值（2026-10-21，KB 06 §7.348）

attack_d 每回合调用 tactic_function(victim)（call_other(this_object(), tactic, victim)）。工匠的 my_tactic(int damage) 把对手声明成了 int，局部的 object victim 从未赋值，random(20)>10 的那几回合 victim->query("armor/shield") 抛错。改成 int my_tactic(object victim)，开头 if (!(victim = query_attacker())) return 0;（本库 teacher.lpc、mob_special.lpc 的写法）。改动：/d/eastland/mumar/monster/artisan.lpc。

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

计时器或输入提示给驱动的函数名和文件里定义的差一个字母；驱动对不存在的函数静默不理，所以对应的计时从来没有触发过。调用和配套的 remove_call_out() 改成已定义的拼法：idle_teme → idle_time。改动：/d/monk/guild/inner_room.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.，同一个动词的其他处理函数不再尝试（不是最新的一条就悄悄跳过）。删除了 7 条注册（6 个文件，scripts/lpc_fix_dead_add_action.py），动词留给别的处理函数：/d/eastland/liang_shan/monster/fish11.lpc（kill_me）、/d/eastland/saulin_temple/brass/zeng7.lpc（do_auction）、/d/eastland/story/monster/elder1.lpc（do_embattle）、/d/eastland/story/weapon/elder1.lpc（do_embattle）、/d/noden/hawk/obj/tape.lpc（do_cast、do_tear）、/std/npc2.lpc（quit）。最多的函数名：do_embattle 2 处、kill_me 1 处、do_auction 1 处、do_cast 1 处、do_tear 1 处。没有动（读过）：/d/noden/mj/emsd.lpc 的 do_gongxian（对象本身编译不过，登记留着，等对象能加载再处理）。

战斗探针（管理员克隆 NPC，2026-10-22）：干净

scripts/play_combat_probe.py esI --account ... --clone ...：用库里预置的管理员账号把 /d/eastland/liang_shan/monster/test, /d/noden/ruin/monster/deltazeus, /d/island/monster/lady, /d/island/samurai/mob/ekars, /d/eastland/volcano/monster/wjailor, /d/island/forest/monster/older 逐个克隆到自己所在的房间并各攻击 20 秒（读了 6 场战斗）：驱动没有输出，战斗画面里没有错误文字。（KB 08 §10.16）

log/ 下的日志子目录没有人建：写日志的 write_file() / log_file() 报错（2026-10-22，KB 06 §7.358）

这个库的代码往 log/ 的 1 个子目录写日志：log/harass（std/body.lpc）。压缩包、git clone 和站点包里都没有这些目录（本地启动没有写过它们，gen_keep_dirs.py 没记），write_file() 对不存在的目录抛 *Wrong permissions for opening file /log/dlog/money for append. "No such file or directory"，调用它的函数在写日志那一行中断，后面的奖励、标志、步骤都没有执行。本库的 log_file() 是 write_file(LOG_DIR + file, text)，目录不存在就抛同样的错误（实测）。把 log/harass 记进 scripts/wasm_keep_dirs.txt（scripts/lpc_keep_log_dirs.py；站点和 pristine 树按它建空目录）。证明（scripts/lpcc_eval.py，在 /adm/daemons 这类目录下的求值对象里写 /log/zzdirprobe/...，新进程）见 KB 06 §7.358 的实测表。

汉字按字节切片的老写法没有换成按字符：改法名 "澄" + 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] 是两个字），老算术原样留着、意思全变：NPC 的称呼和提示里取到两个字而不是一个字。

本库 2 处（2 个文件）：query("name")[..] 2 处。例：(string)ob->query("c_name"))[0..1] → (string)ob->query("c_name"))[0..0]（/d/eastland/easta/monster/taxman.lpc:98）。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，不要重跑。

长度检查按字节写，旁边的提示按汉字写：4 处（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 你好吗）。本库 4 处（3 个文件）：if (strlen(rn) > 14) {（/adm/daemons/newuserd.lpc:132）；if (strlen(ncname) > 14) {（/cmds/std/_chfn.lpc:85）。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 退步。

samurai dagger MSPECIAL 指向缺失 /u/（2026-10-27，KB 06 §7.359 Also）

d/island/samurai/obj/dagger.lpc 写 #define MSPECIAL "/u/m/mercury/obj/special"，档案无该巫师路径，驱动报 Inherited file ... does not exist。改为本库已有的特殊攻击基类 /d/eastland/goomay/obj/special（同文件头注释所述用途）。证明：HEAD 加载失败；改后加载成功。

深度功能测试（2026-10-27，§6.25 death_echoall 截断）

std/fun/death_echoall 同 es1 截断；同样收成空循环。证明：改后加载。