Dialogue scope v2: fix multi-NPC conversations broken by the cross-NPC bleed filter (#558 follow-up)

[Wondernuttz]

What

Follow-up to #558. Lorkhan flagged that the cross-NPC dialogue filter breaks multi-NPC conversations - he's right, and this repairs it while keeping the original bleed protection.

The defects in v1 (#558)

1. Group conversations starved. The filter kept a chat row in an NPC's history only when it was their own line or stamped (talking to <them>). In player-led 3-ways and rechat rounds, every co-participant line was dropped - each NPC remembered only its own dialogue. It looked fine in play because rechat hands the previous line as direct input (origin_line), so turn-to-turn worked; what silently died was shared memory beyond one hop (repetition/incoherence in longer rounds).
2. Multi-listener stamps matched nobody. (talking to Fironet, Ahtar) failed the ilike '%(talking to Fironet)%' test for BOTH addressees - the pattern demanded a closing paren right after the name.
3. Player-addressed lines vanished from every present NPC's history.

The fix

• Group rounds (rechat / narration / continue / continue_group) skip the dialogue filter entirely - every participant needs the whole round in history.
• Addressee match is a word-boundary regex over the listener list (data ~* '\(talking to [^)]*\mNAME\M'), so comma lists and suffixes like (busy) reach every listed listener. Names go through preg_quote + SQL escaping (apostrophes/hyphens safe).
• Player-addressed lines are public to NPCs present - a bystander plausibly hears what the player is told.
• The original bleed case - bystanders ingesting NPC-to-NPC verbatim lines on normal turns and echoing each other - stays filtered.

Testing

• 6 listener-match cases run against live Postgres (single listener, comma list both positions, bystander exclusion, (busy) suffix): all pass.
• buildHistoricContext executes on both normal and group-round turns, including an apostrophe+hyphen actor name through the escaping.
• php -l clean.

[abeiro]

If you play in another language this won't work, as "talking to .." will be replaced by teh translated sentence.
Anyway, all NPCs in column people on eventlog MUST have access to the event. On buildHistoricContext we classify the events. I suggest to move the code there and OPTIONALLY (via a global switch) remove there whatever is bothering you.

[Wondernuttz]

The original problem wasn't access, it was bystanders echoing NPC-to-NPC verbatim lines back at each other. Pure people-based access may reintroduce that, since a bystander present in the scene is legitimately in "people". I didn't think about the language issue....that's a gap.

[abeiro]

then i still don't know what the problem is. Could you provide a log sample (context_sent_to_llm.log) where this is happening. VIa discord.

[Wondernuttz]

Yeah... I've stopped the issue on my end...its been a while since I heard it occur...so it may take a bit to even find logs where it occurred...but I'll dig. I'll hit you up on discord.

…

On Wed, Jul 15, 2026, 7:30 AM abeiro ***@***.***> wrote: *abeiro* left a comment (abeiro/HerikaServer#568) <#568 (comment)> then i still don't know what the problem is. Could you provide a log sample (context_sent_to_llm.log) where this is happening. VIa discord. — Reply to this email directly, view it on GitHub <#568?email_source=notifications&email_token=BVLYWETWQN657HL3F4BJSKD5E5TO7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJYGAYDGOBYGM22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4980038835>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BVLYWEW4D4TYZVGSHFOCCOT5E5TO7AVCNFSNUABFKJSXA33TNF2G64TZHM3DSMZXHA3DGNBYHNEXG43VMU5TIOBVHA4DIOBYHA22C5QC> . You are receiving this because you authored the thread.Message ID: ***@***.***>