DataPack configuration

The configuration { } block controls how Kore writes your pack: JSON formatting, the naming of the functions Kore generates on your behalf, and the optimization passes run before writing. All options are listed at the bottom of this page.

It does not control where output goes or what shape it takes - that is path plus your choice of generate(), generateZip() or generateJar(), covered in Creating a Datapack.

None of these settings change in-game behavior. They exist to make development and debugging easier, and releases leaner.

Example

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

	// ... rest of datapack code
}

prettyPrint

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.

Indentation (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.

Generated 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).

Callers of generated functions (generateCommentOfGeneratedFunctionCall)

When generateCommentOfGeneratedFunctionCall is true, every generated function starts with one comment per function calling it, so you can trace a generated_scopes/ file back to the code that produced it:

# Called by my_pack:shop/buy
# Called by my_pack:shop/sell
give @s minecraft:diamond
tellraw @s "Done!"

A function calling it through a function tag (#minecraft:tick) isn't listed. The comments are added when the pack is written, so they never change the hash in a generated function's name. Default: false. Turn it on while debugging or learning generated control flow; turn it off for minimal .mcfunction output in releases.

Logging

Kore and its modules print their progress and warnings (pack format mismatches, merged packs, optimization summaries, bindings downloads) through KoreLogger, a global object shared by every pack in the process. Raise its level to hide them, or replace its handler to send them to your own logger:

KoreLogger.level = KoreLogger.Level.WARN // keeps warnings, hides progress lines
KoreLogger.level = KoreLogger.Level.OFF // silent

KoreLogger.handler = { level, message ->
	if (level == KoreLogger.Level.WARN) logger.warn(message) else logger.info(message)
}

The default handler prints to the standard output, warnings in yellow.

Development vs release setups

The defaults are release-oriented (compact JSON, no comments). While developing, flipping both booleans makes the output far easier to read:

Keep one dataPack { } definition and branch on a build constant, or use separate main/debug entry points, depending on your Gradle setup:

val debug = System.getenv("KORE_DEBUG") != null

dataPack("mypack") {
	configuration {
		prettyPrint = debug
		generateCommentOfGeneratedFunctionCall = debug
	}
}

Reference

What to read next

• Creating a Datapack - metadata, output location, and packaging
• Functions - what produces the generated functions this page names
• Execute - the main source of generated scope functions
• Optimization - the passes cleaning up the finished pack