Skip to main content

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 saturn:cost_type registry: saturn:resource, mxt:aura, mxt:item and mxt:js; the other is the shorthand that writes no type and only id and amount, read as saturn: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.

saturn:resource​

Spends a data pack value out of the payer's own value account.

FieldTypeDefaultDescription
resourceValue IDrequiredThe value to spend
amountNumberProviderrequiredAmount to spend; must evaluate to a finite positive number
{"type": "mxt:resource", "resource": "example:qi", "amount": "5 + level"}

mxt:aura​

Spends by aura identity.

FieldTypeDefaultDescription
auraAura IDrequiredThe aura identity to spend
amountNumberProviderrequiredAmount 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.

FieldTypeDefaultDescription
itemsItemMatcherrequiredWhich items may be spent; see ItemMatcher
amountNumberProviderrequiredNumber 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.

FieldTypeDefaultDescription
idStringrequiredCallback id registered with MxtCosts.register
paramsObject{}Arbitrary JSON passed to the callback
{"type": "saturn: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 saturn: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.