1 min read
Internals & Architecture
Runtime pipeline, C++ module organization, persistence, and contributor-facing design contracts.
This section is background reading, not a prerequisite. You can write a YAML pack, load it, and balance a recipe without knowing any of it. It’s here for the curious. It’s also here for anyone extending KDataForge itself with a new handler, who wants to understand the data flow, the subsystems, and the module boundaries before touching code.
- Architecture walks through the full pipeline. It covers the filesystem scan, the pack configuration flow (configuration is read first), YAML parsing, the fixed stage order, the reflection engine that turns a property path into a live edit, savegame persistence for generated content, configuration value synchronization, and the current multiplayer boundaries.
- Module Structure covers how the plugin’s
four runtime modules (
KDataForgeApi,KDataForgeYaml,KDataForge,KDataForgeEditorUI) are laid out on disk. It explains why they’re split that way, and the dependency rules that keep the public API tiny and the dedicated-server build lean.