奇遇——什么触发它们，什么堵死它们，以及它们给什么

奇遇不是你去接的任务。从你建号那一刻起，每一个奇遇就已经挂在你角色身上跑着了，日志页只显示你已经撞上过 的那些。这一页讲的是，按游戏自己的数据：每个奇遇由什么触发、进入条件实际检查的是什么，以及122个里有哪些是 随包发出的数据给不出来的。

奇遇是一条记录，而且你从建号起就全都有了

建号时游戏遍历整张任务表，把接取检查通过的每一个奇遇和每一个悬赏解密全部接下来。这两个类型的接取 检查都是一个恒为真的常量（PlayerQuest.Init、CanAcceptQuest）。同一个循环在每次读档结束时还会再跑 一遍，所以补丁新加的奇遇，老角色下次读档就会有。

数据里有122个奇遇和61个悬赏解密。运行中的角色，实时列表里显示的是121和60，因为两边各有一个已经 自动完成了（不是你做过的奇遇，是没有内容的占位行）。

玩起来真正有影响的几点：

• 没有任何一个有时限。 奇遇和悬赏解密都不带时限，游戏对普通任务跑的超时检查明确跳过这两个类型 （UpdateAutoFinishQuest）。
• 它们不出现在任何任务列表里。 任务追踪、地图和HUD用的那个查询会把这两个类型从返回结果里全部滤掉 （PlayerQuest.GetQuestLogByType），所以奇遇从来不会有指引箭头，地图也不会指向它。
• 没有一个给完成奖励。 122个的奖励组都是空的。奇遇给你的东西都在链条中途发放：要么通过你选的对话选项， 要么通过挂在某一步上的物品。
• 没有一个会接着触发另一个任务，也没有一个强制自动存档。

日志只列出你已经碰过的奇遇

奇遇页由PlayerQuest.GetQiyuShowQuestLog生成，只有至少一步已经被记录的奇遇才会留下。在那之前它就在 后台跑着，你看不见。这一页按地区分组，页签就是奇遇自己的地区标签，所以那五个没有地区标签的奇遇，永远 不会出现在上面。

触发机制

每个奇遇是一组编号的步骤。一步就是一行，带一个条件表达式、一个可选的前置步骤，以及可选的副作用（给物品、 收物品、跑脚本、改属性）。122个奇遇一共685行。

表达式。 开头一个标志位决定是所有子句都要成立，还是任意一条成立即可（645行要求全部，39行要求任意）。 每个子句是一个类型id加参数，子句末尾加!可以取反，不过本版本里没有奇遇用到取反。

奇遇这条路径上只认17种子句类型。 ConditionPrototype.GetNewConditionType只把游戏约130个条件id里的 十七个映射成奇遇求值器看得懂的东西；其余全部落到NewConditionType.None，而求值器的默认分支返回false。 122个奇遇实际用到的子句全都在这十七个之内（838条全查过），所以没有东西因为这个原因失效。

十七个里只有十一个真的被用到。 这就是本版本奇遇触发条件的全部词汇：

重点在这张表上没有的东西。 本版本里没有任何奇遇卡时辰、卡日期、卡好感或情分、卡门派身份或门派好感、 卡境界，也不卡任何战斗属性。让你晚上再来、或者等节日的攻略，说的是别的东西。

检查在什么时候跑

求值器不是轮询的。有两条路径把它唤醒：

• 带键的触发。 游戏记录一次击败NPC、击杀NPC、拾取物品、与NPC交互、一次闲谈播完，或一段对话显示时， 会拿这个事件去查一张索引——索引在读档时由所有奇遇条件建起来（QuestPrototype.RegisterCondDef、 PlayerQuest.DispatchQiyuByTrigger）——然后只重算为这个事件和这个值注册过的奇遇。八种子句类型会建 索引项，其余的不建。
• 按类型全扫。 有六个事件会扫过所有条件位掩码里包含该子句类型的、正在运行的奇遇 （DispatchQiYuConditionCheck）：打碎物件、书信结算、你任意一项属性字段发生变化、获得一个技能光环、 挥出一次普攻、切换武器类别。第七个进队列，由任务的每帧更新拿出来跑，一帧一次。

走路、时间流逝、打开菜单：这些都推不动任何东西。

对话记录是在窗口打开时写的，不是关闭时写的（NpcChatView.ShowNpcTalk调用 SocialManager.AddPlayerAutoTalk），之后奇遇的派发会延迟半秒，并且一直压到没有别的UI打开为止 （SocialManager.WaitSendEvent）。那些「关掉对话框之后过一会儿」才推进的奇遇，就是这么回事。

闲谈：20米，播到哪一组是五五开

全表57条子句、122个入口里的42个，都是听到一段闲谈，也就是社区说的「站在NPC旁边听他自言自语」。这个描述 完全正确。

机制从NpcBubbleChatRegulator和BubbleChatData里读出来是这样：

• 每个有闲谈的NPC（共1,694个）都带着一张闲谈组列表，游戏在世界加载时给这个NPC随机挑一组， 每播完一组就重新随机一次。如果这个NPC有两组而你要的是其中一组，那每一轮都是五五开。
• 气泡只在你处于20单位以内、且没有加载画面、黑屏、交互面板、过场或别的窗口挡着、你也不在已被发现的 战斗中时才会播。
• 每行文字按折行后的每一行显示3.5秒，一组播完后该NPC要等10秒冷却才开始下一组。
• 奇遇是在这一组播完时触发，不是第一行。中途走开就重来。
• 被奇遇监听的44个不同闲谈组，本身没有任何门槛：没有显示条件，也没有停止条件。站得够近、等得够久，就是 全部要求。

对话选项：显示、隐藏，还是置灰

另一大类入口，是一个只有你达成条件后才存在的对话选项。这些是交互表里的行，永远在交谈组里，类型永远是 脚本；头顶标记依据的就是这个：一个NPC头上出现奇遇图标，是因为他至少有一条这样的行，显示条件通过而 隐藏条件没通过（UnitHead、RefreshUnitHeadQuestInfo）。

三个条件位，各干各的：

求值这几个位的不是奇遇那十七项的子集，是游戏完整的那套条件分支，二级门槛就在这里。金钱门槛、门派好感、 好感、境界之类都可以卡住启动奇遇的那个选项，尽管它们永远不能直接卡住奇遇的某一步。比如万事通的传闻选项， 身上超过1,600银两之前是锁着的。

奇遇标记会被任务标记压掉。 同一条判断链里先测主线和支线图标，所以一个同时是当前任务目标的NPC，哪怕 身上有奇遇等着，也不显示奇遇图标。

为什么每个奇遇的步数是它实际环节数的两倍

步骤是成对的。奇数那步没有前置，重复上一对的条件；偶数那步带前置和下一个条件。奇数行的作用是弹提示和 显示指引：它的日志文字末尾有一句带颜色的话告诉你下一步做什么，偶数行是同一段文字，把那句指引换成了结果。

规则在QuestLog.CheckQiYuCond里：新记录的步骤没有前置时，弹灵光一现的闪光并进通知列表；带前置 的步骤静默入档。没有地区标签的奇遇，两样都不发生。

顺序、分支，以及什么会把一个奇遇堵死

顺序是按步定的。 685步里有342步写了前置步骤，另外343步可以任意顺序满足。前置未满足的步骤 是死的，它的条件不会被读。

一步就能结束整件事。 有85步带强制完成标志：这样的步骤一被记录， ConditionPrototype.IsQiYuGroupAchieved就返回真，不管还有什么没做完，奇遇直接完成。49个奇遇正好有 一步这样的步骤，16个有两步或更多，这些就是结局互斥的那些：爱吃鱼的狗、云鹤疑云、月下剑舞、 盗圣珍宝、何仇何怨、光头侠客、婚宴惊变、水贼肆虐、小鬼难缠、瓜保熟吗（五个结局）、除魔卫道、寒门书生、 险途崎岖、善人善粥、慈悲为怀、何为菩提。

你没走的那条分支永远空着。 普通任务完成时，游戏会把它剩下的条件全部标成已达成。对奇遇则特意不这么做 （QuestLog.OnFinish），所以另一个结局的日志条目永远不会补上，奇遇也不会为它们重新开启。

57个奇遇没有强制完成步骤，每一步都要记录到。

真正会永久堵死一个奇遇的是什么。 本版本里没有任何奇遇步骤带时限或动态可见性标志，所以那套永久隐藏 步骤的机制对它们从不适用。真正堵死一个奇遇的，是把那个你还需要他对话选项的NPC杀了，是在双结局的链条里 走错了分支，或者，对那64条要求你身上带着某件物品的子句，在子句被检查之前把那件物品卖了或用了——它读的 不是你的历史记录，是你的背包。（悬赏解密的线索卡读的反而是历史记录；见下。）

十一个开不了，一个走不了，还有一个读错了记录

这些都是从数据里读出来的：

十一个奇遇有名字、有地区，步骤是零。 昂贵的秘籍、论道会友（云鹤村）；寸草不生、流云之试（枰栌）； 焦尾琴、服气辟谷、臭棋篓子（淮陵）；嚣张跋扈、进献之宝（豫京）；遭劫掠的货商、梅花傲雪（雁州）。它们的 条件组是空的。出生就接下了，没有任何事件能派发到它们，也永远不会出现在日志里。这不是你漏了什么， 是没做完的内容。

另有五个既没有名字也没有地区标签，是内部记录：两个是「用枪 / 空手普攻50次」的标记，一个是击杀计数， 一个等一段对话，还有一个卡在英雄榜主线的某一步后面。这五个都不会在日志里显示，也都不弹灵光一现的闪光， 因为没有标签的奇遇那条通知是被屏蔽的。

那个按击杀数算的奇遇，键值写错了。 它唯一一步要求累计击杀数达到1。这条子句注册的触发键是 (kill, <所需数量>)，而不是一个NPC id（QuestPrototype.RegisterCondDef），而这个子句类型又从来不会被 全扫派发到，所以它只有在你杀了原型id恰好是1的那个NPC时才会触发。

全部奇遇里唯一一步不是条件表达式的步骤，在险途崎岖里。 那是一步「走到(1398, 955)」，而奇遇求值器不读 这种步骤：它遍历解析出来的子句列表，发现是空的，就把这一步标成已达成 （ConditionPrototype.UpdateNewAchievedState）。于是这一步挂着的脚本，在它的前置（杀掉那五只狼）满足的 瞬间就跑了，不管你人站在哪。社区反映这个奇遇会卡住；真要修，要处理的就是这个机制。

伐木之斧的第一步，读的是一条从来不会被写入的记录。 它开头的子句要求对话956961已经显示给你。956961 不是一句对话：它是杨淳雄的闲谈自语（对话类型4，组2154）。听到一段闲谈，写进去的是「已发生闲谈」列表里的 组号；它不会把这一句写进「已显示对话」列表，而后者才是这条子句读的东西。685步奇遇里，这是唯一一条把 两种记录交叉的子句，而它正好就是社区点名说坏掉的那个奇遇。这个NPC自己的对话选项要的是闲谈，写法是对的， 所以链条能走，强制完成那一步够得着；只是奇遇的第一条日志永远不会开。

有三个奇遇，通过一个「收回物品会抛异常」的选项发东西。 全游戏有五行交互把「移除物品」列表用&分隔， 而解析器按;切这个字段（InteractSlot.DoInteactAddOrRemoveItems）。紧接着的整数解析在保护「添加物品」 那一半的try块外面。于是：物品发下来了，异常抛出，材料从没被收走，而关闭对话的回调没有被清掉，所以你 下一次关对话时它还会再跑一次、再抛一次。这五行是居胥的拿出云母和材料我已收集齐了（伐木之斧）、沈悠的 拿出胡杨木和狼背筋（江海图志·雁州），以及岑不龄和师寒的交付选项（岑家嫁女）。拿出云母还要收走十个云母、 十个赤铜和十个昆吾石，而这个选项自己的要求只是三个云母，别的都没有。

悬赏解密是一块推理板，不是任务链

61条记录，其中48条有内容，13条是空占位。它们永远不会靠条件完成：完成检查对这个类型直接返回false （PlayerQuest.CanFinishQuest）。只有把板子解开才算完成，而解开会强制完成它们。

一块板子是怎么运作的：

1. 线索到手。 一个悬赏解密列出2到8张线索卡。一张卡在它自己的显示条件通过时可见，全表只有三种这样的 条件：你听过某段指定对话（94张）、你曾经获得过某件指定物品（57张）、某个指定闲谈组播过 （26张）。物品那一条读的是你的终身获得记录，所以把东西卖了不会丢线索。卡一旦解锁就永久缓存。
2. 配对。 每张卡写明它能和哪些卡匹配。一组卡放到一起会被拒绝，除非组里每张卡都和其余每一张互相匹配， 并且这一组的张数正好等于第一张卡的匹配列表要求的张数（JieMiViewTuiLun.CheckTuiLun）。
3. 答题。 配对成功且挂了问题的那一组会出四个答案，其中一个对。
4. 所有配对都答对 → 解开，任务被强制完成。答错只播失败动画，板子还开着，所以乱猜没有任何损失。

全表只有一个悬赏解密带完成奖励组；回报就是剧情，外加那些线索物品本身。

那十三块武学传闻板打不开。 风神腿、排云掌、天霜拳、伤心小箭、天罡童子功、弹指神功、孔雀翎、天外飞仙、 幻箭诀、追星赶月、柳叶刀、惊武回风拳和火雷引各有两张线索卡，26张卡的解锁条件都是一个闲谈条件，而它指向 的对话id却是一句普通对话，组号是0。两个线索求值器都会把这个id解析成它的闲谈组，再问这个组播过没有； 游戏里没有哪个NPC挂着0号组，所以答案永远是没有。整张表里指向真实组号的闲谈线索条件，一个也没有。这些 武学本身是能拿到的（社区给的路线是在具名NPC处的脚本任务链，其中惊武回风拳就是光头侠客这个奇遇交给你的）， 但这一层推理内容在发行版本里够不着。

48块真板子，以及解锁各自线索卡的条件：

整个系统里仅有的数值门槛

三条具名链条下的五条奇遇记录会卡玩家属性。这就是奇遇里全部的硬性数值要求：

你任意一项属性字段变化时它们都会重新检查，所以过线的那一刻就开，不用等切地图或者过一天。

社区的说法，哪些站得住

对照过52PK的枰栌列表、 游侠网的枰栌和 雁州列表、 游民星空的枰栌攻略，以及 九游的「有什么奇遇」。

社区资料里没有一处提到：122个奇遇从建号起就全在跑；没有一个给完成奖励；其中十一个完全没有内容；十三块 悬赏解密板打不开；以及好感、门派好感、日期和时辰在全游戏范围内不卡任何一步奇遇。

这些是从哪里读出来的

PlayerQuest.Init / CanAcceptQuest / AcceptQuest / CanFinishQuest / FinishQuest / DispatchQiyuByTrigger / DispatchQiYuConditionCheck / GetQiyuShowQuestLog / GetXuanshangJiemiQuestLogs / GetQuestLogByType / UpdateAutoFinishQuest / Load， QuestLog.CheckQiYuCond / GetAllQiYuCondType / OnFinish / CheckJieMiShowCond / CheckHaveOneJiemiItemCanShow，QuestPrototype.RegisterCondDef / RegisterTrigger / ParseXuanShangJieMiShowConds，ConditionPrototype.ParseNewCondition / GetNewConditionType / CheckOneNewCondDef / UpdateNewAchievedState / IsQiYuGroupAchieved / IsCanShow / OnAchieved， ConditionCheck.IsMatchConditions / CheckETC_Bubble / CheckETC_Item_Geted / CheckConditionSocial， QuestJieMi.CheckStrShowCondition，JieMiViewTuiLun.CheckTuiLun， NpcBubbleChatRegulator / BubbleChatData，SocialManager.AddPlayerAutoTalk / WaitSendEvent， NpcChatView.ShowNpcTalk / OnClickClose，InteractSlot.Handle_IT_SCRIPT / DoInteactAddOrRemoveItems，UnitHead.RefreshUnitHeadQuestInfo，以及表questprototype、 condition_group、questjiemi、npc_interact、dialoguelist、npc_prototype、item_base、 loot_items。

哪些在游戏里核对过，哪些没有。 有两件事对着运行中的游戏确认过：实时的任务计数（121奇遇 / 60悬赏解密， 对表里的122 / 61，存档文件点出了那两个自动完成的占位），以及对话选项的模型。从修改器的交互接口读到，邢泰 给出的正好是数据里为丢失的手镯准备的那两个奇遇选项，一个显示，一个因为缺物品而不给；万事通身上的传闻选项， 显示/隐藏的模式也和表预测的一致。

其余全部是读代码和数据得出的，没有实测：20单位的闲谈半径和它的各项计时、四条坏掉的记录、悬赏解密的 线索门槛，以及下面表里每一行的入口。其中两项最值得先测，因为读错的代价最大：伐木之斧在记录交叉的情况下 究竟能不能被强制完成；以及那十三块武学推理板，有没有哪条数据里看不到的路子能打开。

有一件事数据说不了。 685步里有34步在完成时会跑一段挂着的脚本，这些脚本在asset bundle里，不在可读的 表里。下面表里某条链没列出奖励的，多半就是去了那儿。

数据里的每一个奇遇

122行，按日志用的地区标签分组。步数是这条链有多少条日志行，大约是你实际要做的事情的两倍。 怎么开始是第一个没有前置的步骤，回溯到给出它的那个NPC；坐标是原型表里那个NPC出生点的x,z，NPC会走动， 所以把它当成一个找人的范围。沿途给你什么只列出由某一步、或推进它的那个对话选项 直接发放的物品；有几条链还会额外抽取的通用宝箱掉落组不列，挂着的脚本发的东西也不列。

有两条要配合上面那一节读：伐木之斧在游戏里是从(1511, 1063)的杨淳雄的闲谈开始的，但它读的是奇遇看不到的 那条记录；险途崎岖的护送步骤是自动满足的。

无地区标签

云鹤村

枰栌

豫京

淮陵

雁州