Page 15 · Native Data

Native Minecraft Bridge

Use Minecraft as the underlying engine: Data Components, dedicated native bridge folders, open registry/data passthrough and runtime capability discovery.

Bridge Instead of Reimplement

DAI authoring JSON
  ↓
Known friendly bridge folder OR dai_registry / dai_data
  ↓
Generated server-data pack
  ↓
Minecraft native registry / data loader

When Mojang already defines the data format, DAI compiles to it rather than inventing a parallel representation.

Dedicated Bridge Folders

Common bridge folders include dialogs, native enchantments, paintings, jukebox songs, instruments, damage/chat types, trim/banner data, trades, entity/sound variants, GameTest data and the major vanilla worldgen registries. Native recipes, loot tables, advancements, predicates and item modifiers also have direct passthrough folders.

The exact current folder list is written into capabilities.json, so tools can discover it from the runtime.

Open Registry Bridge

// data/example/dai_registry/plasma.json
{
  "registry": "damage_type",
  "raw": {
    "message_id": "plasma",
    "exhaustion": 0.1,
    "scaling": "never"
  }
}

The file ID supplies the output namespace/path. registry / registry_path supplies the Minecraft registry path. raw, vanilla or value can contain the exact Mojang payload.

Open Server-Data Bridge

// data/example/dai_data/my_predicate.json
{
  "output": "predicate",
  "raw": {
    "condition": "minecraft:entity_properties",
    "entity": "this",
    "predicate": {}
  }
}

Use this for arbitrary JSON server-data paths that are not registry-backed.

Native Item Components

Registry-backed items may use components or native_components. DAI does not maintain a fixed component allow-list: it resolves the current registered component and applies its codec.

capabilities.json

DAI writes config/decisions_and_impulses/capabilities.json with Minecraft registry keys, built-in Data Components, direct bridge folders, dai_registry, dai_data and the native component field. Treat that file as the runtime's machine-readable feature inventory.

3.0 Distribution Boundary

The same native bridge definitions can now originate from an installed mod JAR during early discovery. This matters for registry-backed DAI items/entities and generated world data because the required native shells can be discovered before a save datapack reload begins.

Six first-class DAI registry targets

The native content bootstrap now supports item, block, entity, effect, potion and particle. The open dai_registry/dai_data bridge remains the escape hatch for Mojang registries and server-data types that do not need a dedicated DAI runtime.

See static vs reloadable runtime fields →

Foundations Carried Into 3.0

DAI 3.0 retains standalone global addons, living/moving JSON entity portals, generated custom dimensions, friendly world-type presets including void/water/superflat worlds, and a browser Gameplay Tester integrated into the Creator.