Types Reference

This section documents the built-in types that MiXianTu JSON can select through a type field, together with the shared data types those types consume.

How Type Dispatch Works

Actions, conditions, number providers and a number of smaller families are Java-owned registries of codecs. The mod registers each entry under an ID such as mxt:heal or mxt:uniform, and a datapack selects one of those entries by writing a type field:

{
  "type": "mxt:heal",
  "amount": 2
}

The type key is inlined into the same JSON object that carries the parameters of that type. There is no wrapper object and no separate parameter section: the discriminator and the fields it selects live side by side.

Datapacks Cannot Add Types

A datapack can only supply type and the parameters of an existing type. Reloading a datapack never adds entries to these built-in registries, and an unknown type ID fails the reload. New types must be registered from Java or from a script.

Several families accept a plain JSON shorthand for their most common case, which is exactly equivalent to writing the type with its default fields. For example a JSON number is mxt:constant, a JSON string is mxt:expression, and the item ID "minecraft:apple" is mxt:item. Where a shorthand exists, the explicit typed object remains valid.

Dispatched Fields

The following fields use the MapCodec of a Java built-in registry. Datapacks can pass type and that type's arguments, but cannot introduce a new type:

Data Type	Dispatch Field	Purpose
Ability	ability.type	The top-level field is named ability; the nested type selects the ability lifecycle and trigger style
CurseType	type	How a curse lasts and expires
EntityAction	type	Entity action
BiEntityAction	type	Bi-entity action
BlockAction	type	Block action
ItemAction	type	Item action
EntityCondition	type	Entity condition
BiEntityCondition	type	Bi-entity condition
BlockCondition	type	Block condition
ItemCondition	type	Item condition
DamageCondition	type	Damage condition
ResourceValueProvider	type	Resource value source read by resource bars and extensions, including environmental and actual aura concentration
ResourceBarRenderer	type	Resource bar renderer
ResourceBarVisibility	type	Resource bar visibility condition
Badge	type	Badge structure

Action and condition arrays are shorthand for "all of them, in order":

"entity_action": [
  {"type": "mxt:heal", "amount": 2},
  {"type": "mxt:apply_curse", "curse": "example:burning", "stacks": 1}
]

The concrete fields of every action and condition are defined by its built-in codec. The built-in types are registered in groups by MxtEntityActions, MxtBiEntityActions, MxtBlockActions, MxtItemActions, MxtEntityConditions and their sibling classes; a datapack reload does not add entries to any of those registries.

note

Minecraft 26.3 also ships a vanilla registry named number_provider_type. MiXianTu currently registers its own registry under that name, so the two can be merged in a later version.

Action Types

Action Category	Reference
Entity Action	Entity Action Types
Bi-entity Action	Bi-entity Action Types
Block Action	Block Action Types
Item Action	Item Action Types

Condition Types

Condition Category	Reference
Entity Condition	Entity Condition Types
Bi-entity Condition	Bi-entity Condition Types
Block Condition	Block Condition Types
Item Condition	Item Condition Types
Damage Condition	Damage Condition Types

Number Provider Types

Any number that must change with level, realm or event context is a NumberProvider. See Number Provider Types for the shorthand forms, the built-in providers, the formula functions and the available formula variables.

Other Type Families

The remaining built-in families share the same dispatch rules but are small enough to document together. See Other Type Families for the registered IDs and JSON fields of each of them:

• trigger_type
• cost_type
• badge_type
• ability_type
• ability_component_type
• ability_target_selector_type
• curse_type
• resource_bar_context
• resource_bar_render_data_type
• resource_bar_visibility_type
• resource_value_provider_type
• aura_maximum_type
• item_matcher_entry_type

Shared Data Types

Complex values that appear in many definitions are documented once in Shared Data Types: ResourceCost, ResourceGain, AttributeEntry, the generic holder/tag/matcher syntax, and the ItemMatcher entries.

Registering Custom Types

Custom types are registered in code, never in JSON:

Extension Route	Reference
Java registration into the built-in registries	Registry Guide
Script callbacks through the pre-registered mxt:js types	KubeJS API Reference

The mxt:js entry exists for entity, bi-entity, block and item actions, for entity, bi-entity, block, item and damage conditions, for number providers and for resource value providers. Callbacks are registered from kubejs/server_scripts/, and a missing callback makes an action do nothing, a condition return false and a value resolve to 0, with a warning in the log.