Costs (cost_type)
Every field that consumes something is an array, and each entry writes one Cost. The four shapes that write a type are dispatched by the built-in mxt:cost_type registry: mxt:resource, mxt:aura, mxt:item and mxt:js; the other is the shorthand that writes no type and only id and amount, read as mxt:resource. The whole family is registered by the mod, so a data pack picks an entry but cannot add one. The all-or-nothing semantics of the whole array, the channel rules and the shared evaluation rules are on Shared Data Types · Cost.
This family is referenced all over the pack: in abilities, artifacts, techniques, talismans, cultivation, formations, pills and more, every "what does it take" field is written as one array of Cost, so it has no definition page of its own and stands as a type page by itself. Which definitions carry a costs field is written on those definition pages.
mxt:resource
Spends a data pack value out of the payer's own value account.
| Field | Type | Default | Description |
|---|---|---|---|
resource | Value ID | required | The value to spend |
amount | NumberProvider | required | Amount to spend; must evaluate to a finite positive number |
{"type": "mxt:resource", "resource": "example:qi", "amount": "5 + level"}mxt:aura
Spends by aura identity.
| Field | Type | Default | Description |
|---|---|---|---|
aura | Aura ID | required | The aura identity to spend |
amount | NumberProvider | required | Amount to spend; must evaluate to a finite positive number |
{"type": "mxt:aura", "aura": "example:fire_qi", "amount": 2}What gets charged depends on the payment channel: when the payer pays, the value that aura is measured in is charged (what a payer carries is a value, not an aura); when a shared aura pool or a block's store pays, that aura itself is charged, rounded up to whole units. The difference between the two channels is on Shared Data Types · Cost.
mxt:item
Spends matching items out of a player's inventory.
| Field | Type | Default | Description |
|---|---|---|---|
items | ItemMatcher | required | Which items may be spent; see ItemMatcher |
amount | NumberProvider | required | Number of matching items to spend, rounded up; a non-positive or non-finite result means this Cost cannot be paid |
{"type": "mxt:item", "items": "#minecraft:logs", "amount": 8}mxt:js
Both the check and the payment go to a server script callback.
| Field | Type | Default | Description |
|---|---|---|---|
id | String | required | Callback id registered with MxtCosts.register |
params | Object | {} | Arbitrary JSON passed to the callback |
{"type": "mxt:js", "id": "example:quest_token", "params": {"count": 3}}A script Cost is checked and then paid on the server, and it needs a player. The callback receives the payer and params, not the ability's formula context, because a Cost is evaluated with the payer alone.
The shorthand without type. An entry in the array may also write only id and amount, and it is read as mxt:resource:
{"id": "example:qi", "amount": 5}That entry is equivalent to {"type": "mxt:resource", "resource": "example:qi", "amount": 5}.
The payer is a living entity (a player, mob or summon), not necessarily a player. mxt:item needs a player inventory or a container supplied by the caller; mxt:js needs a player. Missing channels refuse simulation. Scripts keep their array positions and are not moved to the end.
Payment first diagnoses repeated targets (WARN in development, DEBUG in production), then simulates each entry in order. Any simulation refusal prevents all real deductions. Once all pass, deduction follows the same order; a real failure or runtime exception only logs WARN and continues with later entries and business effects, without propagation, rollback or cancellation. Repeated targets are not merged and balances are not reserved. Prefer one entry for each target's whole fee and avoid overlapping item demands. Success does not guarantee full collection; receipts report only known actual spending. Decode errors still fail the whole definition rather than silently dropping an entry.