Examples

This section is home to worked examples: real, copy-pasteable YAML that combines several concepts at once, the way an actual pack looks in practice. It’s deliberately different from the other two teaching sections in this documentation.

Features explains one capability or document type at a time. Task Guides walk a single goal from start to finish and explain each step as they go.

The pages here skip that step-by-step framing. Instead they read like a gallery you can search or a reference chain you can walk. Use them once you already know roughly what you’re doing and want to see it done for real, with several types wired together.

If this is your first time here, Getting Started and the Property Types / Operations / Targeting / Conditions & Packs pages in Features are the better starting point. Come back here once those are familiar and you want end-to-end examples instead of isolated snippets.

Every individual document type (item, recipe, schematic, cdo, and the rest) also has its own dedicated page under Features. The full YAML grammar lives in Reference.

Example packs

• ADA Voice-over from a WAV File imports PCM16 audio as a Wwise event, connects it to FGMessage.mAudioEvent, and configures a milestone trigger.
• Player-Configurable Balancing is a complete pack with five typed settings, category classes, cfg: references, a template description and a config: condition. It is the sample pack’s configuration part, built step by step.

Two pages below are patch-only collections with many small type: cdo examples. Two are build-a-whole-thing packs that chain several document types into finished content. The fifth is a focused complete pack for a Repeat-Purchase Schematic (KLIB) with generated curves. The sixth is a per-type creation gallery of type: dataasset examples, one for each KAPI data asset type, the same spirit as Balancing but for generating new instances instead of patching existing ones. The seventh is a single build-a-whole-thing tree for one KAPI type, UKAPIDeliveryTask.

• Balancing covers rebalancing base-game content that already exists: recipes, items, resources, equipment, consumables, radioactivity, belt speed, schematics, milestones, research trees, vehicles, trains, creatures, categories, and bulk tag-matched edits across many targets at once. All of it works through type: cdo patches against existing classes, and nothing is generated.
• Power & Machines covers the buildable-tuning half of patching: power consumption, manufacturing speed, generator output, extractor cycle time, pipeline flow limits, power storage capacity, drone station logistics, and runtime actor patches that also affect already-placed buildings.
• A Complete Building walks the full reference chain for a dynamically generated building, in dependency order: buildable class → building descriptor → build recipe → production recipes → schematic → sink points. These are six files, and each one references the class path the previous file produced.
• End-to-End Pack builds one realistic pack from an item, a recipe, a schematic with an inline unlock, sink points, a German localization file, a dynamic KAPI data asset, and a cdo edit to another mod’s data-asset instances. It also shows how to rename a generated id safely with redirects: once the pack has shipped.
• Repeat-Purchase Schematic (KLIB) is a complete UKLUnlockMaxRepeatPurchases pack with generated cost and reward curves, level-specific overrides, a result table, and the runtime semantics behind each purchase.
• Adding KAPI Data Assets covers type: dataasset creation for every KAPI PrimaryDataAsset type: air collector, cleaner, modular miner, slug breeding, and extractor/resource allow-lists.
• Delivery Task Trees builds one complete UKAPIDeliveryTask tree from scratch: five nodes (including negative coordinates), a multi-flag mParentTask, repeated-parent thresholds, the full Endless field set, and a schematic force-unlock example.

For a normative catalog of every base-game FGUnlock subclass, including its settable properties and caveats, use Base-Game Unlock Classes.

All seven assume a pack living at <your-mod>/DataForge/, the canonical author root used throughout these docs.