Blueprint Data - mess1re/axiomata GitHub Wiki
| Result | Works with | What happens |
|---|---|---|
An item, no entity
|
Any item of any mod | The blueprint menu takes all materials at once and gives the item |
| An entity whose mod supports construction | Entities written for Axiomata, such as Siegeworks machines | The entity is placed unfinished and built stage by stage with the hammer |
| Any other entity | — | The blueprint is skipped when the server starts or reloads, with an error in the log |
A datapack can make blueprints of the first two kinds and override existing ones. An entity that is built in the world needs support from its own mod: it remembers its progress and shows its unfinished parts. A datapack cannot add that to an entity of another mod; see Developer Integration.
A block item as the result is crafted like any other item; blueprints do not place blocks.
Place one definition in:
data/<namespace>/blueprints/<path>.json
Its ID is <namespace>:<path>. Subdirectories are preserved. index.json is ignored.
The format does not depend on the game version or the mod loader: the same file works on every Axiomata build.
{
"formatVersion": 3,
"result": { "item": "example:machine_spawner", "entity": "example:machine" },
"stages": [
{ "section": "frame", "hits": 8,
"materials": { "#minecraft:planks": 4, "minecraft:oak_log": 2 } },
{ "section": "mechanism", "hits": 4,
"materials": { "minecraft:iron_ingot": 2 } }
]
}Each stage lists its own materials. The blueprint's total cost is the sum of its stages.
| Field | Required | Meaning |
|---|---|---|
formatVersion |
no |
3. Recommended so that a later format can recognise the file. |
result |
yes | What the blueprint makes. See below. |
stages |
yes | Construction stages in building order; at least one. |
outline |
no | Outline ID used at the drawing table. Defaults to the blueprint's own ID. |
returns |
no |
{ "#<tag>": "<item>" }: the item a tag material is given back as. See stages. |
Field names are case-sensitive. An unknown field is an error, so a misspelt name is reported instead of being ignored.
| Field | Required | Meaning |
|---|---|---|
item |
yes | Registered result item ID |
count |
no | Result stack size; defaults to 1
|
data |
no | Integer custom-data entries written to the result, e.g. { "Sections": 4 }
|
entity |
no | Entity placed in the world and built stage by stage |
placement |
no |
"ground" or "water"; defaults to "ground" when entity is set |
Without entity, the blueprint directly crafts the result from the total materials:
{
"formatVersion": 3,
"result": { "item": "minecraft:crossbow" },
"outline": "example:machine",
"stages": [
{ "section": "stock", "materials": { "#minecraft:planks": 2, "minecraft:stick": 3 } },
{ "section": "string", "materials": { "minecraft:string": 2, "minecraft:tripwire_hook": 1, "minecraft:iron_ingot": 1 } }
]
}Stage names of a crafted blueprint are only shown in its menu.
placement needs entity; the entity is never guessed from the item. The entity must support construction, as described above.
| Field | Required | Meaning |
|---|---|---|
section |
yes | Model section raised by this stage. The mod that adds the entity names its sections. |
materials |
no |
{ "<item or #tag>": count }. Omit it for a stage that costs only work. |
hits |
no | Base hammer work. Omit it to derive work from the material count and the server config. |
A material key is an item ID, or a tag ID with # in front. A tag accepts any item in it; screens show the tag's name while its icon cycles through the accepted items. An unnamed tag is shown as #namespace:path. Counts must be at least 1.
Tag names use language keys of the form tag.item.<namespace>.<path>, with slashes in the path replaced by dots. For example, #example:materials/timber uses tag.item.example.materials.timber.
Taking down a stage that was paid for but not finished gives back the items that were taken for it. A stage that already stands gives a tag back as its returns item, or as the first item of the tag when returns does not name one:
"returns": { "#minecraft:logs": "minecraft:oak_log", "#minecraft:planks": "minecraft:oak_planks" }Within one stage each item pays for one material only. Materials named by an item are paid first, so { "minecraft:oak_log": 6, "#minecraft:logs": 4 } needs ten logs, six of them oak.
Drawing quality scales the base materials and hits listed in the file. Plain quality uses 115% of the materials and 100% of the work. See Field Construction for the work formula.
Add fixed-count components to the item tag axiomata:quality_cost_exempt:
data/axiomata/tags/items/quality_cost_exempt.json
{
"replace": false,
"values": ["example:wheel", "example:barrel"]
}Exempt materials keep the counts listed in the blueprint, regardless of drawing quality. Hammer work still uses the quality multiplier. If a blueprint material is a tag, all items in that non-empty tag must be exempt for its count to stay unchanged.
A build is finished when every stage stands; it cannot stop partway. A result whose size varies, such as a ladder of any length, is an item: its size lives in the item's data and grows through ordinary crafting recipes. Files with minStages, starter or stage adds, which earlier versions read, are skipped with an error.
A data pack file at the same path replaces the original completely; fields are not merged. Copy the original from the mod jar and edit the copy. Keep the section names: they belong to the entity's model.
A data pack always ranks above the blueprints inside mod jars, on every loader, even where the loader puts mod data above world data packs.
For example, a frame that accepts any planks and takes longer:
{ "section": "frame", "hits": 20, "materials": { "#minecraft:planks": 12 } }A different file name adds a new blueprint instead of replacing one. It is drawn at the drawing table, which needs an outline. outline can borrow an existing one, e.g. "outline": "example:machine"; a drawing of your own is described in Drawing Outlines.
A file with mistakes is skipped and every mistake is logged with the pack and the field:
Skipping blueprint example:machine from pack 'file/my_pack': stages[0].materials.minecraft:oak_lgo: there is no item 'minecraft:oak_lgo' (a tag needs # in front)
The blueprint then comes from the next pack below that has a valid file. If none has, the blueprint loaded before the reload is kept.
When the server starts and after each /reload, Axiomata also checks what only a running world can tell:
- a blueprint whose entity does not support construction is skipped, with an error naming the entity;
- a blueprint without an outline is kept, but a warning says players cannot obtain it.
Files using lettered ingredients under key and stages under construction still load. The log notes that they use the old format.
| Old | Current |
|---|---|
key entries spent by letter in each stage |
Item IDs in each stage's materials
|
construction |
stages |
result.custom_data |
result.data |
result.deployment.preview_entity |
result.entity |
result.deployment.mode |
result.placement |
| one-element array root | object root |
Definitions are server data. Run /reload after changing a data pack. The loaded catalog is synchronized to clients.