Sources: data/reference/json/ccb_eoc_conditions.json data/reference/json/ccb_eoc_effects.json tools/json_api/contract-inventory.schema.json tools/json_api/generate_contracts.py tools/json_api/test_generate_contracts.py src/condition.cpp src/npctalk.cpp src/effect_on_condition.cpp src/effect_on_condition.h tests/eoc_test.cpp doc/JSON/EFFECT_ON_CONDITION.md commit c663ceb2c1bd api-contract

EOC talkers and alpha/beta routing

EOC conditions and effects operate on alpha/beta talkers in a dialogue context. Historical key names commonly use u_ and npc_ for those routing directions, but a prefix does not prove that the object is necessarily the player avatar or an ordinary NPC. Events, items, monsters, map locations, and nested calls can construct other talker combinations.

How the inventory preserves unknowns

The condition inventory marks 235 keys legacy_alpha_beta_alias and 40 unknown; the effect inventory has 161 and 145 respectively. legacy_alpha_beta_alias proves only a registration alias group. It is never a classification of the concrete runtime talker type.

Before using a key:

1. Locate its parser or handler in the condition/effect registry.
2. Read how the handler obtains alpha and beta from dialogue.
3. Read the call site that triggers the EOC and constructs that dialogue.
4. If a call swaps talkers or nests another EOC, test both routing directions.
5. Do not document a key as “player-only” or “NPC-only” from its prefix alone.

Failure modes

• Alpha or beta is absent or does not support the requested interface.
• An EVENT resolves its focus entity differently from the author's assumption.
• A parent EOC passes context to a child but not the expected talker.
• An alias works in one routing direction while tests omit the other.

Generated references expose the talker classification deliberately. A concrete compatibility claim belongs in the contract only after the handler, call site, and tests prove it together.