linkDataPack configuration

The configuration { } block on a DataPack controls how Kore serializes JSON (and related formats) and where generated functions live. Output location and archive shape are chosen when you call generate(), generateZip(), or generateJar().

linkExample

dataPack("mypack") {
	configuration {
		prettyPrint = true
		prettyPrintIndent = "  "
	}

	// ... rest of datapack code
}

linkprettyPrint

When prettyPrint is true, Kore’s shared Json encoder formats JSON resources (advancements, tags, recipes, worldgen JSON, pack.mcmeta, etc.) with line breaks and indentation. When false, output is compact (smaller files, slightly faster I/O).

• Default: false (release-friendly; smaller packs).
• Set true when you want readable diffs in version control or easier manual inspection while developing.

prettyPrint does not change game behavior; it only affects on-disk JSON layout.

linkIndentation (prettyPrintIndent)

prettyPrintIndent is the indent string passed to Kotlin serialization when prettyPrint is enabled. The default is a single tab ("\t"). Common choices are "\t", " ", or " ".

For TOML serialization (used for some generated files), Kore maps the indent string to ktoml styles: tab, two spaces, and four spaces get proper TOML indentation; other values fall back to no extra indentation for TOML output. Matching your JSON indent to one of those three keeps JSON and TOML visually consistent.

linkGenerated function folder (generatedFunctionsFolder)

Kore may emit generated .mcfunction files (for example when execute chains are lowered into separate functions). Those files are placed under:

data/<namespace>/function/<generatedFunctionsFolder>/...

The default folder name is generated_scopes (see DataPack.DEFAULT_GENERATED_FUNCTIONS_FOLDER in the Kore source). Change generatedFunctionsFolder if you want a different directory name (shorter paths, naming that matches your project, or avoiding clashes with hand-written function/ trees).

linkComments on generated function calls (generateCommentOfGeneratedFunctionCall)

When Kore inserts a call to a newly generated function from an execute block, it can add a comment line in the calling function documenting that call, for example:

# Generated function namespace:path/to/caller

This is controlled by generateCommentOfGeneratedFunctionCall. Default: false. Turn it on while debugging or learning generated control flow; turn it off for minimal .mcfunction output in releases.

linkWhere files go (path) and generation modes

• dataPack.path (default: out): base directory for generation. The generator resolves packs relative to this path (see below).
• generate() writes an unzipped folder: <path>/<datapack.name>/ with pack.mcmeta, data/, etc. Best for pointing Minecraft at a dev folder, CI checks, or tools that expect a plain tree.
• generateZip() writes <path>/<datapack.name>.zip. Same contents as the folder layout, in one archive. Convenient for distribution and often faster for the game to load than thousands of loose files.
• generateJar() writes <path>/<datapack.name>.jar. The comment on the API states this is intended for use * as a mod*: JAR generation runs optional providers (Fabric, Forge, NeoForge, Quilt, etc.) to add loader metadata and package the datapack accordingly. Do not expect a plain datapack ZIP renamed to .jar unless you only need the archive format without mod infrastructure.

generate() and generateZip() accept DataPackGenerationOptions (for example mergeWithPacks). generateJar() uses DataPackJarGenerationOptions, which supports the same merge list plus loader-specific configuration.

linkDevelopment vs release-oriented setups

A practical split:

You can keep one dataPack { } definition and branch configuration with build constants, or use separate main/debug entry points, depending on your Gradle setup.

linkReference

Configuring a datapack is especially useful for debugging and for tuning pack size and readability in production.