Skip to content
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

Nesting EOC conditions and effects

Nesting is constrained first by container shape and then by the individual handler.

Proven general rules

  • Conditions enter object or string parser paths. and and or accept arrays; not accepts one object or string. These three logical keys have completely classified nesting contracts.
  • An effect container may be a string, object, or array.
  • Both parser families use first-match dispatch. Do not put multiple competing condition/effect keys in one dispatch object.
  • Beyond the three logical conditions, handler parameters, defaults, and nesting support are mostly unclassified; follow the source links in generated reference.

Minimal structure

The documentation example mod uses one activation EOC:

{
  "type": "effect_on_condition",
  "id": "EOC_CCB_DOCS_HELLO",
  "eoc_type": "ACTIVATION",
  "condition": { "math": [ "1 == 1" ] },
  "effect": [ { "u_message": "The CCB Docs example EOC ran." } ]
}

Both math and u_message are registered, but their current contracts are partial. The example check proves registration, the maintained fixture shape, and JSON parsing; the real CCB loader remains the final validation layer.

Add complex nesting one layer at a time: validate leaf conditions/effects, then add and/or/not or if/then/else, and only then add variable passing and talker swapping. Keep a minimal EOC that reproduces failures at each layer.