Romance, companions, and the two numbers that gate them

Every social step in this game (writing to someone, asking them for an item, becoming their disciple, marrying them, taking them on the road) is gated by the same pair of numbers, and there are only six gates in the whole system. It is also the same ladder for almost every person in the world: there is no romance roster, no per-character requirement, and no story flag on the marriage option. One row in a data table turns it on for everybody at once.

The ladder

These are one table's worth of rows, all attached to the pseudo-character id 1, which the game merges into every character's interaction menu (NpcInteract.GetNpcInteractsByNpcID). The game prints the requirement itself on the greyed-out button when you hover it, which is how the wording below is verified rather than inferred.

Two of those rows carry a flag that restricts them to procedurally generated characters, the blue dots on the map. 拜师 and the generic recruit option never appear on a named story character, however high you push the numbers. Named characters who can be recruited each have their own row instead, and none of those rows asks for 好感 or 情分 at all (see Recruiting).

A handful of things narrow the list further:

• Every one of these rows is hidden on a pet.
• 结缘, 结义 and 对饮 are hidden on a child.
• Exactly two characters in the game strip the standard menu: 小妙 removes 拜师 and 结缘 (she is a child, and has a grown-up version later who can be recruited), and one other removes the whole block.
• 劫杀 is random-characters-only. 切磋 very nearly so: a procedurally generated character gets it from the default row, and a named one only by carrying a 切磋 row of its own, which 142 of them do. That bounds how fast you can raise a named character, since the spar is the best rate available (see the rate table).

The assembly also contains a hardcoded version of this check, asking 40 for 拜师 and 70 for 结缘 and 结义 (RelationShipManager.IsReachNpcHaoGan). It is dead. Its only two call sites are inside InteractOnChat.InitData, which nothing in the assembly calls. The data conditions above are what run.

The tiers are 25 points wide, and the top one ends the ladder

The phrase the game prints beside a name is a band. RelationShipManager.GetHaoGanDescriptionByValue treats −5 to 5 as a neutral middle and everything outside it as ceil(|好感| / 25), with the sign choosing which of the two ladders to read:

生死与共 is the last rung: nothing sits above it, and 好感 itself caps at 100.

This one was checked in play. Three characters read back what the formula predicts: 张玄素 at 好感 70 shows 莫逆之交, 真熠 at 8 shows 互通名姓, and 宁玉成 at 0 shows 陌路不识, the neutral band.

That top boundary is the same wall the 情分 drip runs into, seen from the other side. The drip is clamped at 好感 75, the last point of 莫逆之交, so 生死与共 begins one point past everything gifting can reach.

情分 is not a second track. It feeds 好感, and it stops dead at 75

This is the mechanic the community has been arguing about for two years, and it is eight lines of code.

Every time your 情分 with someone goes up, the game divides your lifetime 情分 total with that person by 1000, and for each new thousand you have crossed it adds +1 好感, then clamps that award so it can never take you past 好感 75 (RelationShipManager.ModifyQingFenValue). Crossings that would push you over 75 are consumed, not banked.

So:

• Below 75, gifts work even when the game shows +0 好感. A gift always pays 情分, and every 1000 of it is another point of 好感 arriving silently.
• At 75 the drip stops completely. 生死与共 is the tier above 75, and no amount of 情分 will ever reach it. The player reports of "30,000 情分 and 好感 frozen at exactly 75" are this line, exactly.
• Above 75 the only things left are the ones that add 好感 directly: a liked gift, 谈论, a won spar, a finished commission, a 论道 win.

The two numbers are also stored twice each. m_QingFen is the spendable pool that you burn on 请教 and 索要. m_QingFenRecord is a lifetime total that only ever increases. The ladder conditions read the record (the condition rows end in |1, which selects it), so spending 情分 never costs you a rung. Learn a 12,500-情分 secret technique and your 结缘 eligibility is untouched.

Two things can silently kill the drip: it only runs when 情分 increases, and it needs the character to be a loaded entity; the conversion rate is looked up through their personality, and an unloaded character has none.

What moves the numbers, fastest first

Everything below is read out of the assembly. Nothing in this table was measured in play.

谈论 is the best rate in the game, and the only fast one that works on named characters. It costs 20 精力, rolls just over half (Random.Range(0,100) <= 50), and pays 30 to both characters involved plus 30 between them. Expected value is about 15 好感 per cast, against 8 for a won spar you can only get from a random character. On failure 谈论 pays nothing and costs nothing but the 精力; 诋毁 on failure costs you 30, so there is no reason to pick it unless you want the two of them to fall out.

Its one requirement is a target: you pick a third person from either that character's relationship list or your own, so someone with no listed relations gives you nothing to talk about.

委托 is the best source of 情分, paying 495 per tier-7 commission against a gift's few hundred, and it pays 20 好感 on top. Both figures are hardcoded arrays in the assembly, not data. The generic commission option is another random-characters-only row, but roughly 700 characters carry a commission row of their own, so it is not the restriction it looks like.

Two attributes multiply everything, and one adds a flat bonus

容貌 adds a flat bonus to every positive 好感 gain the player makes (RelationShipManager.CheckRongmaoAddHaogan), on a step function:

It is added before the multipliers below, and it applies per gift, per spar, per commission, which is why it matters more than a flat six points sounds. On a base-3 gift it is a doubling.

琴艺 and 酒量 are the two multipliers, and they only exist through equipment-slot 特技:

• 短歌微吟 (a 琴艺 stunt, unlocked at 琴艺 ≥ 450) multiplies every positive 好感 gain by 1 + min(1.0, 琴艺/1000). At the 450 that unlocks it that is +45%; it caps at +100% at 琴艺 1000.
• 一醉累月 (an 酒量 stunt, 酒量 ≥ 450) does the same to every 情分 gain, same curve.
• 歌伶·鸣岚 is a second 琴艺-scaled 好感 stunt on the same internal slot, gated behind a quest and 魔学 ≥ 900.

Both must be equipped, not merely owned; only equipped stunts contribute (StuntManager.RefreshPrototypes), and only one stunt per slot is active. Without the stunt the lookup returns zero and the attribute does nothing at all. There is a third slot for a commission-好感 bonus in the enum with no stunt in the data, so it is currently inert.

Sect standing counts toward these thresholds

RelationShipManager.GetHaoganValue, the function every gate reads, adds ceil(sect_standing / 20) × 5 to the raw number, using your standing with that character's sect. At sect standing 100 that is a flat +25 好感 with every member of that sect, and it counts toward the 75 needed for 结缘 and recruitment. It is applied on read, so it does not persist into the stored value and it evaporates the moment you leave the sect. Negative standing subtracts the same way, up to −25.

That means the cheapest route to 结缘 with a sect member is often sect bounties, not gifts.

Gifts, exactly

Two separate conversions run on the same item, and the panel previews both before you confirm (RelationShipManager.ModifyHaoganValue(…, Item, …)).

好感  = base + floor(base/2) × item_level
情分  = base × (1 + quality × 0.15 + item_level × 0.4 + enhancement × 0.01)

Item level and quality are stored zero-based, so a 七阶 item is level 6 and quality runs 0–4. So a 七阶 gift multiplies the 好感 term by 6 and adds 2.4 to the 情分 multiplier.

The two bases come from the recipient's strongest personality attribute, which the game picks fresh each time from the eight on their sheet (Gift.GetNpcTendencyAttri; ties go to the earliest in the list below). Their info page shows the resulting taste as 兴趣.

画卷 is liked by all eight. Thirty-six items in the game carry that classification, and a painting is the only gift that never needs you to know anything about the recipient. It is also the one gift class you can manufacture: the 画道 life skill produces them.

A 容貌-led character is worth nearly three times as much 情分 per gift as a 福气-led one, for the same item. A 七阶 quality-4 painting is 1152 情分 to the first and 420 to the second, and 1152 is more than a full point of 好感 through the drip.

The 坚韧 row lists 酒 as both liked and disliked; the code checks liked first, so the dislike is dead.

Only four characters in the entire game have a hand-picked favourite item, worth 8 base instead of 3 or 4, yielding 32 好感 for a 七阶 one:

Three more rows list a specifically hated item (狗皮膏药, 醒脑丸/养气散, 百灵丹, for 霖虹, 霖虹/王铁 and 张蓉榕), and five characters start the game with 好感 already on the clock: 张蓉榕, 霖虹, 王铁 and 村长 at 10, 灵均 at 25.

Two things about the gift panel worth knowing:

• It only lists items the recipient likes (ItemStorage.GetPresentItems filters on exactly that), so you cannot hand someone a disliked gift in person. The disliked path — which pays negative 好感, no 情分, and clamps your floor at −39 so it can never itself start a feud — is only reachable through the letter system.
• At 好感 ≤ −40 the panel refuses to open at all ("关系不合", RelationShipManager.CanPresentNpc).

Recruiting

The roster caps at 9 and you can field 3. TeamManager.MAX_TEAM_COUNT is 10 and MAX_DEPLOY_COUNT is 4, but both are tested as count >= MAX − 1, so the real limits are nine recruited and three deployed (TeamManager.AddTeamMember, DeployMember). The cap is on the main team only; story-scripted followers and temporary companions ride in separate lists that GetAllPlayerTeam() folds in on top.

Random characters take the standard 75 / 3500 and nothing else.

Named characters need a row of their own, and not one of the 33 such rows reads 好感 or 情分. They are gated on a quest, a dialogue, or a fight instead, and the requirement is printed on the locked button:

猹猹 is the outlier: its recruit row carries no conditions in either the show filter or the lock, so it joins on request.

Note what is not on that list. 灵均 has no recruit row; the community reports 灵均 joining after the true ending, which would be a script call rather than a menu option, and that is consistent with the data. And no amount of 情分 will ever recruit 镜无双; the reports of 7,000, 20,000 and 50,000 failing are correct, because her row does not read 情分 at all.

Romance

Almost everyone is romanceable. The 结缘 option comes from the global row, so the eligibility test is short: opposite sex, not a child, not a pet, and 好感 75 with 情分 3500 lifetime. The community's reports of marrying the village chief's wife, an elderly aunt, and a quest character by misclick are not bugs. They are the design.

Four characters (all 绝影楼密探) carry their own 结缘 rows with no conditions whatsoever.

Gender is enforced in the menu, not the data. InteractTip.onInteractClick filters the expanded submenu with player.IsFemale() != target.IsFemale() for 结缘 and == for 结义. Sex comes from a bit on the character's base record — bit 4 male, bit 8 female — and 291 base records in the game carry neither, which the game's own error log calls out as missing data; those read as male.

There is a second, older filter in the same method that tests a different field entirely (the character's flag mask, which holds boss and elite bits and is zero for every named character). It sits on the branch that runs when the interaction has no group, and it would hide 结缘 on everyone. It is worth knowing it exists if the option ever fails to appear where the numbers say it should.

Asking is a coin flip you can retake. 结缘, 结义 and 拜师 all roll against a single shared constant, Tools.NPC_INTERACT_RATE = 0.6, a 60% success rate, with no penalty for failure beyond a refusal line. Ask again. Nothing in the code tracks refusals, so the community's "月兰 refuses the first time, accepts on the second or third" is this roll and not a scripted rejection.

Marriage is exclusive, and the game enforces it silently. RelationShipManager.AddJieYuan looks for an existing active bond on the player, marks it inactive, and writes a "bond dissolved" record, so marrying someone new automatically divorces whoever you were with. There is no divorce command; taking a new spouse is the divorce. Before it happens you get a message box naming your current spouse, but the confirm button on that box goes straight through to the roll. It is a warning, not a veto.

Marriage does almost nothing. What AddJieYuan writes is a relationship record, a line in your 生平, and a flag on both characters that stops the world simulation from pairing them off with anyone else. Nothing in the assembly reads the married state to change dialogue, unlock a shop, grant a buff, or make a spouse follow you. The two-year community consensus that 结缘 is "纯摆设" is a fair reading of the code.

There is a second, guaranteed route. An NPC can write to you proposing marriage, and accepting that letter calls RelationShipManager.CreateMarryRelation, which has no success roll. It just happens. The proposal is generated by SendMailHandle, which requires the same 75 / 3500 (it literally looks up the same interaction row and evaluates its condition), plus: opposite sex, they must be alive, and they must be a 飞鸽 correspondent, meaning at least one completed letter exchange and 好感 above 5. Six such letters go out per batch, drawn at random from everyone who qualifies. The equivalent letter for 结义 requires the same sex.

The tier that gates the best rewards is one point above where 情分 stops

Learning a secret technique from your master is priced in 情分 and gated on the 好感 tier, from qingjiao_prototype:

That last row is why 75 matters so much: the drip stops at exactly 75, and the gold technique needs 76.

Except the check is cosmetic. In QingJiaoView.SetContentPrefab, the life-skill buttons only get a click handler when the tier is unlocked, but the 秘技 buttons get theirs unconditionally. The row still draws a padlock on its header, and clicking it still works. The only thing actually verified on click is that you hold enough 情分. That matches the player report of buying a gold technique without unlocking the tier, and it means the practical requirements for a gold passive are 拜师 (50 / 1500) and 12,500 情分, nothing more.

What locks you out permanently

• Death. ModifyHaoganValue returns immediately if the target is dead, so nothing can be repaired afterwards. Killing someone you meant to learn from is unrecoverable.
• 劫杀. Robbing anyone sets every one of their friends, family and their spouse to −50, a hard assignment and not an adjustment, so a friend at +100 drops to −50 in one action. That is past the −40 feud line, so it also opens a blood feud and closes the gift panel with each of them. Their enemies gain 5. The same action costs 5 sect standing with the victim's sect and 5 道德.
• The −40 floor is a soft trap, not a hard one. Below it you cannot give gifts, which removes both the direct 好感 and the entire 情分 drip. 谈论 still works because it has no 好感 requirement, so recovery is possible at 20 精力 a throw.
• A disliked gift cannot start a feud. When the item is one they hate, the game passes a raised floor of −39 for that transaction specifically. You can insult someone down to that line and no further.
• Nothing else is permanent. There is no story flag, no "she only sees you as a brother" state, and no jealousy. Refusals are the 60% roll.

What the community says, and what survives

Checked against the TapTap 江湖2攻略组 new-player guide, its companion piece on NPC development, 秋枫笙陌's beginner guide, 游侠网's relationship-system article, the sect guide, and a large number of 百度贴吧 threads.

Nothing in the community material mentions 谈论 at all, the fastest source of 好感 in the game, available on every character, at four times the rate of a spar.

Where this was read

RelationShipManager in full (ModifyHaoganValue both overloads, ModifyQingFenValue, GetHaoganValue, CheckMenPaiHaoGanChange, CheckRongmaoAddHaogan, SetHaoGanValue, GetHaoGanDescriptionByValue, AddJieYuan, AddShiTu, CreateMarryRelation, CheckPlayerExpWithNpc, CanPresentNpc, IsArchiveHaoGanLevel, SendMailHandle, OnRobNpcCompleted); Gift in full; NpcInteract.GetNpcInteractsByNpcID; RoleInteract.GetNpcInteracts; InteractSlot (Handle_IT_JIEYUAN, Handle_IT_PRESENT, Handle_IT_TanLunNpc, OnPresent); InteractTip.onInteractClick; RelationPanelNew.HaoGanHandle; InteractOther.GetQingYiPrice / QingYiBuyJudge; QingJiaoView; TeamManager; StuntManager.GetStuntEffectValue / RefreshPrototypes; EntrustManager.DoFinisedEntrustAction; LunDaoMainView.GameOver; ItemStorage.GetPresentItems; MailManager (ExchangeHandle, NpcPresentHandle, MarryHadle); AnswerViewNew.CheckFriendshipValue / CheckEmotionValue.

Tables: npc_interact (the ladder), gift (all 115 rows), qingjiao_prototype, npc_haogan (empty), base_probability (which fixes item level and quality as zero-based), stunt_proto, npc_prototype / npc_prototype_base (names, sex bit, child bit), item_base.

The rates here were not measured in play. What has been read off a running game is the tier table, confirmed on three characters at 好感 70, 8 and 0, and the ladder itself, which renders with the exact wording quoted above. Given that this project's last measurement pass overturned a published attribute table wholesale, treat every rate here as what the code says rather than what the game does until it is checked.

The four things most worth measuring, in order:

1. The 情分 drip. Give a run of gifts to one character below 75, tracking 情分 and 好感 on the game's own panel, and confirm +1 per 1000, then push past 75 and confirm it stops.
2. 谈论. Twenty casts on one character, counting successes and the size of each gain, against the predicted 51% × 30.
3. Whether item level really is zero-based in the gift formula. A 一阶 and a 七阶 gift of the same class to the same character separates it in two actions: the prediction is base and base + 6×floor(base/2).
4. The 索要 price. Its item-category lookup compares a string builder against a string, which binds correctly only if the compiler chose the span overload; if it chose the object overload the price is always zero and everything an NPC carries is free. A player report of a 5,001-情分 price says it probably binds, but the panel prints the number, so one look settles it.