Skip to content

EOC contracts and lifecycle

An EOC (effect on condition) combines condition parsing, effect parsing, and a trigger lifecycle. The machine inventories currently index 275 condition keys and 310 effect keys. Registration coverage is complete while handler-level parameter classification remains incomplete.

The effect_on_condition object

The source inventory classifies this object's fields as partial:

  • id has explicit mandatory evidence.
  • eoc_type is optional; the loader follows activation by default without recurrence, and the recurring rules when recurrence exists.
  • condition, deactivate_condition, effect, and false_effect are read behind presence branches.
  • global and run_for_npcs default to false.
  • required_event is mandatory only inside the EVENT branch; do not describe it as mandatory for every EOC.

Lifecycle types come from effect_on_condition.h/.cpp: ACTIVATION, RECURRING, AVATAR_DEATH, NPC_DEATH, PREVENT_DEATH, and EVENT. Each receives talkers and context from different trigger paths, which must be checked in the corresponding source and tests.

Parser boundaries

  • Conditions use first-matching-parser dispatch. An unknown object condition throws JsonError; an unknown string condition becomes a predicate that returns false.
  • Effect containers accept a string, object, or array and also use first-match dispatch; an unknown effect throws JsonError.
  • Only the logical and, or, and not condition keys are fully classified; the other 272 are partial.
  • All 310 effect keys are partial. This does not mean they are unusable. It means parameters, defaults, nesting, talkers, variables, or context do not yet have complete source classification.

Continue with talker routing, variables and context, and nesting, then build a minimal validation chain with the complete example mod.