Fix: 少林寺任务8538寻找师兄链无法完成

[ArthurZhu1992]

问题：点击NPC国清(9310040)无反应，任务链中断

根因：

• NPC 9310040/9310052 缺少对话脚本导致NPCTalkHandler无响应
• 任务道具4031786/4031787未在Item.wz中定义，slotMax=0致道具无法创建

修复：

1. 新增 scripts/npc/9310040.js - 国清英文NPC对话(完成8538+接8539)
2. 新增 scripts/npc/9310052.js - 虚竹英文NPC对话(接8538+完成8539)
3. 新增 scripts-zh-CN/npc/9310040.js - 国清中文NPC对话
4. 新增 scripts-zh-CN/npc/9310052.js - 虚竹中文NPC对话
5. 修改 wz/Item.wz/Etc/0403.img.xml - 补全4031786/4031787最小化条目

[github-actions]

🤖 AI Code Review

Let me analyze this PR carefully. It's adding two quest NPCs for a "Searching for Senior Brother" quest chain in MapleStory v83 server, in both English and Chinese versions, plus adding the corresponding quest items to the WZ file.

Let me review:

1. NPC 9310040 (国清/Guoqing) - On Mount Song: Mountainside (702030000)
2. NPC 9310052 (虚竹/Xuzhu) - On Mount Song: Mahavira Hall (702100000)
3. Items 4031786 and 4031787 - Quest items for the chain

Let me check the logic flow:

9310040 (Guoqing/Senior Brother):

• Status 0:
  • If quest 8538 started AND has item 4031786: sendYesNo
  • Else if quest 8539 started: reminder message
  • Else: default message
• Status 1: Complete quest 8538
• Status 2: Start quest 8539, give letter
• Status 3: Thanks

9310052 (Xuzhu/Junior Brother):

• Status 0:
  • If quest 8538 completed AND quest 8539 started AND has item 4031787: questAction = "complete8539", sendNext
  • Else if quest 8539 completed: thank you
  • Else if quest 8538 started: hint about location
  • Else if quest 8538 not started and not completed: questAction = "start8538", sendYesNo
  • Else: default
• Status 1:
  • If complete8539: complete quest 8539
  • Else: start quest 8538
• Status 2: hint about location

Let me look for issues:

Potential Issues:

1. 🔴 High Severity - Quest 8538 completion without giving quest item:
   In 9310040, status 1, after cm.completeQuest(8538), there's no cm.gainItem(4031787, 1) to give the letter item! The 9310052 NPC checks cm.haveItem(4031787, 1) to proceed with completing quest 8539. So the quest flow would be broken - player completes 8538, starts 8539, but never gets the letter item needed to complete 8539.

2. 🔴 High Severity - Quest 8539 start without giving quest item:
   In 9310040, status 2, after cm.startQuest(8539), there's no cm.gainItem(4031786, 1) either. Wait, but 9310040 checks cm.haveItem(4031786, 1) to allow the player to complete quest 8538. So 4031786 must be given when 8538 starts (by 9310052). But 9310052 doesn't give 4031786 either! The flow is broken.

3. 🟡 Medium - The sendYesNo in 9310040 doesn't handle 'no' response:
   When player clicks "No" to the YesNo dialog, mode will be 0, which calls dispose, but the quest 8538 is never completed and the item isn't given. This might be intentional, but worth checking.

4. 🟢 Low - String comparison for questAction:
   Using string comparison questAction == "complete8539" works in JS, but using constants/enums would be cleaner. However, this is JavaScript-like scripting in MapleStory, so it's fine.

5. 🟢 Low - Item placement in 0403.img.xml:
   The new items 04031786 and 04031787 are placed BETWEEN the existing item 04031785 (with </imgdir> closing the previous item) and 04031788. The order of items in WZ files usually doesn't matter functionally, but they should be placed in numerical order. Let me check - the diff shows them placed in order (786 then 787), which is fine.

6. 🟡 Medium - Missing quest item icons:
   The new imgdir entries for 04031786 and 04031787 only have a quest=1 flag but no canvas name="icon" .... Other items in the file might need icons. Let me check... Actually looking at the diff, the existing 04031785 doesn't show its full content (it was already there), so we don't know if it has an icon. Items can exist without icons, so this may be fine.

7. **🟢 Low - The English version comment says "Mount Song" but the Chinese version also says "Mount Song" - this is consistent.

8. 🟡 Medium - Quest item 4031786 purpose unclear:
   The variable name says 4031786 is the "letter to junior" and 4031787 is the "letter to senior". But the comments don't specify which is which. Looking at the code, 4031786 is checked in 9310040 (the senior) and 4031787 is checked in 9310052 (the junior). So 4031786 might be a "letter to find senior" or "letter to senior" and 4031787 is the "letter from senior to junior" (the reply letter). Without proper item definitions, players can't see what they have.

Let me re-examine the flow:

Correct flow should be:

1. Player talks to 9310052 (Xuzhu/junior) - starts quest 8538, gives item 4031786 (a letter/picture to identify the senior)
2. Player goes to 9310040 (Guoqing/senior) at 702030000 - has item 4031786, completes quest 8538, starts quest 8539, gives item 4031787 (reply letter)
3. Player returns to 9310052 - has item 4031787, completes quest 8539

So the missing pieces are:

• 9310052 status 1, else branch: cm.gainItem(4031786, 1) is missing
• 9310040 status 2: cm.gainItem(4031787, 1) is missing

This is definitely a high severity bug because the quest chain is broken.

Let me also check: in 9310040, the condition is cm.isQuestStarted(8538) && cm.haveItem(4031786, 1) - this requires having item 4031786. But if 9310052 doesn't give 4031786, this can never be true. So yes, the quest is broken.

Also, the check for giving item 4031787 in 9310040 is missing.

Let me also look at:

• In 9310040, after completeQuest(8538) in status 1, the message says "Come find me again later" - this is shown BEFORE the actual letter-giving dialogue. This is a bit confusing because the next message is "My junior sent you?" suggesting the player already talked to the junior. The flow would be:
  • Player clicks Yes on YesNo
  • Sees "Thank you, come find me again later"
  • Sees "My junior sent you?"
  • Sees "Thank you"

This is a bit awkward but not broken.

Actually, looking more carefully at the flow, after clicking Yes, status becomes 1, completeQuest(8538) is called, then the "thank you" message is shown. When player clicks next, status becomes 2, quest 8539 starts, "my junior sent you" message shows. This makes sense actually - the senior is thanking the player, then realizing the player is from his junior, and giving the letter.

But still, the missing cm.gainItem() calls are a critical bug.

Let me also check the items in 0403.img.xml - they don't have proper icons, but this might be okay if they're placeholder quest items that work through the script alone.

One more thing - in 9310052, the check for cm.isQuestCompleted(8538) && cm.isQuestStarted(8539) is good defensive logic. But the check for 4031787 might need to be moved earlier or the logic reordered.

Let me check the structure of 9310052 once more:

• Has 4031787, quest 8538 done, quest 8539 in progress → complete quest
• Quest 8539 done → thanks
• Quest 8538 in progress (no 4031787) → hint
• Quest 8538 not started and not completed → start quest
• Else → default

This is okay defensive logic.

But what about: Quest 8538 in progress AND has 4031787? This shouldn't happen normally, but if it did, the "hint" branch would be taken, which is fine. Actually wait, that's not quite right - if 8538 is started and they have 4031787, the 8538 is not yet completed, so they shouldn't have 4031787. The hint message is appropriate.

Wait, but in 9310040, the check is cm.isQuestStarted(8538) && cm.haveItem(4031786, 1). This means 8538 is started. So if 4031786 is given when 8538 starts, this is consistent.

Let me check if 4031786 and 4031787 should be cm.gainItem somewhere:

Looking at the actual quest flow:

• 9310052 start8538 (status 1, else branch): should give 4031786
• 9310040 complete8538 (status 1): should give 4031787 after startQuest(8539) (in status 2)

The missing gainItem calls are clearly bugs.

Let me also look at the WZ file - the new items 04031786 and 04031787 only have quest=1 set but no other info. They should at least have basic info or they'll be invisible to the player. Actually, this might be okay if the server doesn't require icons for quest items - but typically quest items need to be displayable.

Actually, looking at the diff more carefully:

+  <imgdir name="04031786">
+    <imgdir name="info">
+      <int name="quest" value="1"/>
+    </imgdir>
+  </imgdir>
+  <imgdir name="04031787">
+    <imgdir name="info">
+      <int name="quest" value="1"/>
+    </imgdir>
+  </imgdir>

These are very minimal. For comparison, let me think about what other quest items might have. Typically they have a name, description, icon, etc. This minimal definition might be okay for the WZ structure to load, but the items won't be displayable properly.

Actually, the diff doesn't show the full context - we only see what was added, not what other items look like. Looking at the diff for 04031788:

   <imgdir name="04031788">
     <imgdir name="info">
       <canvas name="icon" width="29" height="28">

This shows 04031788 has an icon. But 04031786 and 04031787 don't, which would be problematic.

But wait, this is a WZ file edit and we should focus on the code changes. The WZ file is a data file, not really "code" in the traditional sense. Still, it's part of the PR.

Let me also note that the items should probably also be registered somewhere in the quest scripts, not just the WZ. Looking at it, the items are referenced in the NPC scripts via cm.haveItem(4031786, 1) and cm.haveItem(4031787, 1). If these items don't exist in the database/server, the haveItem check would always return false, breaking the quest.

Looking at the issue list again:

Critical bugs:

1. Missing cm.gainItem(4031786, 1) in 9310052 when starting quest 8538
2. Missing cm.gainItem(4031787, 1) in 9310040 when starting quest 8539
3. Quest items in WZ file lack proper icon/name definitions

Medium issues:
4. The sendYesNo "No" path in 9310040 doesn't dispose properly - wait, it does, mode=0 disposes
5. The questAction global variable approach is a bit awkward but functional

Low issues:
6. Code duplication between English and Chinese versions (this is a general project pattern though)
7. Magic numbers (quest IDs) without constants

Let me finalize my review.

Actually wait, let me check if MapleStory scripts typically use cm.gainItem - yes, they do. The missing gainItem calls are definite bugs.

Let me also check the item ID range - 4031XXX is a quest item in MapleStory, so 4031786 and 4031787 are reasonable IDs.

OK, let me write the review.

📋 PR 概览

新增"寻找师兄"任务链的两个 NPC（国清/Guoqing 9310040 与 虚竹/Xuzhu 9310052），含中英双语脚本及对应的任务物品（4031786、4031787）。

⚠️ 潜在问题

🔴 高危

1. 任务物品发放完全缺失——任务链无法完成

• 9310052.js（虚竹/师弟）启动任务 8538 时，未通过 cm.gainItem(4031786, 1) 发放寻人信物。
• 9310040.js（国清/师兄）启动任务 8539 时，未通过 cm.gainItem(4031787, 1) 发放回信。

后果：玩家跟 9310052 领完任务后去 702030000 找 9310040，由于 cm.haveItem(4031786, 1) 永远为 false，第一个 YesNo 分支永远进不去；同理，完成 8538 后 4031787 也不会进包，任务 8539 永远无法完成。整条任务链是断的。

修复示意：

// 9310052.js status==1 else 分支
cm.startQuest(8538);
cm.gainItem(4031786, 1);   // ← 补上

// 9310040.js status==2
cm.startQuest(8539);
cm.gainItem(4031787, 1);   // ← 补上

2. WZ 物品定义残缺

0403.img.xml 中新增的 04031786/04031787 仅有 <int name="quest" value="1"/>，缺少 icon、name、desc 等必要字段。客户端在背包/任务栏查看时会显示空白或报错。建议至少补上 icon canvas，或参考 04031788 的格式补全。

🟡 中危

3. Yes/No 分支的"拒绝"结果未在对话中提示

9310040.js 玩家选 No 时直接 cm.dispose()，但在此之前应至少做一次"贫僧明白了"之类的回应，或与 Yes 分支保持对称的反馈，否则玩家会感觉 NPC 反应生硬（属于体验问题，不是逻辑 bug）。

4. 状态机未防御"已启动 8538 但物品已消耗/丢失"的边角情况

比如 9310052 中如果玩家身上意外存在 4031787 但 8538 未完成，会落到"else 默认语"，逻辑没问题；但反过来——当 8538 已完成、8539 已开始、但 4031787 已被丢弃时，无法恢复。建议把"补发回信"做成兜底分支，或在丢失时提示任务失败。

🟢 低危

5. 魔法数字 8538/8539/4031786/4031787 直接散落在脚本里

Maple 服脚本里写死 ID 是惯例，但若项目内有常量文件，建议集中管理，方便维护时检索。

6. questAction 用字符串作状态标记

var questAction = "";
...
if (questAction == "complete8539") { ... }

可用 0/1 等数字更轻量，且避免编码不一致风险（不阻塞，纯风格建议）。

7. 中英两份脚本完全平铺重复

双语同步是项目既定约定，没问题；但如果将来对话文案调整需要改两遍，建议引入脚本生成器或共享字符串常量表。

💡 改进建议

1. 优先修复任务链断点：在两处 startQuest 之后立即 cm.gainItem 对应物品，并在两处 NPC 中加入"物品缺失时重新发放"的防御分支（如 if (cm.isQuestStarted(8538) && !cm.haveItem(4031786)) cm.gainItem(4031786, 1);）。
2. 补全 WZ 物品定义：给 04031786/04031787 加上 icon canvas、name 字符串（"国清师兄的信物"/"国清师兄的回信"）以及 desc，否则玩家在背包里看到的是空格子。
3. 抽取公共部分：将 9310040 / 9310052 中"取任务状态→分派物品→完成/推进任务"的状态机抽成公共函数（如 tryCompleteChain(questId, itemId)），减少重复、提升可读性。

📊 评分

维度	分数	说明
代码质量	2/5	状态机结构清晰，但 gainItem 关键调用遗漏直接破坏了功能
安全性	4/5	NPC 脚本无注入风险，isQuestStarted/Completed/haveItem 防御性条件较完善
可维护性	3/5	注释齐全、双语规范，但缺乏物品/任务 ID 常量化，且缺失兜底逻辑

总评：功能框架写得不错，但当前 PR 存在会让任务链完全跑不通的硬伤（缺两处 gainItem + WZ 物品字段残缺），不建议合入主线，需先修复再 review。