linkKnown issues and compatibility

This page lists limitations and rough edges that touch Kore directly: the kore module, bindings, and * helpers* where Kore documents behavior. It is not a general Minecraft gameplay reference.

Each item is tagged:

Category	Meaning
Kore limitation	Kore or a dependency Kore wires in (for example knbt) cannot express or round-trip the case yet.
Documented DSL / helper cap	Behavior is spelled out in Kore’s own command or helper docs (often because the vanilla command format or text API is narrow).
Generation rough edge	generate() / generateZip() / merge paths behave as implemented; surprising until you read the generation docs.

For the high-level “what Kore does not include,” see From Datapacks to Kore.

---

linkKore limitations

linkNBT and SNBT (via knbt)

Category: Kore limitation

Kore builds NBT and SNBT through knbt (StringifiedNbt and builders). Entry points include NbtTagUtils.kt and the nbt { } / stringifiedNbt(...) helpers used across commands and components.

Implications:

• Typed NBT lists: In knbt, NbtList is homogeneous (one element type per list). That matches Java edition NBT, but it means you cannot build a single list that mixes unrelated tag kinds through the normal DSL. See the knbt README (NbtList description).
• Exotic SNBT text: Some SNBT spellings or parser extensions you might see in external tools are not necessarily available through Kore’s knbt-backed path. Prefer compounds, homogeneous lists, and literals Kore’s builders support.

Workaround: Emit a literal("...") only when you must hand-craft a fragment, or post-process generated files. Upgrading or patching knbt (Kore pins a version in gradle/libs.versions.toml) is the right place for format-level fixes.

linkResource packs

Category: Kore limitation

Kore generates datapacks only (data/, functions, JSON registries, pack.mcmeta). It does not emit resource packs (assets/). That scope is stated on the site (for example Home) and in From Datapacks to Kore.

Workaround: Maintain a separate resource-pack project or tooling; you can still keep both in one Gradle repo.

linkBindings importer

Category: Kore limitation

The bindings module is experimental. Official docs: Bindings. Roadmap and design discussion: GitHub #176.

Notable constraints from Kore’s own docs and README:

• Generated APIs may change between Kore versions; pin versions and review diffs.
• Unknown resource types are skipped so codegen stays valid (Bindings troubleshooting).
• Macros in imported .mcfunction files are detected via $()-style patterns, not a full Minecraft parser (Bindings).
• CurseForge downloads need a CurseForge API key; GitHub may need a token for rate limits (Download sources).

Workaround: Treat imports as a typed starting point; simplify or remap packs that confuse the importer ( remappings { }, includes / excludes in Configuration).

linkJSON / NBT serialization (generate vs decode)

Category: Kore limitation

Many serializers are write-only for Kore’s use case: they encode what you build in Kotlin and **refuse to decode ** from arbitrary vanilla JSON/SNBT. Examples in the codebase include ComponentsSerializer (“deserialization is not supported”), NbtAsJsonSerializer, book page serializers, and chat component decode paths that throw.

Workaround: Treat your Kotlin project as the source of truth; inspect generated files under path / zip. For contributors extending serializers, see Arguments and the relevant feature docs.

linkCustom components and @SerialName

Category: Kore limitation

When you define custom components backed by NBT, property names sometimes need an explicit @SerialName("vanilla_json_key") because the KNBT stack does not always follow the same naming path as Kore’s JSON namingStrategy for that shape. The guide shows this in context (for example the UseComponent example with durability_damages).

Workaround: Copy patterns from Components and match the keys your target **pack format ** expects (use Minecraft’s registry JSON or Kore’s generators as reference, not guesswork).

---

linkDocumented DSL / helper caps

These are not Kore bugs; Kore documents them so authors know what the DSL will and will not do.

linkCommand macros

Category: Documented DSL / helper cap

Macros require Minecraft 1.20.2+ for the feature itself. Kore’s doc lists DSL limits: macros only in functions, no type checking, and macros are not threaded through every possible command argument slot.

Workaround: Prefer normal Kotlin command builders where types matter; keep macro surfaces small and **test in-game **.

linkMarkdown renderer (helpers)

Category: Documented DSL / helper cap

The Markdown renderer turns Markdown into text components. The helper lists features Minecraft cannot represent (images, tables, fenced code blocks, etc.) in Not supported (Minecraft limitations).

Workaround: Stay in the supported subset documented on that page, or build textComponent trees by hand.

linkQuick reference

Need	Where to look
Tune JSON output	Configuration (prettyPrint, comments, paths)
Folder vs zip vs jar	Creating A Datapack — Generation
Import external packs	Bindings
Module layout	From Datapacks to Kore
Report a bug or gap	Kore on GitHub with pack format and Kore version