Skip to content
Sources: CONTRIBUTING.md doc/MOD_COMPATIBILITY.md src/mod_manager.cpp src/worldfactory.cpp tests/worldfactory_test.cpp commit d32b9cc880a8 source-and-tests

Mod compatibility

Mod compatibility covers identifiers, dependencies, load order, optional interactions, save data, and public scripting contracts. It is broader than whether a mod's JSON parses once.

Stable boundaries

  • Keep published type and object IDs stable or provide supported migration and obsoletion data.
  • Declare dependencies in the mod metadata; do not rely on alphabetical file order or another mod being present by accident.
  • Put conditional content for another loaded mod under mod_interactions/<other-mod-id>/. Interaction content loads after ordinary mod content; directory IDs are case-sensitive and nested multi-mod combinations are not supported by the verified implementation.
  • Treat EOC talkers, variables, and context as part of behaviour.
  • Treat the Lua manifest version, capabilities, permissions, and published v5 symbols as an API contract.

Validation

Load the mod alone with its declared dependencies, then with each supported interaction set. Create a world, exercise the changed content, save, reload, and inspect the first loader error. A complete example mod should be loaded by CI rather than being validated only as isolated JSON files.

Compatibility claims must name the CCB commit, mod versions, dependency set, and platform. Upstream compatibility does not automatically imply CCB compatibility because registrations, data, and the Lua surface can diverge.