Skip to content
k-modsK-Mods Docs
k-mods.com
GitHub
3 min read

Type: building

Generating new building/buildable descriptor classes from YAML, covering what you actually get and the hard limits on what a generated building can be.

This is the Items stage, at priority 20, the last of the five generation types (class → unlock → item → resource → building). It loads changes only during session initialization, so changes need a restart. The entries key is buildings, and the default parent is /Script/FactoryGame.FGBuildingDescriptor, which is also the required base class (or a subclass of it). Register-only mode (class:) is not supported here, use id: instead.

Don’t confuse this with editing an existing buildable’s stats. That’s a plain cdo patch, and it’s the far more common thing to want (see Power & Machines and Type: cdo). type: building is specifically for creating a new FGBuildingDescriptor-derived class: a genuinely new entry in the build menu, not a tweak to one that already exists.

Read this before you start: the hard constraint

Section titled “Read this before you start: the hard constraint”

A generated class copies its parent’s layout exactly: same components, same mesh slots, same everything except CDO default values. type: building is worth reaching for when you want a second build-menu entry for an existing buildable, with its own display name and description. Players can then have both the original and the new entry at once. The placed building stays the parent’s actor, unchanged.

It is not a way to add a new mesh, a new component, or genuinely new behaviour: a generated class has no new reflected properties and no new components beyond what the parent already defines. KDataForge is also 2D-only by design, so there’s no way to bring in new meshes either. For a new mesh, new component, or new gameplay behaviour, you need actual C++/Blueprint content: type: building can’t get you there.

Worked example: a second Storage Container entry

Section titled “Worked example: a second Storage Container entry”

A building document’s buildings: entries follow the same id/parent/properties shape as every other generation type. id names the new descriptor, parent is the existing descriptor class it clones the layout from, and properties applies CDO overrides to the clone. Here a plain Storage Container Mk1 gets a second build-menu entry with its own name and description:

type: building
buildings:
  - id: CrimsonStorage
    parent: /Game/FactoryGame/Buildable/Factory/StorageContainerMk1/Desc_StorageContainerMk1.Desc_StorageContainerMk1_C
    properties:
      - path: mDisplayName
        value: Crimson Storage Container
      - path: mDescription
        value: A second Storage Container Mk1 entry in the build menu.

This generates /KDataForge/Gen/<PackRef>.Gen_<PackRef>_CrimsonStorage, a new FGBuildingDescriptor subclass. The mDisplayName and mDescription overrides apply to the descriptor only. The generated class adds no mesh, no components, and no capacity or paint change. Placing it spawns the parent’s actor, Build_StorageContainerMk1_C, exactly as it is. The entry only appears in the build menu once a recipe and schematic unlock it (see Troubleshooting).

Practical note: descriptor vs. buildable

Section titled “Practical note: descriptor vs. buildable”

FactoryGame splits “the thing in your build menu” (UFGBuildingDescriptor, what this document generates) from “the thing placed in the world” (AFGBuildable*, the actor). Parenting a building entry must be a descriptor. Desc_StorageContainerMk1 is an FGBuildingDescriptor whose mBuildableClass points at the Build_StorageContainerMk1 actor, so the generated descriptor places that same actor. Giving the actor path (Build_*_C) as parent: is an error: kdf lint reports it and suggests the matching Desc_*_C, and the game refuses the entry when the pack loads. Your mDisplayName and mDescription overrides change the build-menu entry only. Actor-only properties such as mInventorySizeX belong to the actor (FGBuildableStorage) and are not valid on a descriptor. You’re not generating a new AFGBuildable subclass, and for a simple variant you never need to.

When you do want a separate buildable class, with its own CDO defaults on the actor and its own save identity, generate one from an existing Build_*_C parent with type: class and point the descriptor’s mBuildableClass at it. The full chain (buildable → descriptor → build recipe → production recipes → schematic → sinkpoints) is walked step by step in A Complete Building.

Troubleshooting

Section titled “Troubleshooting”
  • The new building doesn’t show up in the build menu at all: check /kdf report first. If the class generated successfully but you don’t see it, this is very likely a build menu category or recipe registration question, not the building document itself. A building descriptor needs a recipe (see Type: recipe) that produces it, and a schematic that unlocks that recipe before it becomes buildable in a fresh game.
  • Stats didn’t change: same rule as everywhere else. An unsupported op or a bad path: is a diagnostic, never a silent failure, and /kdf report tells you exactly which patch failed.
  • Want to bulk-tune a whole family of existing buildings instead (all miners, all belts, all generators)? That’s applyToSubclasses: on a plain cdo patch. See Targeting.