The page is at https://www.minecraftjson.com.
With this tool, you can:
- Create complex chat messages, full-screen text alerts, custom signs, and books.
- Add fully formatted hover text, click actions, and more
- Show NBT data, scoreboard values, custom user keybinds
- Save and restore your commands
2
One reason the command behaves that way (apart from player motion being messed up as was mentioned) is because when you test for data within a list (values surrounded by square brackets), each element within the list you specify is checked within every element on the target.
For example, if you checked for "List:[1]" and the target had a list of "List:[3,2,1]", it would match because your specified value of "1" is compared with the target's values of "3", "2", and "1", and it matched the last value. Therefore your test of "Motion:[0.0,0.0,0.0]" is the exact same as testing "Motion:[0.0]".
But for whatever reason, the player's X and Z motion will be 0 even when moving normally, so the check for Motion:[0.0] will always find at least 1 element. Sprint-jumping causes the values to actually update, and no motion values are 0 at that point, so the check fails.
As for the objectives, you'd create them like so (prepended with "minecraft.custom:minecraft."):
1
It simply means unsorted, such that the order will be whatever it is internally.
Internally the sorting is based on load order, such as which chunks are accessed first. Each chunk has its own array of entities. For example, when a chunk is loaded, it loads entities in the order that they were saved to chunk files. You can manipulate the ordering by killing and summoning entities in a specific order in the same chunk.
However, this is not something you'll want to rely on because it could change in the future. The goal of "arbitrary" is to greatly increase performance by not using expensive sorting methods (which was not avoidable pre-1.13, as it would always sort by distance unless @r was used), so that's all you should really be using it for.
1
To elaborate further for this particular case: /testfor did not need to be used. If you're checking the location of a player with the selector in /testfor in order to teleport them elsewhere, then simply move the selector out of /testfor and into /tp. /testfor just serves as a redundant step.
1
The nested quotation marks will need to be escaped further (more backslashes). With no backslash, it will close the nested `Pages` string early and cause an NBT syntax error. With one backslash, it will close the `value` string of the text component early and cause a JSON syntax error.
The formula to determine the number of backslashes depending on the depth is: 2n+1 where n is the number of current backslashes. For example, the first depth is 1 backslash, while the next depth is 3 backslashes (then 7, then 15, and so on).
12
Index
Generic info
1. Intro
2. Errors
File editing
3. Location
4. Referencing
5. Replacing default advancements
6. Editing
Shared data structures
7. JSON structure
8. Shared: range
9. Shared: location object
10. Shared: distance object
11. Shared: status effects object
12. Shared: item object
13. Shared: entity object
14. Shared: block object
15. Shared: damage object
16. Shared: damage flags object
17. Shared: death object
Customizing advancements
18. Criteria
19. Requirements
20. Display
21. Rewards
22. Tree display
Conclusion
23. Q&A
24. External links
Generic info
Intro
Starting in 1.12, achievements, now referred to as "advancements", have become data-driven via modifiable JSON files rather than hard-coded. This allows map makers, modders, and server owners to modify and add advancements to their liking.
Advancements have a multitude of options, ranging from triggers based on the player's inventory to what biome they're in. Rewards can optionally be given, such as unlocking a recipe, providing an item, or providing experience. A new command, /advancement, has been introduced to supplement the files.
Advancements use the JSON format to store the advancement information in external files.
Errors
When an advancement fails for whatever reason, you can find failure messages in the Game Output window in the log files.
Game Output window
To open the Game Output window when launching the game, you must enable it in the "Settings" tab of the launcher.
This window will show the error and stacktrace explaining the issue.
Log files
If you no longer have the Game Output window open, you can check the output log. You can quickly access the Minecraft program files in the launcher by navigating to Launch Options -> + Add New, and clicking the "Go to folder" button:
From there, navigate to the /logs/latest.log file, which will contain the stacktrace. In this case, the error is stating that the advancement has a display, but is missing a description:
If you need assistance with your advancements, please post relevant advancement(s), as well as the error and stacktrace if applicable, in the following format:
File editing
File location
Advancements are saved within the world folder to be distributed with the world itself. More specifically, inside the /data/advancements/ folder. Here is an example structure within the world folder, where "New World" is the name of the world folder:
Namespaces
The root folder that you create within the /advancements/ folder will be referred to as the "namespace". This is what separates collections of advancements, such as for different mods or maps. File/folder names must all be lowercase to circumvent issues with differing operating system file structures.
From the image example above, "skylinerwadvancements", "anothermod", and "minecraft" are the namespaces.
The "minecraft" namespace in particular should only be used to overwrite default advancements, such as with the intent to prevent them from working. Place any new advancements in a new namespace and not within "minecraft".
Referencing
When referencing an advancement, whether it's from a parent or in a command, you must follow the following format excluding the .json extension:
Example, targeting the file /data/advancements/anothermod/challenges/kill_creepers.json:
By excluding the namespace, it will automatically assume it's meant to be "minecraft":
Replacing default advancements
You can create an advancement within the "minecraft" namespace with the same name as a default advancement. Anything that uses the default advancement will then use your custom one.
For example, given the filepath /data/advancements/minecraft/story/elytra.json, the following advancement will replace the default advancement that triggers by having any elytra in the inventory, and instead triggers by having an elytra slightly damaged in the inventory (which can trigger when starting to fly):
List of default advancements
The following is a list of default advancements. Be aware that this will dramatically change over time.
https://pastebin.com/L7G1RBdC
Editing
You will need to use a UTF-8 compliant text editor when creating and saving advancements that use unicode characters (such as the section symbol). By not encoding in UTF-8, special characters may not be saved correctly and Minecraft may fail to parse the data.
File/folder names must all be lowercase to circumvent issues with differing operating system file structures.
1. Windows Notepad is capable of saving as UTF-8, though will default to ANSI. Instructions for saving a .json in UTF-8:
1. Click Save or Save As.
2. Set "Save as type" to "All files (*.*)".
3. Name your file and append the name with ".json".
4. Set "Encoding" to "UTF-8".
5. Save.
Image example:
2. Notepad++ is a great alternative to using plain Notepad. Instructions for saving a .json in UTF-8:
1. Change the encoding to either "UTF-8" or "UTF-8 without BOM" under the "Encoding" menu. See image below.
2. Click Save or Save As.
3. Set "Save as type" to "All files (*.*)".
4. Name your file and append the name with ".json".
5. Save.
Image example:
3. Atom has multiple platform support. Instructions for saving a .json in UTF-8:
1. Change the encoding to "UTF-8" under the "Select Encoding" menu. See image below.
2. Click Save or Save As.
3. Set "Save as type" to "All files (*.*)".
4. Name your file and append the name with ".json".
5. Save.
Image example:
Shared data structures
JSON Structure
The following is a list of all possible keys for advancements.
Shared: range
A large number of advancement features make use of a "range" object, which is a comparison of the incoming number (such as the number of occupied inventory slots) to the specified range of numbers.
To check for an exact value, simply declare the range as a number. The following checks if the compared value is exactly 3.
To check between two values, the range must be specified as an object containing "min" and "max" numbers. The following checks if the compared value is between 1 and 3.
You can alternatively specify only the minmum or only the maximum, which will ignore a check for the opposing limiter. For example, the following checks if there are at least 3 occupied slots. The player's inventory could have 7 occupied slots and they will still match.
Versus the opposite, where the following checks if there are at most 2 occupied slots. The player's inventory could have 0 occupied slots and they will still match.
Shared: location object
A location object contains a small amount of data to specify an origin, biome, or generated structure. All options are available anywhere that this location object is used.
1. "position"
The "position" object contains "x", "y", and "z" ranges to check the global position of the player in the world. You do not need to specify all of the axes. For example, the following checks if the player is at Y62 or lower.
2. "biome"
The "biome" string specifies the name ID of the biome that the player must stand within. You can find a list of name IDs for biomes here. The following checks if the player has visited the "minecraft:desert" biome.
3. "feature"
The "feature" string specifies the name ID of a structure. The player must be standing within the bounding box of that structure to be detected. The following checks if the player is inside an "EndCity" structure.
4. "dimension"
The "dimension" string specifies the name ID of a dimension to find the player in. Accepted values are "overworld", "the_nether", and "the_end". The following checks if the player is anywhere in the nether.
Shared: distance object
The distance object contains information about the distance between the advancement-earning player and an unspecified origin. The origin cannot be directly defined but changes depending on the trigger; see each trigger that uses this for specific information. All options are available anywhere that this location object is used.
1. "x", "y", "z"
The "x", "y", and "z" ranges each check if the player is a number of blocks in either direction of the origin in the specified axis. You do not need to specify all of the axes. For example, the following checks if the player is within 40 blocks in either the positive or negative X direction of the origin.
2. "absolute"
The "absolute" range checks if the player is within a number of blocks on all axes. You would use this instead of "x/y/z" if all axes are uniform. The following checks if the player is outside a 5-block range of an origin.
3. "horizontal"
The "horizontal" range checks if the player is within a number of blocks on the X and Z axes, ignoring the Y axis. The following checks if the player is withn a 10-block range of an origin, but only on the X and Z axes.
Shared: status effects object
A status effect object contains nested objects, whose key names reflect status effect IDS. All options are available anywhere that this item object is used.
1. "amplifier"
The "amplifier" range checks the amplifier of the specified effect. The following checks if the amplifier is 10 or higher.
2. "duration"
The "duration" range checks the remaining duration in ticks of the specified effect. The following checks if the effect has at least 15 seconds (300 ticks) remaining.
3. "ambient"
The "ambient" boolean checks if the effect has the "ambient" flag set to true.
4. "visible"
The "visible" boolean checks if the effect has the "visible" flag set to true.
Shared: item object
An item object contains a handful of data to compare to an incoming item stack. All options are available anywhere that this item object is used.
1. "item"
The "item" string specifies a base item ID to compare the item to. The following checks if the item is redstone.
2. "data"
The "data" integer specifies a metadata of the item. The following checks if the item is a polished granite block.
3. "durability
The "data" range specifies the remaining durability of an item. The following checks if the item has 400 or more durability remaining.
4. "count"
The "count" range specifies the number of items in a single stack. This cannot be used to check the number of items across the inventory as a whole. The following checks if the item has 16 or more in its stack.
5. "potion"
The "potion" string specifies the default brewed potion ID that the item must contain, specified in the Potion NBT string. The wiki contains a list of those IDs here.
The item does not have to be a potion. As long as the item has the Potion NBT string, it will match:
6. "enchantments"
The "enchantments" list checks the item's enchantments (whether in the ench NBT list for all items excluding books, or the StoredEnchantments NBT list for only books) for matching data. If only an empty object is specified, the player's inventory is checked for any enchanted items.
The "enchantment" string will specify the enchantment ID to look for. The following checks the item for the Sharpness enchantment.
The "levels" range will specify the range of levels to find for an enchantment. The following checks if the player has any enchantments level 3 or higher.
And combining it with an ID, the following checks if the player has Sharpness 5.
7. "nbt"
The "nbt" string compares the raw NBT input to the item's NBT data. This raw data starts within the "tag" compound of the item format and must be surrounded by curly brackets. The following checks if the item has a specific display name.
Shared: entity object
An entity object contains a handful of data to compare to an incoming entity. All options are available anywhere that this entity object is used.
1. "type"
The "type" string specifies the entity ID to match against. For example, the following checks if the incoming entity is a creeper.
2. "distance"
The "distance" distance object specifies the distance between the advancement-earning player and an entity's origin. The following checks if the player is within 10 blocks of the entity.
3. "location"
The "location" location object checks data concerning the entity's location in the world. The following checks if the entity is in the desert biome.
4. "effects"
The "effects" status effects object checks data concerning the entity's status effects. The following checks if the entity has Speed 2.
5. "nbt"
The "nbt" string compares the raw NBT input to the entity's NBT data. This raw data starts within the root of the entity format and must be surrounded by curly brackets. The following checks if the entity has a specific tag within its "Tags" list.
Shared: block object
A block object contains a handful of data to compare to an incoming block. All options are available anywhere that this entity object is used.
1. "block"
The "block" string specifies a base block ID to detect the player in. For example, the following checks if the block has the base ID of "minecraft:tallgrass" (includes grass, fern, and double tallgrass).
2. "state"
The "state" object contains a list of custom keys, much like "criteria" does. The names for these keys will correspond to the blockstate name you want to detect, and the value corresponds to possible values for that blockstate. For "minecraft:tallgrass", the "type" blockstate specifies which of the tallgrass blocks it is. The "block" string must be specified to use this condition. The following checks if the tallgrass is a fern.
Shared: damage object
A damage object contains a large amount of information about the incoming or outgoing damage. All options are available anywhere that this damage object is used.
1. "dealt"
A range checking the raw incoming damage before damage reduction. For example, the following checks the damage of an un-owned arrow (via /summon) before that damage was either reduced or blocked with a shield entirely.
2. "taken"
A range checking the incoming damage after damage reduction. For example, the following checks if the resulting damage after reductions was at least 5.0.
3. "blocked"
Checks if the incoming damage was successfully blocked, provided that the "damage_flags_object.bypasses_armor" ("unblockable") flag isn't true. The following checks if the player failed to block a skeleton's attack (either by an arrow or melee weapon).
4. "type"
A damage flag object that checks various flags about the damage. The following checks if the damage was a projectile caused by a skeleton (though does not necessarily mean the direct cause of the damage was an arrow).
5. "source_entity"
An entity object that checks information about either the entity hit or the entity dealing the damage. Note that for players being the source entity, the nested "type" string can essentially only be "minecraft:player". The following checks if a skeleton was at least 10 blocks away when it hit the player.
Shared: damage flags object
A damage flags object checks different flags concerning the incoming or outgoing damage. All options are available anywhere that this damage flags object is used.
1. "bypasses_armor"
Checks the "unblockable" flag for the incoming damage. This is true for: fire, suffocation (blocks & world border), entity cramming, drowning, starving, falling, flying into a wall, void (the Void & /kill), health recalcuation, magic damage, and wither effect damage. The following checks if the damage is caused by any damage that cannot be blocked.
2. "bypasses_invulnerability"
Checks if the damage source can inflict damage on creative mode players. This is true for: void damage. The following checks if the incoming damage is not caused by the Void or /kill.
3. "bypasses_magic"
Checks the "damageIsAbsolute" flag for the incoming damage. This is true for: starvation. The following checks if the player is taking starvation damage.
4. "is_explosion"
Checks the "explosion" flag for the incoming damage. This is true for: creepers, ender crystals, TNT, Minecart TNT, ghast fireballs, beds, the wither, and wither skulls. The following checks if the "explosion" flag is true.
5. "is_fire"
Checks the "fire" flag for the incoming damage. This is true for: standing in a fire block, being on fire, standing on magma, standing in lava, ghast fireballs, and blaze fireballs. The following checks if the player is not taking damage from fire sources.
6. "is_magic"
Checks the "magicDamage" flag for the incoming damage. This is true for: thorns, Instant Damage effect, Poison effect, part of Guardian laser damage, evocation fangs, and un-owned wither skulls (via /summon). The following checks if the incoming damage is flagged as magic damage.
7. "is_projectile"
Checks the "projectile" flag for the incoming damage. This is true for: arrows, ghast fireballs, blaze fireballs, enderpearls, eggs, snowballs, shulker bullets, and llama spit. The following checks if the incoming damage is specifically not a projectile.
8. "source_entity"
An entity object that specifies the "owner" of the damage. For example, if the player was hit by an arrow shot by a skeleton, the skeleton would be the "source entity". The damage object already makes use of this check, so it is pointless to specify a source entity twice. This particular check is still useful for triggers that only use a damage flags object rather than a damage object.
9. "direct_entity"
An entity object that specifies the direct cause of the damage. For example, if the player was hit by an arrow shot by a skeleton, the arrow would be the "direct entity". The following ensures the player was hit by an arrow shot by a skeleton.
Shared: death object
The death object contains information about both the killer/killed entity (changing depending on the trigger) and the killing blow. All options are available anywhere that this death object is used.
1. "entity"
An entity object that will either describe the entity that was killed or the killer itself, depending on the trigger being used; see each trigger that uses this for specific information. To be clear: this does not always describe the entity that died. The following checks if the killed entity or killer was a creeper.
2. "killing_blow"
A damage flags object that contains damage flags about the killing blow against the dead entity. Be aware that this is not the damage object, so the options from that object are unavailable. The following checks if the entity had died due to an explosion.
Customizing advancements
Criteria
An advancement must include a set of rules that activate the advancement, specified in the "criteria" object. Each object nested within will contain a custom name of your choosing, to later be used with the optional "requirements" list or the /advancement command. When the player matches a criterion at any point, that fulfillment will be remembered, allowing the player to fulfill all criteria over time rather than all at the same time.
Within each criterion there must be a trigger, specified by the "trigger" string.
If "requirements" is not specified, then all criteria must be met for the advancement to be granted.
The following advancement is granted provided both the "custom_test_name" and "take_damage" criteria succeeds, where the names can be anything you want. The player can breed animals together, and then at any point in the future take damage to complete the advancement (or vice versa). As "requirements" is not specified, both criteria must be fulfilled.
While the following advancement is granted provided either the "custom_test_name" and "take_damage" criteria succeeds. See the Requirements section for more details.
The custom criteria names are local to that file and cannot be referred to in other files.
Triggers
Go to list of triggers
Processing order of triggers
The following timeline describes the order in which specific triggers activate in each game tick. This can be useful when running a function as a reward. For example, if you needed to run commands before entities are processed (and after command blocks are processed), the "minecraft:tick" trigger will do so. If you needed to run commands after entities are processed, you would use the "gameLoopFunction" gamerule to run the necessary function.
Requirements
The "requirements" list specifies a Conjunctive Normal Form structure to accompany criteria. It essentially allows boolean logic to determine when the advancement is granted based on the accompanying criteria. The list contains more lists, which in turn contains strings that equal the names of the criteria. You would use this if you want to use an OR operation. Each new list is a new AND operation, while each comma-separated string within the list is an OR operation.
If "requirements" is not specified, then all criteria must be fulfilled. If this list is specified, then every criteria must be included in "requirements" to determine which ones need to be fulfilled.
Given the following advancement:
Both "trigger_1" and "trigger_2" criteria must be fulfilled before the advancement can be granted. Since that would be the case without "requirements", it is not necessary to use it here. Using logical operators, this can be viewed as:
Modifying the requirements list slightly, which joins "trigger_2" with "trigger_1":
Now either "trigger_1" or "trigger_2" must be completed to be granted the advancement. Using logical operators, this can be viewed as:
Given the following advancement:
The advancement is granted if the "trigger_1" criterion is met, while either "trigger_2" and "trigger_3" are also met. If only "trigger_1" is completed, the advancement is not granted. Using logical operators, this can be viewed as:
And modifying the requirements slightly:
The advancement is granted if any of the criteria are met. Using logical operators, this can be viewed as:
Display
The optional "display" object contains information about the display in the "Advancements" menu. If this object does not exist, the advancement will be hidden from the "Advancements" menu and popup notifications will not appear.
Title, description, & icon
When the "display" object exists, the "title", "description", and "icon" tags must be specified. The background for the icon for each advancement will range from gray to red depending on the number of criteria fulfilled in that advancement.
1. "title"
The title can either be a simple string or a text component object. This title is shown in the "Advancements" menu when hovering over the icon, as well as in the popup notification when completing the advancement.
Given the following advancement, which uses a simple string for the title:
This will display as:
Or you can specify formatting for the text using the text component (note that many text component features are unavailable, such as selectors, scores, and event listeners):
This will display as:
2. "description"
The description can either be a simple string or a text component object. This description is shown in the "Advancements" menu when hovering over the icon, but not in the popup notification when completing the advancement. The description can be blank for no description to appear, but the tag itself must still exist.
Given the following advancement, which uses a simple string for the description:
This will display as:
Or you can specify formatting for the text using the text component (note that many text component features are unavailable, such as selectors, scores, and event listeners):
This will display as:
3. "icon"
The "icon" object holds a required item ID and an optional metadata value of the item. This icon is shown in the "Advancements" menu, as well as in the popup notification when completing the advancement. The following icon specifies red wool
Background
The "background" is an optional string for all advancements, but is only used by "root" advancements (i.e. when no parent is defined). This is the background that appears behind all of the icons. The value is a resource location to any image within a resource pack. For example, the following advancement will display a tiled gold block background, coming from the default block texture:
Image of the result:
Frame
An optional "frame" string modifies the border shape around the icon, accepting one of three possible values: "task", "challenge", and "goal". When not specified, it will default to "task".
The following advancement makes use of the "challenge" frame.
The following advancement makes use of the "goal" frame.
Show toast
An optional "show_toast" boolean can be specified in order to prevent the popup notification in the upper right-hand corner of the screen from appearing when the player fulfills an advancement. It defaults to true, and setting it to false will hide the popup.
Announce to chat
An optional "announce_to_chat" boolean can be specified in order to prevent a chat message from being sent telling all players that somebody fulfilled an advancement. It defaults to true, and setting it to false will prevent chat messages from being sent.
The announceAdvancements gamerule can globally disable fulfillment messages, overriding the value of "announce_to_chat" for individual advancements.
Hidden
An optional "hidden" boolean can be specified in order to prevent child advancements from displaying in the "Advancements" menu until they are completed.
Rewards
The "rewards" object specifies multiple types of rewards to provide the player upon completing the advancement.
"recipes"
This list specifies multiple recipes to unlock for the player upon completing the advancement. The following advancement unlocks the "minecraft:redstone" and "minecraft:ladder" recipes together.
"loot"
This list specifies multiple loot tables to process, providing the player with the resulting item(s). The following advancement provides players with items from "minecraft:entities/creeper" and "minecraft:chests/simple_dungeon".
"experience"
This number (not range) specifies the amount of experience (not levels) to reward the player with.
"function"
This string specifies a single function file to run, with the value being the resource location to that function. The player will be considered the command sender and CommandStats trigger target, which means sender bias (such as from "@s") will always target that player, and that player will trigger their own stored CommandStats. Each command will run in the specified order in the function. If the advancement is granted via command block, all of the listed commands will execute immediately, allowing other command blocks further in the chain to run based off of the results of the advancement's function being run (although you do not need to use advancements for this if focusing on functions).
All rewards can be used at the same time.
Tree display
When an advancement has a display, it will be shown in the "Advancements" menu under a relevant tab. Root advancements will be the "owner" of a tab, with new tabs appearing for each unique root:
Any advancements referring to the root will be its children and are displayed in a branching tree:
Root
A root advancement will be one without a parent defined. If a root has a display, it will be the left-most icon in the tree. If a root does not have a display, a tab in the "Advancements" menu will not be shown, effectively hiding all branches in the tree. The popup notification for branches will be displayed even in that case, allowing you to show the player custom notifications without having to have a tab in the "Advancements" menu.
A root can also control the background of the tab.
The following is a proper root that will be shown in the menu, as it has both a display and no parent:
While the following is an invisible root, as it has neither a display nor a parent:
Branches
A branch is defined by having a "parent" string. The parent specifies the resource location of another advancement, where the branch visually extends from the parent. Note that the parent does not actually need to be completed in order for the branch to be completed.
The visual structure of the tree will be automatically generated.
For example, the following set of advancements defines a root and two branches, where the branches are direct descendents of the root:
/custom/root.json
/custom/branch_a.json
/custom/branch_b.json
Visual:
Changing /custom/branch_b.json to the following will cause it to branch off of "custom:branch_a" rather than the root:
Which would then show as a direct line of branches:
Since you can have multiple branches per parent, complex trees can be created. The following image is a segment from the default "story" tab for vanilla Minecraft, showing complex connections between branches:
Conclusion
Q&A
Coming soon...
External links
- Generic JSON Validator
- Minecraft Wiki: Advancements
Translations:
- Chinese
97
Index
Generic info
1. Intro
2. Errors
3. JSON Structure
4. Unicode & escape sequences
In-game features
5. /tellraw
6. /title
7. Books
8. Signs
9. Advancements
Text component
10. Text input
11. Text styling
12. Event listeners
13. Adding text
Additional usage info
14. Inheritance
15. Senders & origins
16. /trigger
Conclusion
17. Q&A
18. External links
19. Conclusion
Generic info
Intro
The "Text Component" is Minecraft's text handling system, in which the text to parse is stored as JSON. It features basic text styling such as color and formatting (bold, italic, underline), parsing of anonymous data such as target selectors or playerscores, use of translations, as well as advanced options through clickEvents and hoverEvents to, for example, run a command when clicked or display more data when the mouse hovers over text.
This thread will cover how to use the text component with various in-game features, but not all component options are available for all features. Below is a key that will indicate what features a component option if available for.
= /tellraw
= /title
= Books
= Signs
= Advancements
Errors
If you have any issues running commands, please paste your commands here along with any error messages or unexpected behavior. If the command is long, please post them in a spoiler:
You can check for valid JSON using a generic validator such as JSONLint.
JSON structure
The following is a list of all possible keys for the text component. The wiki will have an up-to-date version here if this is outdated.
Unicode & escape sequences
The text component supports the use of Java's escape sequences, which includes unicode support. Not all escape sequences are supported, and not all unicode characters may be visible.
\u0000 to \uFFFF
Specifies a unicode character, replacing 0000 with the hex value. See here for unicode characters. For example, the following produces the pilcrow/paragraph sign, being unicode character 00B6:
\n
"Newline" character, pushing text to the next line. While with signs it can be used, the text pushed to the next line will not be visible.
\" and \' and \\
Allows the usage of quotation marks nested within quotation marks, such as NBT data for various click/hover events, as well as backslashes as literal characters rather than as an escape sequence.
Note that for nested quotes, deeper-nested quotation marks will need to be escaped further. The formula to obtain the number of backslashes needed is (2 * [current backslashes]) + 1. For example, if a quotation mark is needed as a literal value, but is already inside a set of quotes that has 1 backslash, 3 backslashes are needed in order to use the quotation marks:
The next depth would be 7, then 15, and so on.
\t and \b and \f and \r
None of these escape characters can be used with the text component.
In-game features
/tellraw
The /tellraw command adds a message to the chat for specific players. It has access to most features of the text component.
Unavailable features:
1. "open_file" click event.
2. "change_page" click event.
/title
The /title command adds a message at the center of the screen for specific players. It has access to most basic features of the text component, but lacks support for event listeners. The wiki lists command syntax and general usage info for /title here.
Unavailable features:
1. All event listeners.
Books
Currently only the pages list tag supports strings that contains a JSON object. The title and author string tags do not. In order for a book to be considered "valid", the title tag must be at maximum 32 characters long. Any higher and the book will only display "* Invalid book tag*".
Because the NBT data must be string data, quotation marks must be used as other characters would invalidate the JSON object. This also means that any nested quotation marks must be escaped.
While the JSON format for pages can be lenient (i.e. without required quotation marks around all key names and strings), it is not recommended. All other usage of the text component has switched to strict, and books will do so in the future.
Note that a bug currently causes inconsistencies with text styling between books and other features using the text component (see MC-62866).
Unavailable features:
1. insertion event listener.
2. open_file click event.
3. suggest_command click event.
Signs
Signs allow usage of the text component through the Text1, Text2, Text3, Text4 string tags. In order for any text on the sign to be valid and remain after reloading, all four tags must exist and must contain a valid text component.
Because the NBT data must be string data, quotation marks must be used as other characters would invalidate the JSON object. This also means that any nested quotation marks must be escaped.
Unavailable features:
1. insertion event listener.
2. open_file click event.
3. open_url click event.
4. suggest_command click event.
5. change_page click event.
6. All hover events.
Advancements
Advancements can use the text component in their "title" and "description" keys. Since advancements themselves use the JSON format, there is no need to encase the entire text component in quotation marks.
Unavailable features:
1. Score text.
1. Selector text.
2. All event listeners.
Text component
Text input
The first step to creating a text component is to specify the text to be shown. There are various methods to display text, but only one may be used at a time.
The order of precedence is as follows, from highest to lowest: text, translate, score, selector, keybind.
For example, if translate and selector are both defined at the same depth, translate will be used. This means text supersedes all.
One of these keys must be defined for the text component to be valid, though does not need to contain text.
Alternatively, if within an array of text components (such as from instantiation or via extra), a lone string will act as text.
"text"
Basic text with no parsing other than escape sequence support. Target selectors are not parsed using this option.
If specifying a lone string within an array of text components (such as from instantiation or via extra), the input will be parsed as the text option.
"translate"
Sends input through the translation parser, useful for multi-lingual support. The input is expected to be the language key (e.g. gui.toTitle), but if the key is invalid it will be parsed as though it were the key's value instead. The output shown will be dependent on the player's language setting, unless the key is invalid.
Example, showing that invalid key results in input being parsed as output.
Conversion flags & "with"
Minecraft's language files support the usage of several conversion flags, which are placeholders for text. For example:
%s is the placeholder, which is text to be inserted at a later point. While the language files support the use of a handful of different conversion flags, all flags are converted to %s or %#$s. See here for a more in-depth explanation of placeholders, but be aware that Minecraft implements them manually and thus not all are available.
The with array will hold the extra data to be inserted. Example, where the %s placeholder is replaced with "Creeper":
Conversion flags are also supported when specifying an invalid key, but be aware that the game is expecting only %s or %#$s. No other conversion flag will work for those cases.
Below is a list of conversion flags, how they are interpreted, and how they are intended to be used.
%s
The next string in the sequence inside with. For example, given the following:
The first %s will grab the first record within with, being "STRING1". The second %s will grab the second record, being "STRING2". The third will then grab the third record, but because there is none, will simply become blank.
%d
Intended to be an integer. Converted to %s upon reading the language files.
%f
Intended to be a float. Converted to %s upon reading the language files.
%#$s
A specific record inside with. The # is replaced by the incremental record number within the array. Note that this does not affect the sequence used by %s. For example, given the following:
%1$s gets the first record, being "STRING1". %2$s grabs the second record, being "STRING2". The first record is then grabbed again. Finally, %s accesses the current string in its sequence, and since no other %s was used, it will grab the first record "STRING1".
%#$d
Intended to be a specific integer record. Converted to %#$s upon reading the language files.
%#$f
Intended to be a specific float record. Converted to %#$s upon reading the language files.
%.#f
Intended to be a float with a maximum number of decimal places. Converted to %s upon reading the language files.
%.#d
While technically possible with Minecraft's parser, does not represent anything. Converted to %s upon reading the language files.
"with" & text components
The records inside with may also be text components. Availability will vary between in-game features, as usual. For example, the following replaces %s with a parsed target selector:
"score"
Displays the value of a score based on a playerscore on the scoreboard. The score object holds three keys: name, objective, and value.
A bug (see MC-56373) currently prevents full usage within hover events ("value" does work).
"name" is the name of the player stored on the scoreboard, which may be a "fake" player. It can also be a target selector that must resolve to 1 target, and may target non-player entities. With a book, /tellraw, or /title, using the wildcard * in place of a name/selector will cause all players will see their own score in the specified objective. Signs cannot use the wildcard.
"objective" is the objective to find the player's score from.
"value" stores the processed value so that the score does not need to be re-evaluated. If defined, this value is used instead of a processed score.
Example, where all players are shown the score of the nearest player in the "TEST" objective:
Example, where all players will see their own score in the "TEST" objective:
Example, where a score is not processed due to value being present and will instead display "hello":
"selector"
Processes a target selector into a pre-formatted set of discovered names, complete with event listeners where applicable. Multiple targets may be obtained, with commas separating each one and a final "and" for the last target.
The resulting formatting cannot be overwritten. This includes all styling from team prefixes, insertion event for entity & player names, clickEvents for player names, and hoverEvents for entity & player names.
A bug (see MC-56373) prevents it from working in hover events.
Example, assuming there are 3 creepers:
"keybind"
Shows the player their corresponding key for a keybind. The following is a list of valid keybinds:
"key.forward"
"key.left"
"key.back"
"key.right"
"key.jump"
"key.sneak"
"key.sprint"
"key.inventory"
"key.swapHands"
"key.drop"
"key.use"
"key.attack"
"key.pickItem"
"key.chat"
"key.playerlist"
"key.command"
"key.screenshot"
"key.togglePerspective"
"key.smoothCamera"
"key.fullscreen"
"key.spectatorOutlines"
"key.hotbar.1"
"key.hotbar.2"
"key.hotbar.3"
"key.hotbar.4"
"key.hotbar.5"
"key.hotbar.6"
"key.hotbar.7"
"key.hotbar.8"
"key.hotbar.9"
"key.saveToolbarActivator"
"key.loadToolbarActivator"
Example, showing the player their key for dropping an item (defaulting to Q):
Text styling
"color"
Choose from a set of pre-determined colors that will be applied to the text. Defaults to "white". List of colors and their IDs:
Example, where the text is colored "red":
"reset" may be used to reset the color to default.
The following is only meant to document technical details as they exist. You should not be using the following because it is deprecated. There are newer and more preferred features to use than the following, and the following may not exist forever.
Apart from colors, other styling options can be used as the value. Since you can only have one key of the same name, you'd be unable to specify a color at the same depth without relying on inheritance. The accepted values are:
1. "obfuscated"
2. "bold"
3. "italic"
4. "strikethrough"
5. "underline"
6. "reset"
"reset" will only reset styling options used in the color tag. It will not reset the standard styling options, such as from the underlined tag.
"bold"
Boolean; increases text thickness. Defaults to "false".
"italic"
Boolean; emphasises text. Defaults to "false".
"underlined"
Boolean; underlines text. Defaults to "false".
"strikethrough"
Boolean; adds a strikethrough in the middle of text. Defaults to "false".
"obfuscated"
Boolean; causes text to cycle through random letters (example: ). Defaults to "false".
Event listeners
"insertion"
When the player holds SHIFT and left-clicks text, the insertion event listener will fire. This will append text to the player's current chat input, provided their chat is open. This is restricted to /tellraw only.
"clickEvent"
When the player left-clicks /tellraw or book text, or right-clicks on a sign, the clickEvent listener will fire.
For signs, all clickEvents must be at the root of inheritance. Clicking on a sign activates the listener for all of the Text1/Text2/Text3/Text4 tags, thus the maximum number of clickEvents on a sign is 4.
The event is stored within a clickEvent object, with an action string holding the type of event and a value holding the various relevant values that corresponds with the action.
List of clickEvents
The following is a list of all possible clickEvents that can be used.
1. open_url
2. open_file
3. run_command
4. suggest_command
5. change_page
open_url
Opens a URL using Java's URI class. The only accepted protocols are "http" and "https", and one must be included. Web links must also be enabled.open_file
Cannot be used with commands. Opens a file on the clicking player's hard-drive. It is used in-game when taking a screenshot and clicking on the link provided.run_command
Runs a command with the clicking player set as the sender.For /tellraw and books, the clicking player is running the command as if they have typed the command themselves in the chat. This means they are subject to standard chat limitations, being a 256-character limit, required "/" for command usage, as well as the requirement of OP status to run OP-only commands. The player will also be kicked if using an illegal character, such as the section symbol (\u00A7) and the DEL control character (\u007F). If the command to run exceeds 256 characters, the remainder will be trimmed and the player will still attempt to run the command. The /trigger command was introduced to overcome these obstacles.
Signs will run commands themselves while setting the clicking player as the command sender, allowing players to run commands without standard chat limits as well as having sender bias apply to themselves. Note, however, that the coordinate origin of execution is still at the sign, so commands like /setblock will be run at the sign. This allows a player to modify the sign they click without having to know exactly where the sign is.
In terms of CommandStats, signs will be the one receiving return values and not the player. The sign would need to run /execute, which will activate CommandStat triggers for both the sign and the player. Each event will run one at a time, obtaining the return value, and then moving onto the next event if there is one (starting at Text1 and ending at Text4). This can allow for some complex command handling based on the sign's success at running commands.
For example, given the following command:
When the sign runs commands, it will set the nearest player's "OBJ" score equal to the success of the command. In Text1, the sign will run /testfor at its coordinate location, looking for any entities within 3 blocks of itself. It will then set the nearest player's score equal to that amount. In Text2, the sign will cause the nearest player with an "OBJ" score of at least 3 to run a /say command. That player's score will only be 3+ if there were 3+ entities around the sign. It will then set the nearest player's score to either 1 if the sign successfully ran /execute, or 0 if it did not.
suggest_command
Replaces the player's current chat input with the text in value. Unlike insertion, it completely replaces instead of appends.change_page
Used with books to switch to the page specified in value. If page number does not exist, nothing will happen."hoverEvent"
When the player hovers over /tellraw or book text with their mouse pointer, the hoverEvent listener will fire.
The event is stored within a hoverEvent object, with an action string holding the type of event and a value holding the various relevant values that corresponds with the action.
List of hoverEvents
The following is a list of all possible hoverEvents that can be used.
1. show_text
2. show_achievement
3. show_item
4. show_entity
show_text
Shows a tooltip populated by a text component, though could also just be a simple string.Unavailable features:
1. All event listeners.
2. "score" text, though an explicit "value" will work.
3. "selector" text.
See MC-56373 for issues concerning "score" and "selector".
show_achievement
Displays a pre-formatted achievement tooltip. May also show pre-formatted statistics tooltips, though will only show the statistic name. The wiki has a list of valid achievement IDs here, as well as statistic IDs here.Achievements will be prefixed by "achievement." while statistics are prefixed by "stat.".
The following shows the pre-formatted text template:
The first line will be the achievement or stat name, dependent on the string provided from "value".
The second line will either show "Achievement" or "Statistic" depending on the language setting, which is translated from the following keys in the language file:
The third line will display a description, which is only used for achievements.
If the value is not a valid achievement or statistic, it will instead display "Invalid statistic/achievement!".
show_item
Parses NBT input into an item and displays the result.The value is a string and must have nested quotation marks escaped. Must be valid NBT input starting with an unnamed compound. Note that if Advanced Tooltips is shown (F3 + H), extra data will be shown as it normally would.
If either the item data is invalid (wrong item ID, "Count" tag not 1+) or the NBT data is syntactically incorrect, "Invalid Item!" is shown instead.
show_entity
An advanced tooltip displaying an entity's name, type, and UUID. Advanced tooltips must be enabled to view (F3 + H). Note that this is not targeting any existing entities, but is instead just creating dummy text.The value is a string and must have nested quotation marks escaped. The value is NBT input of a specific structure, rather than entity data, but none of the following tags are required and can simply be blank:
None of the tags are required, but the game will render a line for both "name" and "id". "type" will only have a line dedicated to it if it's defined. The input does not need to be valid.
"name" is essentially the "CustomName" tag of the entity. "type" is the entity's savegame ID and will be appended by the corresponding numerical ID (90 (AKA Pig) if invalid). "id" is the UUID pair of the entity (determined by "UUIDLeast" and "UUIDMost" tags).
If the NBT data is syntactically invalid, "Invalid Entity!" will be displayed instead.
Adding text
"extra"
The "extra" array will accept a list of text components and strings. This tag is used in order to create more text with their own options. Note that the text components here will inherit from a parent first, but each are their own separate child. See Inheritance for more info.
For example, the following results in the parent ("First") being red, while its children ("Second" and "Third") inherit that property and are also red. The first child ("Second") set itself to be bold, unlike its parent, while the second child ("Third") does not change any properties that it inherited.
Array structure
A text component can instead be instantiated as an array rather than an object. This essentially allows one to skip using the "extra" tag entirely, and can also save on characters as it becomes quicker to nullify a parent.
Note that the first record defined will be marked as the parent, and all other records will inherit from that parent. For example, the following causes the first record ("Parent") to be the parent set to red, while the second record ("Child") inherits everything from the first record and will also be red.
A quick way to skip over the first record as the parent to avoid any unwanted inheritance is to simply input an empty string.
Additional usage info
Inheritance
Inheritance refers to component options that are transferred from a parent/root component to a child/nested component. This is revalent when dealing with the "extra" tag or array instantiation. A child will take on all options from a parent, including styling and event listeners.
When instantiating as an object, the initial text is the parent. For example, the following shows a parent with no children.
The following shows a parent, with absolutely everything inside the "extra" tag being a child (including any "grandchildren" and so on).
When instantiating as an array, the first record will be the parent while all other records are the children.
Each child can be a parent to their own children, and only their children will inherit their properties (as well as any properties inherited by a grandparent and so on). The following shows a parent that is bold, a child that inherits boldness and has the italic property, and a grandchild that is both bold, italic, and has its own property of being red.
The following demonstrates that siblings do not inherit from one another. While the parent is bold and causes both its children to be bold, the first child will be italic while the second child is underlined (and not italic).
Senders & origins
Initial parsing
When parsing the "selector" tag or the "name" tag in the "score" object, and if there is a command sender available, sender bias will apply, forcing them to always be the target.
This occurs when an entity runs a command (such as a player running the /tellraw or /title commands directly, or via the /execute command) or when the player opens a book for the first time.
For example, the following will cause all entities to say their own name no matter what:
This functionality is not available for signs as they do not have a sender to work from, and instead their selectors will parse without a sender bias from the blockspace that they are placed at.
run_command clickEvents
When a player activates a run_command event, they will be marked as the command sender as they are naturally the ones running the command. However, there is a key difference with signs: while /tellraw and books will use the player's current coordinates as the origin, clickEvents in signs will instead use the sign's coordinates as the origin, while still setting the clicking player as the command sender for sender bias to apply.
For example, the following will cause the clicking player to set a block above the sign, rather than above themselves, and to always say their own name:
This can be used very effectively in order to know exactly which sign the player had clicked while still being able to target the clicking player.
/trigger
The /trigger command was introduced as a way around the various chat restrictions when running commands from /tellraw and book clickEvents. /trigger can be used by non-OPs and will be shorter than the 256-character limit.
Syntax:
Players that run this command will only be capable of targeting their own objective, noted by the lack of a target selector in the syntax.
In order for the command to modify a score, the objective itself must use the "trigger" objective-type. This objective-type has a special feature in that it will be 'locked' in order to prevent being modified. This occurs when the value is modified by the /trigger command, though do note that if a player is not tracked in the objective they will still be considered 'locked'. Example:
The player's "OBJECTIVE" score will be enabled by default in this case. Changing their score with /scoreboard does not unlock the objective for the player, but because the player had never run /trigger yet, it will be enabled.
The following will cause the player to change their score to 1, and thus locking the objective for that player. The player will not be able to run /trigger to modify that score until they are unlocked.
The /scoreboard command can be used to unlock the objective.
The /execute command can be used to forcibly change a player's score by causing them to run /trigger. This can be useful to automatically lock a player's objective without waiting for them to run the command themselves. For example, the following will not change their score but will lock it:
Example usage with /tellraw:
The clicking player will set their "OBJECTIVE" score to 1 if it is enabled for that player, and if so, will then become disabled.
Conclusion
Q&A
Q. Can multiple clickEvents be run at the same time?
A: Only signs have this capability, and only 4 can run at a time. Click events on signs must be the root parent to function.
Q. Does the player activating a "run_command" clickEvent need to be OP'd?
A: Only for /tellraw and books. Signs do not require being OP'd. This requirement is useful as it can be used to differentiate between OP'd and non-OP'd players.
Q. What is the character limit for "run_command" clickEvents in /tellraw and books?
A: 256; any extra text beyond will be trimmed off, which can also lead to errors in command syntax.
Q. Can I use target selectors as values?
A: Yes, you must use the "selector" tag, which replaces the "text" tag. The input can only be a target selector.
Q. Is JSON the same as NBT?
A: No, they are two different formats with different parsing rules.
External links
Bug reports
MC-62866 (JSON Inheritance in Books Different)
MC-56373 (hoverEvent limitations)
Other
Text component generator by Ezfe
Sign generator by CrushedPixel
Book generator by CrushedPixel
1.8 lenient to 1.9 strict conversion
Basic online tool
MCEdit filter by Al_T
Conclusion
If you have any questions, just ask. If there is outdated, missing, or incorrect information, please correct me by leaving a reply in this topic or sending me a private message. I will attempt to keep this topic up-to-date.
36
Index
Generic info
1. Intro
2. Errors
3. JSON Structure
Files
4. Location
5. Referencing
6. Replacing default tables
7. Editing
Loot Construct
8. General info
9. Luck
10. Looted entity ("this")
11. Player context ("killer_player")
12. Damage source ("killer")
Customizing tables
13. Pools
14. Entries
15. Rolls
16. Bonus rolls
17. Items
18. Conditions
19. Duplicate functions & conditions
Usage
20. generic.luck, Luck, Unluck, Luck of the Sea
21. NBT data
Conclusion
22. Custom table example
23. Q&A
24. External links
25. Conclusion
Generic info
Intro
1.9 has introduced an organized collection of loot tables that determines what type of items are acquired from chests, hoppers, dispensers, droppers, mob drops, chest/hopper minecarts, and fishing. They allow a map/mod maker or server owner to modify what items are obtained as default loot, as well as add custom tables to be used alongside NBT data.
Loot tables are highly customizable, allowing numerous conditions with varying depths as well as functions to further modify the item(s) to provide. For command mechanisms, they will replace most loot-providing systems, such as those that use the HandItems and ArmorItems lists.
Loot tables use the JSON format to store the loot information in external files.
Errors
When a loot table fails to provide an item due to an error with the loot table itself (whether it is related to the file or the JSON structure itself), the Game Output tab in the launcher will provide the error. If you are experiencing problems with your loot tables, you may be able to find the answer within the output.
To see the output, you must keep the launcher visible while playing. You can enable this by opening the Minecraft launcher, clicking on "Edit Profile", and changing the "Launcher Visibility" to "Keep the launcher open":
Feel free to comment here for help with an issue while providing your loot table. Ensure you paste both the loot table you're using and the error (if applicable) in spoiler tags:
Common errors
1. Couldn't find resource table minecraft:tablename
2. Expected value at line # column #
3. Missing [key], expected to find a [type]
4. Expected loot table to be a JsonObject, was "??"
JSON Structure
The following is a list of all possible keys for loot tables. The wiki also includes the structure here.
Files
Location
Loot tables are saved within the world folder to be distributed with the world itself. More specifically, inside the data/loot_tables folder, which will not be created automatically. Here is an example structure within the world folder, where "New World" is the name of the world folder:
Namespaces
The folder that you create within the loot_tables folder will be referred to as the "namespace". This is what separates collections of loot tables, such as for different mods or maps. File/folder names must all be lowercase to circumvent issues with differing operating system file structures.
From the image example above, "skylinerwloot", "mocreatures", "anothermod", and "minecraft" are the namespaces.
The "minecraft" namespace in particular should only be used to overwrite default loot tables, such as replacing natural zombie drops. Place any new loot tables in a new namespace and not within "minecraft".
Referencing
When referencing a loot table, whether it's from within loot tables or in NBT data, you must follow the following format excluding the .json extension:
Example, targeting the file anothermod/bears/grizzly.json:
By excluding the namespace, it will automatically assume it's meant to be "minecraft":
Replacing default tables
You can create a loot table within the "minecraft" namespace with the same name as the default loot tables. Anything that uses these default tables will then use your custom one, without the need to modify NBT.
For example, given the filepath minecraft/entities/zombie.json, the following loot table will cause all default zombies to drop 0-2 feathers when killed, instead of the default rotten flesh.
List of default tables
The wiki has a description for each of the default loot tables here.
minecraft:empty
minecraft:chests/abandoned_mineshaft
minecraft:chests/desert_pyramid
minecraft:chests/end_city_treasure
minecraft:chests/igloo_chest
minecraft:chests/jungle_temple
minecraft:chests/jungle_temple_dispenser
minecraft:chests/nether_bridge
minecraft:chests/simple_dungeon
minecraft:chests/spawn_bonus_chest
minecraft:chests/stronghold_corridor
minecraft:chests/stronghold_crossing
minecraft:chests/stronghold_library
minecraft:chests/village_blacksmith
minecraft:chests/woodland_mansion
minecraft:entities/bat
minecraft:entities/blaze
minecraft:entities/cave_spider
minecraft:entities/chicken
minecraft:entities/cow
minecraft:entities/creeper
minecraft:entities/donkey
minecraft:entities/elder_guardian
minecraft:entities/ender_dragon
minecraft:entities/enderman
minecraft:entities/endermite
minecraft:entities/evocation_illager
minecraft:entities/ghast
minecraft:entities/giant
minecraft:entities/guardian
minecraft:entities/horse
minecraft:entities/husk
minecraft:entities/iron_golem
minecraft:entities/llama
minecraft:entities/magma_cube
minecraft:entities/mule
minecraft:entities/mushroom_cow
minecraft:entities/ocelot
minecraft:entities/parrot
minecraft:entities/pig
minecraft:entities/polar_bear
minecraft:entities/rabbit
minecraft:entities/sheep
minecraft:entities/shulker
minecraft:entities/silverfish
minecraft:entities/skeleton
minecraft:entities/skeleton_horse
minecraft:entities/slime
minecraft:entities/snowman
minecraft:entities/spider
minecraft:entities/squid
minecraft:entities/stray
minecraft:entities/vex
minecraft:entities/villager
minecraft:entities/vindication_illager
minecraft:entities/witch
minecraft:entities/wither_skeleton
minecraft:entities/wolf
minecraft:entities/zombie
minecraft:entities/zombie_horse
minecraft:entities/zombie_pigman
minecraft:entities/zombie_villager
minecraft:entities/sheep/black
minecraft:entities/sheep/blue
minecraft:entities/sheep/brown
minecraft:entities/sheep/cyan
minecraft:entities/sheep/gray
minecraft:entities/sheep/green
minecraft:entities/sheep/light_blue
minecraft:entities/sheep/lime
minecraft:entities/sheep/magenta
minecraft:entities/sheep/orange
minecraft:entities/sheep/pink
minecraft:entities/sheep/purple
minecraft:entities/sheep/red
minecraft:entities/sheep/silver
minecraft:entities/sheep/white
minecraft:entities/sheep/yellow
minecraft:gameplay/fishing
minecraft:gameplay/fishing/fish
minecraft:gameplay/fishing/junk
minecraft:gameplay/fishing/treasure
Editing
You will need to use a UTF-8 compliant text editor when creating and saving loot tables that use unicode characters (such as the section symbol). By not encoding in UTF-8, special characters may not be saved correctly and Minecraft may fail to parse the data.
File/folder names must all be lowercase to circumvent issues with differing operating system file structures.
1. Windows Notepad is capable of saving as UTF-8, though will default to ANSI. Instructions for saving a .json in UTF-8:
1. Click Save or Save As.
2. Set "Save as type" to "All files (*.*)".
3. Name your file and append the name with ".json".
4. Set "Encoding" to "UTF-8".
5. Save.
Image example:
2. Notepad++ is a great alternative to using plain Notepad. Instructions for saving a .json in UTF-8:
1. Change the encoding to either "UTF-8" or "UTF-8 without BOM" under the "Encoding" menu. See image below.
2. Click Save or Save As.
3. Set "Save as type" to "All files (*.*)".
4. Name your file and append the name with ".json".
5. Save.
Image example:
3. Atom has multiple platform support.
Loot construct
General info
When a loot table is accessed, some specific information is passed to it for the parser to work with. For example, a killed entity will be stored and passed to the loot table to use for features that look for a "this" entity (such as the "entity_properties" condition).
Not all of the necessary information is stored. Depending on the feature using the loot table, a "damage source" is not relevant (such as opening a chest). The following will describe the information that can be stored, when it actually is stored, and how it is used and can be used.
All cases when info is stored:
1. When a mob dies
2. When minecart chests are opened
3. When minecart hoppers are opened
4. When chests are opened
5. When hoppers are opened
6. When dispensers are opened
7. When droppers are opened
8. When fishing
Luck
See also: bonus_rolls, quality, Luck usage
"Luck" is stored as a single float value, usually being the final "generic.luck" attribute value of the player but will also be modified by the player's "Luck of the Sea" enchantment level for fishing.
Note that while this value is obtained from a relevant player, that player does not necessarily get stored as player context.
Hard-coded usage:
None
Loot table usage:
1. The "bonus_rolls" parameter for pools.
2. The "quality" parameter for entries.
When it is stored:
1. When a mob dies
2. When minecart chests are opened
3. When minecart hoppers are opened
4. When chests are opened
5. When hoppers are opened
6. When dispensers are opened
7. When droppers are opened
8. When fishing
Looted entity ("this")
Stores the entity class that was looted.
Hard-coded usage:
None
Loot table usage:
1. Accessed when using the "this" context for conditions.
When it is stored:
1. When a mob dies
Player context ("killer_player")
Stores the player class, intended to signify that the player had been the one who killed the looted entity. This does not mean the player was the one who dealt the final blow. Technically it does not even have to mean the player did any killing at all, as there is a possible player for the game to potentially store when opening a chest or fishing, but is only stored in cases where a mob dies.
Hard-coded usage:
1. The "killed_by_player" condition.
Loot table usage:
1. Accessed when using the "killer_player" context for conditions.
When it is stored:
1. When a mob dies (as long as the player had struck the mob within 3 seconds before death, or as long as a zombie pigman is angry at the player)
Damage source ("killer")
Stores information concerning the final blow to the killed entity. The killing entity that dealt the final blow, if applicable, is stored alongside this information.
However, only the killing entity is ever accessed and the rest of the damage information that is stored (such as the type of damage, like "fall" or "thorns") is not yet used. Even if there was no killing entity, the damage source will still be stored but is also still unused.
Hard-coded usage:
1. The "looting_enchant" condition, obtaining the killing entity info.
2. The "random_chance_with_looting" condition, obtaining the killing entity info.
Loot table usage:
1. The killing entity info is accessed when using the "killer" context for conditions.
When it is stored:
1. When a mob dies.
Customizing tables
Pools
The collection of different items that can be dropped, dependent on conditions or other factors, stored within the "pools" list. Every record within the pool will be accessed, each of which has its own set of entries, conditions, and rolls. The following has two different records within the pool; the first record will always result in stone, while the second record will be either another stone or a stick. The end result is either 2 stone or 1 stone and 1 stick.
Entries
Each pool requires a declaration of entries via the "entries" list. Each entry will then require stating what type of entry it is with the "type" string key. The accepted types are "item", "loot_table", and "empty".
The following will provide either an item, a nested loot table, or nothing.
item
States that the entry will be an actual item. The "name" string key is required and defines the item ID to be used. This particular type supports the use of "functions". See the Items section for extended usage of this type.
The following will provide either a stone or a feather.
loot_table
States that the entry will be another loot table. This simplifies loot tables that uses the same data as another. The "name" string key is required and defines which loot table is to be used. Does not support "functions".
Note that the other loot table's provided item is not affected by this loot table. If the other loot table has 3 rolls while this one has 1, the other loot table will cycle through all 3 of its own rolls.
A loot table may not point to itself in any manner. If the root loot table points to a second loot table that selects the root in a loop, the loot table will not function and no item will be provided.
The following will provide either an item from its own loot table, or provide item(s) from another loot table.
empty
States that the entry will be nothing. No item will be provided. Does not support "functions" and the "name" string key cannot be used. While "conditions" may be used, they are essentially useless.
The following will provide either nothing or a stone.
Rolls
A roll is the number of times the loot table will pick an item from its pool. It can either be defined as a "roll" integer key or a "roll" compound with "min" and "max" keys defined. In either case, a roll amount is required.
The following will provide exactly 3 results from the list of items.
The following will provide between 1 and 5 results from the list of items.
Bonus rolls
See also: quality, Luck usage
The player's "generic.luck" attribute can optionally modify the number of total "rolls" a pool will perform. The number of bonus rolls is specified with the "bonus_rolls" integer/compound key. If compound, it defines a minimum and maximum range with the "min" and "max" integers.
The formula is:
As such, if the bonus roll is negative while luck is positive, the number of total rolls provided is decreased. For example, with 1 roll, -1 bonus rolls, and a luck value of 1, the result is 0 rolls from that pool:
The following will always provide 2 stone (due to 2 initial rolls), and will also provide 1 extra stone for each point of "luck" the player has. If the player has 0 luck, they will be given 2 stone. If they have 1 luck, they will be given 3 stone.
The following will provide between 2-6 extra stone.
Items
Weight
A weight determines the chances of an item being picked in comparison to the weights of other items. If all items have the same weight, they all have the same chance of being picked. A weight is defined by the "weight" integer key and is optional. If not specified, the value defaults to 1. The following will provide 1 stone at half the rate as 1 stick.
To get an idea of how weights are used, imagine the instance of each item being multiplied by its weight. Using the above table, the following is a visual representation in which there are 2 sticks (weight of 2) and 1 stone (weight of 1). Since there are 2 sticks, they have a higher chance (exactly double) of being chosen compared to stone.
Quality
See also: bonus_rolls, Luck usage
Optionally changes the "weight" of the entry based on the killing/opening/fishing player's "generic.luck" attribute value. The attribute can be modified by either worn gear with the "AttributeModifiers" list or by giving the player the "Luck" potion effect.
The formula is:
The following will provide either stone or diamond at equal rates while the player does not have any Luck, but if the player has a Luck value of 2, the diamond will have its "weight" changed to 7.
Functions
Functions are optional operations to perform on the item, such as providing it a count between two values, giving it NBT data or a Damage value, as well as enchanting it using a random enchantment. The "functions" list will hold multiple compounds, while the "function" string key states which function is to be used. Individual functions may ask for more data, which is covered in the next section.
The IDs for functions will have the resource namespace default to "minecraft" (e.g. "minecraft:set_attributes") when not specified. If using mods, the namespace will be whatever the mod has implemented. Note that you cannot create your own functions without modding.
List of functions
The following is a list of all possible functions that can be used, along with any extra applicable data. Open the spoiler before clicking a link to be taken to the description.
1. set_count
2. set_data
3. set_damage
4. set_nbt
5. set_attributes
6. enchant_randomly
7. enchant_with_levels
8. looting_enchant
9. furnace_smelt
set_count
Sets the "Count" NBT value of the item either to an exact value or randomly between a minimum and maximum value. The range is defined within the "count" integer or compound. If this function is not used, only one of that item will be dropped.The following provides exactly 4 stone.
The following provides between 3 and 5 stone.
set_data
Sets the "Damage" NBT value of the item to the specified value or randomly between a minimum and maximum value. The exact value is defined with the "data" integer key, while the range is defined within the "data" compound.Cannot be used with items that have durability.
The following provides a mob head with a Damage value of 3 (resulting in a player head).
The following provides a dye with a Damage value randomly chosen between 1 and 4.
set_damage
Sets the percentage of durability remaining for items that have durability. 1.0 is 100% of durability remaining (undamaged) while 0.0 is no durability remaining. Does not function for items that have no durability. The "damage" float/compound keys will define the value.The following will either provide either an item at half durability or an item between 75% to 100% durability remaining.
set_nbt
Sets the "tag" NBT value of the item. The input is raw NBT data, just like the show_item action for hoverEvents in the JSON text component. The value is defined within the "tag" string key. Be sure to escape nested double quotes!set_attributes
Applies attribute modifiers to the item via the "modifiers" list.Each modifier will require:
1. An "attribute" string that states the attribute ("generic.maxHealth", "generic.armor", etc).
2. A "name" string that states the custom name of the attribute. Can be anything.
3. An "amount" float or compound, stating how much to modify the attribute. If compound, "min" and "max" floats define the range.
4. An "operation" string, stating which operation to use. The accepted inputs are "addition", "multiply_base", and "multiply_total".
5. A "slot" string or list, stating which one of the specified slots the item can be used in. Note that if using it as a list, it will randomly selecting one of the specified slots. Accepted slots are: "mainhand", "offhand", "feet", "legs", "chest", "head".
Optional input:
1. An "id" string tag that specifies the UUID of the modifier.
The following will provide a diamond sword that will increase the "generic.maxHealth" attribute, choosing a value randomly between 3.5 and 6.0, using the "addition" operation. The slot it is applied to will either be "mainhand" or "offhand".
The following will apply a "generic.attackDamage" modifier of exactly 1.0 in specifically the "chest" slot. The UUID is 00000000-0000-0001-0000-000000000001.
enchant_randomly
Randomly applies a single enchantment from a list of enchantment IDs, specified with the optional "enchantments" list. If "enchantments" is not specified, the item will be enchanted randomly with a compatible enchantment for that item.The following will apply a random enchantment and level of either Looting, Depth Strider, or Sharpness, along with a secondary enchantment that is compatible with the item.
enchant_with_levels
Applies an enchantment as if it were enchanted through an enchanting table, using a minimum and maximum level defined through the "levels" integer key or compound. The range of levels are the experience levels required for the enchantment, not the level of the enchantment applied.The "treasure" boolean key will allow treasure-only enchantments to be used (such as Mending or Frost Walker). If not defined, it will default to false.
The following provides a diamond sword enchanted at exactly level 30 while allowing the use of treasure-only enchantments.
The following provides a diamond sword with a random enchantment obtained between levels 25 and 30, disregarding treasure.
looting_enchant
The number of extra items to drop if the entity has the Looting enchantment on the item in their mainhand. Does not need to be a player entity, but must extend "LivingBase" (essentially all mobs, whether hostile or passive, as well as armor stands). Uses the same "count" integer/compound as set_count. The "limit" tag ensures that the resulting number of items cannot exceed that value.
The following provides an extra 30 stone for each level of Looting, but the player can receive no more than 80.
The following provides between 10 and 20 extra stone.
furnace_smelt
If the item to drop has a smelted crafting recipe, that resulting item will be supplied instead. The following provides charcoal instead of a log.
Conditions
Conditions are a list of requirements that must be met before either a pool can be used, an individual item can be selected, or before a function can be run. All conditions are stored within the "conditions" list, with the "condition" string key stating which internal condition function is used. Conditions may be applied at the same depth as "items", alongside each individual "item", or within "functions".
The IDs for conditions will have the resource namespace default to "minecraft" (e.g. "minecraft:random_chance") when not specified. If using mods, the namespace will be whatever the mod has implemented. Note that you cannot create your own conditions without modding.
Each condition runs one at a time. If any condition fails, the remainder in the same list will be ignored.
The following only provides items within the pool if the condition is met. Both the stone and stick will only be provided when killed by a player, otherwise nothing is provided.
The following only provides the individual item if the condition is met. The stone will always drop, but the stick will only drop when killed by a player. If the conditions are not met when selecting an item, the entry will not be selected. The pool will not re-roll and ignores the entry instead.
The following will only run the individual function if a condition was met. The following will run the "furnace_smelt" function only if the mob was killed by a player. If a player kills the mob, smooth stone will drop. Otherwise, cobblestone will drop.
List of conditions
The following is a list of all conditions that can be used. Open the spoiler before clicking a link to be taken to the description.
1. random_chance
2. random_chance_with_looting
3. killed_by_player
4. entity_properties
5. entity_scores
random_chance
Adds a modifier to the drop chances of the item/pool or chance to execute a function. The "chance" float key will hold a value between 0.0 and 1.0, with 1.0 being 100% chance.The following has a 30% chance to provide smooth stone. Otherwise, it provides cobblestone.
random_chance_with_looting
Modifies the chances of success based on the Looting enchantment on the item in the mainhand of the killing entity. Does not need to be a player entity, but must extend "LivingBase" (essentially all mobs, whether hostile or passive, as well as armor stands). The "chance" float key holds the base chance value while the "looting_multiplier" float key modifies the chances based on the Looting level.The following formula is used to determine the chances.
The following will smelt the cobblestone at a base 10% chance, increasing by 15% with each level of Looting. For example, with Looting 3, the following smelts cobblestone 55% of the time (0.1 + (3 * 0.15) = 0.55).
killed_by_player
Provides an item/pool or executes a function if the mob was specifically killed by a player. The "inverse" boolean key, when set to true, will only do so if the mob was not killed by a player.The following will smelt the cobblestone only if the mob was not killed by a player.
entity_properties
Provides an item/pool or executes a function if the target entity defined by the "entity" string key has the properties defined within the "properties" compound."entity" is restricted to: "this", "killer", and "killer_player". Target selectors or exact names do not work.
The IDs for properties will have the resource namespace default to "minecraft" (e.g. "minecraft:on_fire") when not specified. If using mods, the namespace will be whatever the mod has implemented. Note that you cannot create your own properties without modding.
"on_fire" (boolean)
The following will only provide a stick if the mob was killed while it was on fire.
The following will only provide cobblestone if the killing player was not on fire.
entity_scores
Provides an item/pool or executes a function if the target entity defined by the "entity" string key has the scores defined within the "scores" compound."entity" is restricted to: "this", "killer", and "killer_player". Target selectors or exact names do not work. Note that because of this, you may need to copy fake player scores to your desired killers/victims.
Within the "scores" compound will either be an integer or another compound, both of which uses the objective name for its own key name.
The following will only provide stone if the killing player had an "ObjA" score of exactly 1, as well as an "ObjB" score between values 1 and 25.
Duplicate functions & conditions
Multiple of the same functions and conditions can be applied, though not all will work or are useful.
Functions
set_count
Only the last "set_count" function specified will be used.
set_data
Only the last "set_data" function specified will be used.
set_damage
Only the last "set_damage" function specified will be used.
set_nbt
NBT data will merge. If duplicate tags are declared, the last "set_nbt" function specified will take precedence. For example, the following would provide an item that contains the lore from the first function, but the second function overwrites the display name from the first.
set_attributes
Attributes will be appended. Note that if "id" is duplicated, the game will not account for it. Do not use multiple of the same UUID.
enchant_randomly
Enchantments will be appended, rather than merged. Note that if the same enchantment is picked twice, they will not merge together and will instead be listed one after the other (and does not have to have the same level).
enchant_with_levels
Enchantments will be appended, rather than merged. Note that if the same enchantment is picked twice, they will not merge together and will instead be listed one after the other (and does not have to have the same level).
looting_enchant
Counts will be merged. For example, the following provides 42 stone with Looting I; 1 for initial, an extra 30 for the first function, and an extra 11 for the second function.
furnace_smelt
Each function will run one at a time, processing the item before moving on to the next. For example, in the following, the first function will turn the cactus into green dye, and the second function will fail because green dye has no smelting recipe.
Conditions
random_chance
Each condition runs one at a time (so long as no conditions fail), which can greatly change the rate of selection. For example, the following has a 50% chance for the first function, and if the first function succeeded, a 25% chance for the second function.
random_chance_with_looting
Each condition runs one at a time (so long as no conditions fail), which can greatly change the rate of selection. See Duplicate random_chance, which essentially functions the same way (albeit without a looting multiplier).
killed_by_player
Each condition runs one at a time (so long as no conditions fail). However, since the only option is whether or not the mob was killed by a player, it would be pointless to have multiple of these conditions at the same depth.
entity_properties
Each condition runs one at a time (so long as no conditions fail). It would be pointless to have multiple of these conditions if "entity" remained the same. However, it will function well for different targets. For example, the following would provide stone so long as both the mob and the killer were on fire.
entity_scores
Each condition runs one at a time (so long as no conditions fail). It would be pointless to have multiple of these conditions if "entity" remained the same. However, it will function well for different targets. For example, the following would provide stone so long as the killed mob had an "ObjA" score of 1, and the killer had an "ObjA" score between 1 and 2.
Usage
generic.luck, Luck, Unluck, Luck of the Sea
There are numerous features in-game that refer to "luck", such as the attribute, potion effect, and enchantment. Luck is specifically used with loot tables in order to modify potential loot chances. See "bonus_rolls" and "quality" for implementing into loot tables.
In default vanilla, the only thing that "luck" affects is fishing. It is a common misconception that "luck" does anything else. It does not affect mob or chest loot because the default loot tables for them do not implement the "bonus_rolls" or "quality" tags. Custom loot tables would need to be created to implement them. As well, the "Lure" enchantment no longer affects loot chances.
The "generic.luck" attribute is what controls the player's current luck value, with a base value of 0. The player can be given items that modify this value using all of the features of attribute modifiers. For example, the following provides the player with an iron ingot that, when held in the off-hand, increases the player's "generic.luck" attribute by 2.0:
The "Luck" and "Unluck" potion effects will apply modifiers to the player's "generic.luck" attribute, adding 1.0 per effect level of "Luck" or removing 1.0 per effect level of "Unluck". For example, the following gives the player "Luck" 10 and "Unluck" 4, which has a final resulting "generic.luck" value of 6:
The "Luck of the Sea" enchantment does not directly add an attribute modifier like the "Luck" or "Unluck" effects. Instead, the level of the enchantment is added onto the player's final "generic.luck" value (but only when obtaining fishing loot). As such, the enchantment supersedes other modifiers placed on the player. If the player had a modifier that reduced their attribute value by 100% (which occurs after any addition modifiers), their enchantment would still work because it is adding the enchantment level onto the final base of 0.0.
For example, the following provides the player with a "multiply total" attribute modifier, reducing their "generic.luck" by 100%, as well as a fishing rod with a high "Luck of the Sea" enchantment. The result is the player being guaranteed to fish treasure items because the enchantment value is added after obtaining the final attribute value (0.0 attribute + 85 enchantment = 85 "luck", the lowest value needed to guarantee treasure from fishing):
After all of these values are totalled up, the resulting value is what loot tables will use when modifying the "bonus_rolls" and "quality" tags.
For example, the following gives the player an iron helmet that, when worn, increases the player's "generic.luck" value by 100% (doubling their value), a "Luck" effect of 40 (which provides a modifier of +40.0), and a fishing rod with a "Luck of the Sea 5" enchantment. The result is a final attribute value of 80.0 (40 * 2), with 5 added on from the enchantment, finally resulting in 85 (guaranteeing treasure while fishing):
NBT data
"LootTable" (string)
The "LootTable" tag holds the filepath to the desired loot table. This tag's usage is restricted to the following: chests, hoppers, dispensers, droppers, minecart chests, minecart hoppers.
The following will create a chest that will populate with items from the "chests/simple_dungeon" loot table:
"LootTableSeed" (long)
Instead of being random every single time, inventory population can be deterministic based on seed. A default survival world will use this to always generate the same loot whenever a new world with the same seed is created. Value must not be 0, otherwise a new seed will be chosen randomly. This tag's usage is restricted to the following: chests, hoppers, dispensers, droppers, minecart chests, minecart hoppers.
"DeathLootTable" (string)
Mobs use this tag to determine what loot table is used when killed. Note that the "HandItems/ArmorItems" data for mobs is unrelated to loot tables and can drop separate items.
"DeathLootTableSeed" (long)
Same as "LootTableSeed", except for mobs.
Empty tables
An empty loot table may be declared by using "minecraft:empty". This will prevent any default loot from generating, provided that this table has not been overwritten with a custom table.
Conclusion
Custom table example
Since the "LootTable/DeathLootTable" tags states the path to the desired loot table within the target folder, rather than using hard-coded tables, you can add your own table to the mix.
The following is an example of a loot table named custom_table_a.json within the "entities" folder, inside the "customloot" namespace. It has a 1% chance of providing TNT, so long as it was on fire and killed by a player, otherwise it provides nothing.
And then using that in-game is the same as before, replacing the name with the name given to the JSON file. The following summons a creeper that, when killed, has a 1% chance to drop TNT when killed by a player and on fire.
Q&A
Q&A last updated: 16w02a.
Q: Is there an easy way to reload loot tables in-game if I've made changes?
A: Yes, hold F3 and press T to reload all resources.
Q: Do custom loot tables work on servers?
A: Yes, the file structure is exactly the same. A singleplayer world with custom loot tables can be copied to a multiplayer server with no need to change the tables.
Q: Are loot tables a part of resource packs?
A: No. Loot tables (and structures) are server-side, while resource packs are client-side. The difference is the client themselves being unable to change server resources. Loot tables and structures are not packaged with a resource pack.
Q: Where can I find the default loot tables?
A: You will need to extract "assets/loot_tables" from: /.minecraft/versions/15w49a.jar (or higher)
Q: There is no "loot_tables" folder within my world save, does it get created automatically?
A: It does not; the folder must be created manually.
Q: Why should I not use the "minecraft" namespace for new tables?
A: It is bad practice to use the default namespace for tables that are not default. There is also the risk of the filename you create being used in the future, resulting in unexpected overwriting of default resources. You should always put new loot tables into a separate namespace.
Q: Can I use target selectors for "entity"?
A: No, we are currently restricted to "this", "killer", and "killer_player".
Q: Can I use fake player scores for "entity_scores"?
A: No, we are currently restricted to "this", "killer", and "killer_player". You can use /scoreboard to duplicate the desired fake player score onto the killer or victim. You'll want to apply the score to as few targets as possible to save on scoreboard.dat bloating. For example, there will likely be fewer players compared to mobs in a CTM map, so you'll copy the fake player scores to the players ("killer_player") rather than to the killed mob ("this").
Q: Do I have to include "minecraft" before item IDs, condition IDs, and function IDs in loot tables?
A: No, the namespaces will default to "minecraft" when not defined.
Q: Accented characters/section symbol does not show up correctly in-game. What happened?
A: Your JSON file was not encoded in UTF-8. See Editing for info.
Q: What does "luck" do for default vanilla Minecraft?
A: The only thing luck affects in default vanilla is fishing loot tables. It is a common misconception that it affects mob drops or chest loot, but that is incorrect because default loot tables do not incorporate luck into anything except the fishing loot tables.
External links
- Generic JSON Validator
- Minecraft Wiki: Loot table
- Javascript loot table generator by MrPingouin1
Conclusion
If there is information that needs to be added, corrected, or clarified, please post!
7
Index
Generic info
1. Intro
2. JSON structure
3. Shared: item object
Customizing recipes
4. Type
5. Groups
6. Shaped crafting
7. Shapeless crafting
8. Results
Commands
9. Command: /recipe
Conclusion
10. Q&A
11. External links
12. Conclusion
Generic info
Intro
As of 1.12, recipes have become data-driven via external JSON files. This allows map makers, modders, and server owners to modify and add recipes to their liking.
Recipes can be shaped or shapeless, producing a specific item. As of 17w13b, only crafting table recipes are customizable. A new command, /recipe, has been introduced to supplement the files.
Recipes use the JSON format to store the recipe in external files.
JSON Structure
The following is a list of all possible keys for recipes.
Shared: item object
An item object contains a handful of data to either compare with an incoming object or to create an outgoing object. The context of the values may change based on the feature using the item object, and some may not be available depending on that context.
1. "item"
The required "item" string specifies a base item ID. The following either looks for or creates the "minecraft:redstone" item.
2. "data"
The optional "data" number specifies a metadata of the item. The following either looks for or creates a polished granite block.
When used in a key or ingredient, not specifying this tag or giving it a value of 32767 will indicate that the metadata value can be anything. When used in a result, it will set the item's metadata to the value specified, defaulting to 0 when not specified.
3. "count"
The optional "count" number specifies the number of items in the stack, defaulting to 1 when not specified. This cannot be used in a key or ingredient, only in a result. The following creates an item with a stacksize of 16.
Customizing recipes
Type
A recipe must have a type of crafting layout, specified in the "type" string. The value can either be "crafting_shaped" for shaped crafting or "crafting_shapeless" for shapeless crafting.
The following recipe makes use of shaped crafting.
While the following recipe makes use of shapeless crafting.
Groups
A recipe can optionally have a recipe group it belongs to within the crafting helper interface, specified by the "group" string. The value of this string can be anything. Any recipes that have the same group name specified will be shown together in the crafting helper. The intention is to keep similar items within the same category, such as all boats:
The following recipes belong to a group called "stuff" and will be grouped together in the crafting helper interface:
Shaped crafting
Shaped crafting involves placing items into the crafting window in a specific order. A pattern specifies the slots that items must appear in using arbitrary placeholder characters, while keys define what items those placeholders are looking for. Patterns and keys are both required with shaped recipes.
The following sets two placeholders in the pattern, being "#" and "^", while the keys define "#" as redstone dust and "^" as an iron block.
Image example of how it is used in the crafting window:
Patterns
A pattern must be specified via the "pattern" list. The list must contain between 1 and 3 strings, with each string representing a row in the crafting grid. Within each string there must be between 1 and 3 placeholder characters of your choosing, with each character representing a column. A space character indicates an empty slot in the crafting window, where no items are allowed to appear. The shape will automatically adapt to larger crafting grids, such that a 2x2 recipe will work in any corner of a 3x3 crafting grid.
For example, the following pattern uses only 1 row and all 3 columns, with an empty slot between the two items:
Which could look like any of the following in the crafting window:
All strings must contain the same number of characters. The following pattern is invalid due to the uneven rows.
The fix would be to specify an empty slot where the rows are uneven.
The fixed pattern could look like any of the following in the crafting window:
A pattern can have up to 9 unique placeholder characters. These characters can be anything (except the reserved space character), provided there is a corresponding key to go with them, although that doesn't mean that the items defined by those keys have to be unique. The following recipe makes use of 9 placeholders.
You can also use a single row and column to create a recipe where the item may be placed anywhere in the crafting grid, although you should use shapeless crafting instead as it is for unordered recipes.
Which could look like the following in the crafting window:
Keys
A set of keys must be specified via the "key" object. This object contains multiple item objects, whose key names must be equal to the unique characters specified in the pattern. The key name can only be 1 character long and cannot be the reserved space character.
The following pattern set uses "H" and "?" as the placeholders, while the key defines what items those placeholders will be. The "H" represents a lever, while the "?" represents a bone.
Which would look like the following in the crafting window:
If the "data" key is either not specified or has a value of 32767, the metadata value of the incoming item will be ignored. The following pattern set will accept stone, diamond swords, and wool of any kind.
Which could look like the following in the crafting window:
To work around that, you would specify the metadata value. The following pattern set ensures that the incoming diamond swords are brand new.
Shapeless crafting
Shapeless crafting involves placing items anywhere into the crafting window in no particular order. A list of ingredients specifies the items that make up the recipe, which is required for shapeless recipes.
The following recipe will allow placing a diamond and a nether star anywhere in the crafting grid to receive a stick in return.
Image example of how it is used in the crafting window:
Ingredients
A set of required items must be specified via the "ingredients" list. This list contains item objects; if the player does not provide all items in this list, the recipe will not work. There is no limit to the number of items, though be aware that in vanilla there can only be 9 total items to provide in a crafting table.
The following will only work if the player provides all 5 items, which also means they cannot use the standard inventory crafting grid (2x2) to craft the item as there is not enough room.
Which could look like the following in the crafting window, plus many more combinations:
You can use the same item multiple times, in which the player must provide all instances of that item.
Which could look like the following in the crafting window:
You can also require just a single item, and that item can be placed anywhere in the crafting window.
Which could look like the following in the crafting window:
If the "data" key is either not specified or has a value of 32767, the metadata value of the incoming item will be ignored. The following will accept stone, diamond swords, and wool of any kind.
Which could look like the following in the crafting window:
To work around that, you would specify the metadata value. The following ensures that the incoming diamond swords are brand new.
Results
A recipe must have the resulting item that is crafted, specified in the "result" item object. Unlike in "key" and "ingredients" item objects, the "data" key will default to 0 when not specified.
For example, if the following shaped recipe is fulfilled, the player will receive a new anvil.
Unlike in "key" and "ingredients" item objects, the "count" key may be specified in "result" to provide the player with multiple items. The following shapeless recipe will create 4 sticks when the recipe is fulfilled.
Commands
Command: /recipe
Coming soon...
Conclusion
Q&A
Q: Can custom recipes be used in 17w13b?
A: Not quite. The JAR must be modified directly, but in the future we will be able to modify recipes on a per-world basis, same as loot tables and advancements. This thread was created to prepare for that, so be aware that information in this thread is highly likely to become outdated once custom crafting becomes available without modding. Once it's possible, I will add instructions for file placement.
External links
- Generic JSON Validator
Conclusion
If there is information that needs to be added, corrected, or clarified, please post!
1
Yes, though quite a bit differently. CommandStats as a whole has been overhauled and no longer directly stores data on the entity/block. Instead, /execute stores the result of a command directly to a target's score. That way the only prerequisite is the objective itself, no /stats or other /scoreboard commands.
Prerequisites:
The objective to track the number of items in:
Triggering:
The following command will set each player's own score based on the number of the specified items that they have in their inventory:
And to target players afterwards:
The subargument that replaces CommandStats is "store". All of the old varied CommandStats types (AffectedItems, AffectedEntities, AffectedBlocks, QueryResult) have been merged into one "result" type (which is what's used in the command above). The original "SuccessCount" type is now just "success" (in place of "result" int he command). From there, you can either choose to store the resulting value from the nested command into a "score", or you could store it directly into NBT data for a "block" or "entity".
For example, the following sets a creeper's health based on the number of cobblestone in the player's inventory (provided the amount does not exceed the creeper's max health):
1
It's not. What's happening is when the internal list of savegame entities is instantiated, some of them come with "spawn egg colors" to indicate that they have a spawn egg. Anything that does not have those egg colors will not get a corresponding egg, thus preventing the custom egg from working. On top of that, statistics rely on the same list of entities that are available for spawn eggs, hence why there's no "stat.killEntity" for iron golems, ender dragons, etc. (though those can be worked around using the "player_killed_entity" advancement trigger).