Java Edition 1.13

1.13 is an upcoming major update with no set release date. It will focus mainly on bug fixes, technical features, and optimisation.

General

 * Data packs
 * Like resource packs, but for loot tables, advancements, functions, etc.
 * Can be changed from world to server side.
 * Used by placing them into the world or server file, and it is also possible to use multiple data packs, or none at all.
 * Data packs are  files or folders with a   in the root. See: Tutorials/Creating a resource pack#pack.mcmeta
 * Structures will load from  before checking data packs.
 * However, this directory should not be used to distribute structures. Instead, move these files into data packs.

Commands

 * Commands
 * A command UI when typing commands in the chat.
 * Different components of commands will be displayed in different colors.
 * Errors will be displayed in red without having to run the command.
 * An  argument in target selectors.
 * New gamerule:.

General

 * Block metadata
 * Numeric block metadata completely phased out in favor of block states.


 * Crafting
 * Customizable crafting recipes.
 * Originally planned to be added in 1.12.


 * Block ID
 * The upper limit of the block ID disappears


 * Functions
 * Functions will be completely parsed and cached on load.
 * This means if a command is incorrect for any reason, the player will know about it on load.


 * Structures
 * Structures stored in the world file will need a namespace.
 * The default namespace is always, which will likely cause conflicts in future updates.
 * Structures are saved to.


 * The "flattening"
 * The damage value parameter in, and  will be removed.
 * Damage values will be moved to a new  tag, used only by damageable items in their   tag.
 * For instance, will become
 * Blocks currently separated by variant, type, and color block states will be split into their own ids. (for example  will become  .)
 * Removing the block entity for flower pots, mob heads (except player heads) and note blocks.


 * World Files
 * The following files will need to be moved into a data pack:
 * will need to be moved to
 * will need to be moved to
 * will need to be moved to
 * will need to be moved to
 * Files and folders of functions, advancements, structures and loot tables have to be lowercase.

Commands

 * General
 * Commands and functions will be much faster and more efficient.
 * Functions will be completely parsed & cached on load.
 * Most commands are now more case-sensitive. Lowercase is preferable wherever possible.
 * For example, this is no longer allowed:
 * The output signal of a command block used to be its "success count", but now will be its "result".


 * Specific Commands


 * The syntax of has changed.
 * {{cmd|clear [ ] [ using the entity   (but doesn't change position).
 * {{cmd|execute at }} executes a   using the position of   (but doesn't change entity).
 * {{cmd|execute offset }} executes a command using the position of.
 * Conditional sub-commands can let you prevent the command from running at all:
 * {{cmd|execute (if{{!}}unless) block  }} executes a   if (or unless)   matches.
 * {{cmd|execute (if{{!}}unless) blocks  (all{{!}}masked) }} executes a   if (or unless) the region between   and   matches.
 * {{cmd|execute (if{{!}}unless) entity }} executes a   if (or unless)   exists (returns 1 or more entities).
 * As replacement for {{cmd|stats}}, a new sub-command  lets you store the result of a command somewhere:
 * {{cmd|execute store (result{{!}}success)  }}
 * is the result of a command, which replaces these old stats:,  ,  ,.
 * is how many times the command was successful. This is usually  or , but if the command split up (for example  ) then it may be more than  . This replaces.
 * The value is stored into the scoreboard under  and.
 * The  must exist, but unlike with {{cmd|stats}} you don't need to set an initial value for.
 * The value will be stored when the full command has finished executing.
 * If a command isn't successful ( is  ),   will always be set to.
 * It will be made clear what the expected result of each command is.
 * You can chain all sub-commands together.
 * After every sub-command you need to write another sub-command.
 * When you're done with chaining sub-commands,  lets you write the actual command to be executed.
 * {{cmd|execute as somebody at somebody then say hi}}
 * Example of old commands:
 * {{cmd|execute @e ~ ~ ~ detect ~ ~ ~ stone 0 say Stone!}} will become {{cmd|execute as @e at @s if block ~ ~ ~ stone then say Stone!}}
 * {{cmd|execute @e ~ ~ ~ detect ~ ~ ~ grass summon pig}} will become {{cmd|execute at @e if block ~ ~ ~ grass then summon pig}}
 * {{cmd|execute @e ~ ~ ~ say Hello!}} will become {{cmd|execute as @e then say Hello!}}
 * {{cmd|execute @e ~ ~ ~ say Hello!}} will become {{cmd|execute as @e then say Hello!}}


 * {{cmd|experience}}
 * {{cmd|xp}} is now an alias for {{cmd|experience}}.
 * Split up into 3 different subcommands:
 * {{cmd|experience add [points{{!}}levels]}}
 * Adds  of either points or levels to the target   of either points or levels on the target   (defaults to points).
 * You cannot set more points than their current level allows.
 * When changing levels, the points will stay at the same percentage as the previous level.
 * {{cmd|experience query (points{{!}}levels)}}
 * Returns either the number of points or levels on the given.


 * {{cmd|fill}}
 * The syntax of {{cmd|fill}} has been changed.
 * {{cmd|fill    arguments.
 * This has been moved into {{cmd|execute}}.
 * {{cmd|function foo if @e}} will become {{cmd|execute if entity @e then function foo}}


 * {{cmd|gamerule}}
 * {{cmd|gamerule}} no longer accepts unknown rules ("custom gamerules").
 * You can use functions or scoreboards as replacements, with no loss of functionality.
 * Existing custom gamerules will just not be accessible. Only built-in rules will be available.
 * Values to {{cmd|gamerule}} are now type checked (giving a string if it wants an int is a very obvious error).


 * {{cmd|give}}
 * The syntax of {{cmd|give}} has changed.
 * {{cmd|give [ ] [  removed from its commands, as they're no longer needed.


 * {{cmd|setblock}}
 * The syntax of {{cmd|setblock}} has changed.
 * {{cmd|setblock [  and , which covers all the old stat types.


 * {{cmd|testfor}}, {{cmd|testforblock}} and {{cmd|testforblocks}}
 * Removed. Now part of {{cmd|execute}}.


 * {{cmd|toggledownfall}}
 * Removed. It was always used to stop the rain, then make you frustrated in a minute when it's raining again.
 * Use {{cmd|weather}}.


 * {{cmd|tp}} and {{cmd|teleport}}
 * {{cmd|tp}} is now an alias of {{cmd|teleport}} (much like {{cmd|w}}, {{cmd|msg}} and {{cmd|tell}}).
 * Coordinates are now relative to the executor, as with all other commands.
 * The syntax of {{cmd|tp}} remains, but with the behavior of {{cmd|teleport}}.


 * Argument Types


 * Target selectors
 * More error handling has been introduced.
 * Things like,  ,   are not allowed.
 * There's no longer a "min" and "max" separate values, we instead support ranges.
 * is level 10
 * is level 10, 11 or 12
 * is anything level 5 or above
 * is anything level 15 or below
 * The arcane shorthand names have been renamed.
 * or  ->
 * or  ->
 * or  ->
 * or  ->
 * ,,  ,  ,  ,   are now doubles and allow values like
 * and  are no longer center-corrected.
 * This means  no longer equates to.
 * (previously ) no longer allows numerical or shorthand IDs.
 * (was ) No longer allows negative values.
 * Use  instead.
 * The  argument now supports spaces (as long as it's quoted).
 * Multiple of the same argument in target selectors is now possible.
 * matches someone with,   and not.
 * matches something that isn't a cow and isn't a chicken.
 * isn't allowed, because something cannot both be a cow and chicken.
 * You can specify the sorting.
 * is default and current behaviour (except for ).
 * is the reverse of that (previously you'd use  for this).
 * for random sorting (default for ).
 * is a new option to not sort the result, which is useful if you're optimising commands and don't need sorting.
 * for random sorting (default for ).
 * is a new option to not sort the result, which is useful if you're optimising commands and don't need sorting.


 * Blocks
 * Wherever a, optionally   and optionally   was required, it's now a single   argument that looks like this:
 * ID is required (though just as before, if namespace isn't set it defaults to ).
 * States are inside, comma-separated and must be properties/values supported by the blocks. They are optional.
 * is a syntax error, because  doesn't have.
 * is a syntax error, because 's   is a number between 0 and 15.
 * NBT tag is inside {}, and works just like you'd expect. It's optional.
 * In the context of "conditions"/testing for blocks, only the states you provided will be tested.
 * If you test, it only checks power but ignores other states such as.
 * In the context of setting blocks, any states you provided will be set but anything missed out will default depending on the block.
 * If you set, it will set   to 15 but   will be a default value (in this case, set to  ).
 * There is no such thing as block data value in 1.13. It's either a different blocks, or a state.
 * If you test, it only checks power but ignores other states such as.
 * In the context of setting blocks, any states you provided will be set but anything missed out will default depending on the block.
 * If you set, it will set   to 15 but   will be a default value (in this case, set to  ).
 * There is no such thing as block data value in 1.13. It's either a different blocks, or a state.


 * Items
 * Wherever an, optionally   and optionally   was required, it's now a single   argument that looks like this:
 * ID is required (though just as before, if namespace isn't set it defaults to ).
 * NBT tag is inside {}, and works just like you'd expect. It's optional.
 * There is no such thing as item data value or item damage value in 1.13.
 * Damage, where applicable, is being moved into nbt.
 * Any other information is either a separate item or a property in nbt.
 * Damage, where applicable, is being moved into nbt.
 * Any other information is either a separate item or a property in nbt.

Mobs

 * Horse
 * The model will be changed
 * It will look more like Minecraft
 * The current horse is a lot more detailed than the other animals
 * It will be simplified and a bit more blocky.

Unconfirmed features

 * The ability to change biome dependent colors (such as foliage, water, and the sky) without needing mods.
 * The new  notation to use coordinates based on the rotations of entities.
 * The textures of some blocks, items, mobs, effects and GUIs will change.
 * New textures will be closely based on the originals, "with improved techniques and colors."
 * Recently-added blocks (such as glazed terracotta) will be not changed
 * Paintings will not be redone, although one might be added.
 * Will first be released as a resource pack for feedback purposes.
 * Ability for the recipe book to show smelting recipes.
 * Customizable furnace recipe files.
 * Suggesting tab-completions will be added at command input.
 * Recipe book design might be changed.
 * A new command: