奇遇 — what fires them, what closes them, and what they pay

A 奇遇 is not a quest you accept. Every one of them is already running on your character from the moment you create it, and the journal page only shows the ones you have already stumbled into. This page is what the game's own data says fires each of them, what the entry conditions actually check, and which of the 122 the shipped data cannot deliver.

A 奇遇 is a record, and you own all of them from birth

At character creation the game walks the whole quest table and accepts every 奇遇 and every 悬赏解密 whose accept check passes. For both types the accept check is a constant that is always true (PlayerQuest.Init, CanAcceptQuest). The same loop runs again at the end of every save load, so a 奇遇 added by a patch appears on an old character the next time you load.

The data holds 122 奇遇 and 61 悬赏解密. A running character shows 121 and 60 in its live lists because one of each has already self-completed (content-free placeholder rows, not encounters you did).

Consequences that matter while playing:

• Nothing is on a clock. No 奇遇 or 悬赏解密 carries a time limit, and the timeout check the game runs on ordinary quests explicitly skips both types (UpdateAutoFinishQuest).
• They are hidden from every quest list. The lookup the tracker, the map and the HUD use filters both types out of everything it returns (PlayerQuest.GetQuestLogByType), which is why a 奇遇 never gets a guidance arrow and why the map will not point at one.
• None of them pays a completion reward. All 122 have an empty reward group. Everything a 奇遇 gives you, it gives you mid-chain, through the conversation option you pick or through an item grant attached to one of its steps.
• None of them chains into another quest, and none forces an autosave.

The journal only lists 奇遇 you have already touched

The 奇遇 page is built from PlayerQuest.GetQiyuShowQuestLog, which keeps a 奇遇 only if at least one of its steps has already been recorded. Until then it is running invisibly. The page is grouped by region and the tab is the 奇遇's own region tag, so the five 奇遇 with no region tag can never appear on it at all.

The trigger machinery

Each 奇遇 is a group of numbered steps. A step is one row carrying a condition expression, an optional prerequisite step, and optional side effects (items in, items out, a script, an attribute change). 685 rows across the 122 奇遇.

The expression. A leading flag says whether all the clauses must hold or any one of them (645 rows require all, 39 require any). Each clause is a type id plus parameters, and a clause can be negated with a trailing !, though no 奇遇 in this build uses negation.

Only 17 clause types are understood on the 奇遇 path. ConditionPrototype.GetNewConditionType maps exactly seventeen of the game's ~130 condition ids onto something the 奇遇 evaluator can check; everything else falls through to NewConditionType.None, and the evaluator's default branch returns false. Every clause the 122 奇遇 actually use is one of the seventeen (all 838 checked), so nothing is dead on that account.

Eleven of the seventeen are used at all. This is the whole vocabulary of 奇遇 triggers in this build:

What is not in that list is the point. No 奇遇 in this build is gated on time of day, on the calendar, on 好感 or 情分, on sect membership or sect standing, on 境界, or on any combat attribute. Guides that tell you to come back at night or wait for a festival are describing something else.

On what clock the check runs

The evaluator is not polled. Two paths wake it:

• A keyed trigger. When the game records a beaten NPC, a killed NPC, an item pickup, an NPC interaction, a finished 闲谈, or a shown dialogue, it looks the event up in an index built at load from every 奇遇 condition (QuestPrototype.RegisterCondDef, PlayerQuest.DispatchQiyuByTrigger) and re-evaluates only the 奇遇 that registered for that exact event and value. Eight clause types build an index entry; the rest do not.
• A type sweep. Six events sweep every running 奇遇 whose condition bitmask includes that clause type (DispatchQiYuConditionCheck): smashing an object, a letter resolving, any change to one of your attribute fields, gaining a spell aura, swinging a basic attack, and changing weapon class. A seventh is queued and run once a frame from the quest tick.

Walking somewhere, the clock, opening a menu: none of these moves anything.

The dialogue record is written when the window opens, not when it closes (NpcChatView.ShowNpcTalk calling SocialManager.AddPlayerAutoTalk), and the 奇遇 dispatch is then deferred half a second and further held until no other UI is open (SocialManager.WaitSendEvent). A 奇遇 that ticks over "a moment after you close the box" is doing exactly that.

闲谈: 20 metres, and which line you get is a coin flip

57 clauses across the table, and 42 of the 122 entry points, are an overheard 闲谈, the community's "stand near the NPC and listen to them mutter". That description is exactly right.

The mechanics, read out of NpcBubbleChatRegulator and BubbleChatData:

• Each NPC that has 闲谈 at all (1,694 of them) owns a list of 闲谈 groups, and the game picks one at random for that NPC at world load and re-rolls it every time one finishes. If the NPC has two groups and you need one of them, that is a coin flip per cycle.
• The bubble only runs while you are within 20 units and no loading screen, black screen, interaction panel, cutscene or other window is up, and you are not in sighted combat.
• Each line shows for 3.5 seconds per wrapped row, and there is a 10-second cooldown after a group completes before that NPC starts another.
• The 奇遇 fires on the group completing, not on the first line. Walking away mid-bubble resets it.
• All 44 distinct 闲谈 groups a 奇遇 listens for are themselves ungated: no show condition, no stop condition. Proximity and patience are the whole requirement.

The conversation option: shown, hidden, or greyed out

The other big entry class is a conversation option that only exists once you have earned it. These are rows in the interaction table, always in the 交谈 group and always of the script type, and the nameplate marker keys off exactly that: an NPC gets the 奇遇 icon over their head when they have at least one such row whose show-condition passes and whose hide-condition does not (UnitHead, RefreshUnitHeadQuestInfo).

Three condition slots, and they do different jobs:

Those slots are evaluated by the game's full condition switch, not the seventeen-entry 奇遇 subset, and that is where the second-order gating lives. Money thresholds, sect standing, 好感, realm and the rest can gate the option that starts a 奇遇 even though they can never gate a 奇遇 step directly. 万事通's rumour options, for instance, are locked until you carry more than 1,600 银两.

The 奇遇 marker loses to the quest markers. Main-quest and side-quest icons are tested first in the same chain, so an NPC who is also a live quest target shows no 奇遇 icon even when they have one waiting.

Why every 奇遇 has twice as many steps as it has beats

The steps come in pairs. The odd one has no prerequisite and repeats the previous pair's condition; the even one carries the prerequisite and the next condition. The odd row exists to fire the notification and to display the hint: its journal text ends with a coloured sentence telling you what to do next, and the even row is the same text with the hint replaced by the outcome.

The rule is in QuestLog.CheckQiYuCond: a newly recorded step with no prerequisite pops the 灵光一现 flash and goes on the notify list; a step with a prerequisite is filed silently. And neither happens for a 奇遇 with no region tag.

Ordering, branches, and what closes a 奇遇 off

Order is per-step, not global. 342 of the 685 steps name a prerequisite step; the other 343 can be satisfied in any order. A step with an unmet prerequisite is inert; its condition is not even read.

One step can end the whole thing. 85 steps carry a force-finish flag: the moment such a step is recorded, ConditionPrototype.IsQiYuGroupAchieved returns true and the 奇遇 completes regardless of what else is outstanding. 49 奇遇 have exactly one, and 16 have two or more, marking the ones with mutually exclusive endings: 爱吃鱼的狗, 云鹤疑云, 月下剑舞, 盗圣珍宝, 何仇何怨, 光头侠客, 婚宴惊变, 水贼肆虐, 小鬼难缠, 瓜保熟吗 (five endings), 除魔卫道, 寒门书生, 险途崎岖, 善人善粥, 慈悲为怀, 何为菩提.

The branch you did not take stays blank forever. When an ordinary quest finishes, the game marks all its remaining conditions achieved. For a 奇遇 it deliberately does not (QuestLog.OnFinish), so the other ending's journal entries never fill in and the 奇遇 cannot be resumed for them.

57 奇遇 have no force-finish step at all and need every step recorded.

What actually closes one off permanently. No 奇遇 step in this build has a time limit or a dynamic visibility flag, so the mechanism that permanently hides a step never applies to them. What closes one off is killing the NPC whose conversation option you still needed, taking the wrong branch of a two-ending chain, or, for the 64 clauses that ask you to be holding an item, selling or using that item before the clause is checked, since it reads your bag, not your history. (悬赏解密 clue cards read history instead; see below.)

Eleven that cannot start, one that cannot be walked, and one that reads the wrong record

Read out of the data rather than reported:

Eleven 奇遇 have a named title, a region, and zero steps. 昂贵的秘籍, 论道会友 (云鹤村); 寸草不生, 流云之试 (枰栌); 焦尾琴, 服气辟谷, 臭棋篓子 (淮陵); 嚣张跋扈, 进献之宝 (豫京); 遭劫掠的货商, 梅花傲雪 (雁州). Their condition group is empty. They are accepted at birth, no event can ever dispatch them, and they can never appear in the journal. Unfinished content, not something you missed.

Five more have no name and no region tag and are internal records: two are the "attack 50 times with a spear / with bare hands" markers, one is a kill counter, one waits on a single dialogue, and one is gated behind a step of the 英雄榜 main quest. None can show in the journal, and none of them pops the 灵光一现 flash, because that notification is suppressed for untagged 奇遇.

The kill-count 奇遇 is mis-keyed. Its only step asks for a cumulative kill count of 1. That clause registers a trigger keyed on (kill, <the required count>) rather than on an NPC id (QuestPrototype.RegisterCondDef), and nothing ever dispatches that clause type by sweep, so it can only fire if you kill the NPC whose prototype id is literally 1.

险途崎岖 contains the only step in any 奇遇 that is not a condition expression. It is a "walk to (1398, 955)" step, and the 奇遇 evaluator does not read that kind of step: it iterates the parsed clause list, finds it empty, and marks the step achieved (ConditionPrototype.UpdateNewAchievedState). The step's attached script therefore runs as soon as its prerequisite (killing the five wolves) is met, wherever you happen to be standing. The community reports this 奇遇 as one that hangs; this is the mechanism a fix would have to address.

伐木之斧's first step reads a record that is never written. Its opening clause asks that dialogue 956961 has been shown to you. 956961 is not a conversation line: it is 杨淳雄's 闲谈 mutter (chat type 4, group 2154). Overhearing a 闲谈 writes the group into the happened-chats list; it does not write the line into the shown-dialogues list, which is what this clause reads. Across all 685 奇遇 steps this is the only clause where the two records are crossed, and it is the 奇遇 the community singles out as broken. The NPC's own conversation option correctly asks for the 闲谈, so the chain is playable and its force-finish step is reachable; the 奇遇's first journal entry never opens.

Three 奇遇 hand out an item through an option whose take-back throws. Five interaction rows in the whole game write their remove-items list with & between entries, and the parser splits that field on ; (InteractSlot.DoInteactAddOrRemoveItems). The bare integer parse that follows is outside the try block that guards the add-items half. So: the item is granted, the exception fires, the materials are never taken, and the dialogue-close callback is left un-cleared so it runs and throws again on the next dialogue you close. The five rows are 居胥's 拿出云母 and 材料我已收集齐了 (伐木之斧), 沈悠's 拿出胡杨木和狼背筋 (江海图志·雁州), and 岑不龄's and 师寒's hand-over options (岑家嫁女). 拿出云母 also asks to take ten 云母, ten 赤铜 and ten 昆吾石 where the option's own requirement is three 云母 and nothing else.

悬赏解密 is a deduction board, not a quest chain

61 records, of which 48 carry content and 13 are empty placeholders. They never complete by condition: the finish check returns false for the type outright (PlayerQuest.CanFinishQuest). They complete only by solving the board, which force-finishes them.

How one works:

1. Clues arrive. A 悬赏解密 lists 2–8 clue cards. A card becomes visible when its own show condition passes, and there are only three of those in the whole table: you have heard a specific dialogue (94 cards), you have ever obtained a specific item (57), or a specific 闲谈 group has played (26). The item clause reads your lifetime acquisition record, not your bag, so selling the item does not lose the clue. Once a card unlocks it is cached permanently.
2. You pair them. Each card names the cards it matches. Dropping a set together is rejected unless every card in it matches every other, and unless the set is exactly the size the first card's match list expects (JieMiViewTuiLun.CheckTuiLun).
3. You answer. A matched pair with a question attached puts up four answers, one right.
4. All pairs right → solved, and the quest is force-finished. Wrong answers play the failure animation and leave the board open, so nothing is lost by guessing.

Only one 悬赏解密 in the table carries a completion reward group; the payoff is the story and whatever the clue items themselves were.

The thirteen martial-arts rumour boards cannot be opened. 风神腿, 排云掌, 天霜拳, 伤心小箭, 天罡童子功, 弹指神功, 孔雀翎, 天外飞仙, 幻箭诀, 追星赶月, 柳叶刀, 惊武回风拳 and 火雷引 each have two clue cards, and all 26 cards unlock on a 闲谈 condition pointing at a dialogue id that is a plain conversation line with group 0. Both clue evaluators resolve that id to its 闲谈 group and ask whether that group has played; no NPC in the game owns group 0, so the answer is always no. There are zero 闲谈 clue conditions in the entire table that point at a real group. The moves themselves are obtainable (the community's routes to them are scripted quest chains at named NPCs, and one of them, 惊武回风拳, is handed over by the 光头侠客 奇遇), but this deduction tier is unreachable as shipped.

The 48 real boards, with what unlocks their cards:

The only numeric prerequisites in the system

Five 奇遇 records across three named chains gate on a player attribute. These are the whole of the hard numeric requirements anywhere in 奇遇:

They re-check on every change to any of your attribute fields, so they open the moment you cross the line rather than on a zone or a day boundary.

What the community says, and what survives

Checked against 52PK's 枰栌 list, 游侠网's 枰栌 and 雁州 lists, 游民星空's 枰栌 guide and 九游's "有什么奇遇".

Nothing in the community material mentions that all 122 are running from character creation, that none of them pays a completion reward, that eleven of them have no content at all, that thirteen 悬赏解密 boards cannot be opened, or that 好感, sect standing, the calendar and the clock gate no 奇遇 step anywhere in the game.

Where this was read

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, and the tables questprototype, condition_group, questjiemi, npc_interact, dialoguelist, npc_prototype, item_base, loot_items.

What was checked live, and what was not. Two things were confirmed against the running game: the live quest counts (121 奇遇 / 60 悬赏解密 against 122 / 61 in the table, with the save file naming the two self-completed placeholders), and the conversation-option model. The trainer's interaction endpoint reports 邢泰 offering exactly the two 奇遇 options the data holds for 丢失的手镯, one shown and one withheld for want of the item, and 万事通 offering the rumour options with the same show/hide pattern the table predicts.

Everything else is a code and data reading and has not been measured: the 20-unit 闲谈 radius and its timings, the four broken records, the 悬赏解密 clue gating, and the entry point of every row in the table below. Two of those are worth measuring first because a wrong reading would matter most: whether 伐木之斧 can in fact be force-finished despite its crossed record, and whether any of the thirteen 武学 deduction boards can be opened by some route the data does not show.

One thing the data cannot tell you. 34 of the 685 steps run an attached script when they complete, and those scripts live in an asset bundle rather than in the readable tables. Where a chain's reward is not listed below, that is usually where it went.

Every 奇遇 in the data

122 rows, grouped by the region tag the journal uses. Steps is how many journal rows the chain has, roughly twice the number of things you actually do. How it starts is the first step with no prerequisite, resolved back to the NPC that delivers it; coordinates are that NPC's spawn x,z from the prototype table, and NPCs walk, so treat them as a place to look rather than a spot to stand. What it hands you lists only items granted outright by a step or by the conversation option that advances it; the generic treasure-chest loot groups several chains also roll are left out, and so is anything an attached script grants.

Two entries need reading with the section above: 伐木之斧 starts from 杨淳雄's 闲谈 at (1511, 1063) in the game but from a record the 奇遇 cannot see, and 险途崎岖's escort step is auto-satisfied.

No region tag

云鹤村

枰栌

豫京

淮陵

雁州