Czech, Thai, and Turkish language wikis are now available. Please help with translating!


From Minecraft Wiki
Jump to: navigation, search
Planned release date


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

Planned additions


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


  • A command UI when typing commands in the chat.[7][8][9][10]
    • Different components of commands will be displayed in different colors.[11]
    • Errors will be displayed in red without having to run the command.[8][12]
  • An nbt argument in target selectors.[9][10]
  • New gamerule: structureSaveDestination.[13]

Planned changes


Block metadata
  • Numeric block metadata completely phased out in favor of block states.[14][15]
  • Customizable crafting recipes.[1]
    • Originally planned to be added in 1.12.[16]
Block ID
  • The upper limit of the block ID disappears[17][18]
  • Functions will be completely parsed and cached on load.[6]
    • This means if a command is incorrect for any reason, the player will know about it on load.
  • Structures stored in the world file will need a namespace.[19][6]
    • The default namespace is always minecraft, which will likely cause conflicts in future updates.[20][6]
  • Structures are saved to (world)/generated/structures/(namespace)/(file).nbt.[6]
The "flattening"
  • The damage value parameter in /give, /clear and /replaceitem will be removed.[21]
    • Damage values will be moved to a new Damage tag, used only by damageable items in their tag tag.
      • For instance, /give @p diamond_sword 1 1 will become /give @p diamond_sword{Damage:1} 1
  • Blocks currently separated by variant, type, and color block states will be split into their own ids. (for example wool color=red will become red_wool.)[21]
  • Removing the block entity for flower pots, mob heads (except player heads) and note blocks.[21]
World Files[20][6]
  • The following files will need to be moved into a data pack:
    • (world)/data/advancements/(namespace)/(file) will need to be moved to data/(namespace)/advancements/(file)
    • (world)/data/functions/(namespace)/(file) will need to be moved to data/(namespace)/functions/(file)
    • (world)/data/loot_tables/(namespace)/(file) will need to be moved to data/(namespace)/loot_tables/(file)
    • (world)/structures/(file) will need to be moved to data/(namespace)/structures/(file)
  • Functions, advancements, structures and loot tables will be only allowed to be lowercase filenames.


  • Commands and functions will be much faster and more efficient.
    • Applies to functions as well.[22]
  • Most commands are now more case-sensitive. Lowercase is preferable wherever possible.
    • For example, this is no longer allowed: /scoreboard ObJeCtIvEs ...
  • The output signal of a command block used to be it's "success count", but now it's "result".
Specific Commands[6]
  • The syntax of /clear has changed.
    • /clear <target> [<item>] [<data>] [<count>] [<nbt>] will become /clear <target> [<item>] [<count>]
    • See the item argument type for more details.
  • The syntax of /clone has been changed.
    • /clone <x1 y1 z1> <x2 y2 z2> <xt yt zt> filtered [force|move|normal] [<block>] [<data>] will become /clone <x1 y1 z1> <x2 y2 z2> <xt yt zt> filtered [<block>] [force|move|normal]
    • /clone <x1 y1 z1> <x2 y2 z2> <xt yt zt> [replace|masked] [force|move|normal] [<block>] [<data>] will become /clone <x1 y1 z1> <x2 y2 z2> <xt yt zt> [replace|masked] [force|move|normal]
/defaultgamemode and /gamemode
  • The syntax of /effect has been split off, to avoid ambiguity.
    • /effect <entity> <effect> will become /effect give <entity> <effect>
    • /effect <entity> clear will become /effect clear <entity> [<effect>]
  • The syntax of /execute has been split off.
    • Modifier sub-commands can change how the command is ran:
      • /execute as <entity> executes a command using the entity <entity> (but doesn't change position).
      • /execute at <entity> executes a command using the position of <entity> (but doesn't change entity).
      • /execute offset <x y z> executes a command using the position of <x y z>.
    • Conditional sub-commands can let you prevent the command from running at all:
      • /execute (if|unless) block <x y z> <block> executes a command if (or unless) <x y z> matches <block>.
      • /execute (if|unless) blocks <begin> <end> <destination> (all|masked) executes a command if (or unless) the region between <start> and <end> matches <destination>.
      • /execute (if|unless) entity <entity> executes a command if (or unless) <entity> exists (returns 1 or more entities).
    • As replacement for /stats, a new sub-command store lets you store the result of a command somewhere:
      • /execute store (result|success) <name> <objective>
      • result is the result of a command, which replaces these old stats: AffectedBlocks, AffectedEntities, AffectedItems, QueryResult.
      • success is how many times the command was successful. This is usually 0 or 1, but if the command split up (for example as @a) then it may be more than 1. This replaces SuccessCount.
      • The value is stored into the scoreboard under <name> and <objective>.
      • The objective must exist, but unlike with /stats you don't need to set an initial value for <name>.
      • The value will be stored when the full command has finished executing.
      • If a command isn't successful (success is 0), result will always be set to 0.
      • 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, then lets you write the actual command to be executed.
      • /execute as somebody at somebody then say hi
    • Example of old commands:
      • /execute @e ~ ~ ~ detect ~ ~ ~ stone 0 say Stone! will become /execute as @e at @s if block ~ ~ ~ stone then say Stone!
      • /execute @e ~ ~ ~ detect ~ ~ ~ grass summon pig will become /execute at @e if block ~ ~ ~ grass then summon pig
      • /execute @e ~ ~ ~ say Hello! will become /execute as @e then say Hello!
  • The syntax of /fill has been changed.
    • /fill <x y z> <xt yt zt> <block> <data> replace [<replaceBlock>] [<replaceData>] will become /fill <x y z> <xt yt zt> <block> replace [<filter>]
    • /fill <x y z> <xt yt zt> <block> [<data>] [destroy|hollow|keep|outline|replace] [<nbt>] will become /fill <x y z> <xt yt zt> <block> [destroy|hollow|keep|outline|replace]
  • /function no longer accepts [if|unless] <entity> arguments.
  • /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 /gamerule are now type checked (giving a string if it wants an int is a very obvious error).
  • The syntax of /give has changed.
    • /give <players> <item> [<count>] [<data>] [<nbt>] will become /give <players> <item> [<count>]
    • See the item argument type for more details.
  • The syntax of /replaceitem has changed.
    • /replaceitem block <pos> <slot> <item> [<count>] [<data>] [<nbt>] will become /replaceitem block <pos> <slot> <item> [<count>]
    • /replaceitem entity <target> <slot> <item> [<count>] [<data>] [<nbt>] will become /replaceitem entity <target> <slot> <item> [<count>]

See the item argument type for more details.

  • /scoreboard had [<dataTag>] removed from its commands, as they're no longer needed.
  • The syntax of /setblock has changed.
    • /setblock <pos> <block> [<data>] [<mode>] [<nbt>] will become /setblock <pos> <block> [<mode>]
    • See the block argument type for more details.
  • Removed. Now part of /execute.
  • The new /execute one isn't a direct replacement, the behavior has changed:
    • It's now per-command, instead of per-entity or per-block.
    • There's only result and success, which covers all the old stat types.
/testfor, /testforblock and /testforblocks
  • Removed. It was always used to stop the rain, then make you frustrated in a minute when it's raining again.
  • Use /weather.
/tp and /teleport
  • /tp is now an alias of /teleport (much like /w, /msg and /tell).
  • Coordinates are now relative to the executor, as with all other commands.
  • The syntax of /tp remains, but with the behavior of /teleport.
Argument Types[6]
Target selectors
  • More error handling has been introduced.
    • Things like limit=0, level=-10, gamemode=purple are not allowed.
  • There's no longer a "min" and "max" separate values, we instead support ranges.
    • level=10 is level 10
    • level=10..12 is level 10, 11 or 12
    • level=5.. is anything level 5 or above
    • level=..15 is anything level 15 or below
  • The arcane shorthand names have been renamed.
    • m -> gamemode
    • l or lm -> level
    • r or rm -> distance
    • rx or rxm -> x_rotation
    • ry or rym -> y_rotation
    • c -> limit
  • x, y, z, distance, x_rotation, y_rotation are now doubles and allow values like 12.34
    • x and z are no longer center-corrected.
      • This means x=0 no longer equates to x=0.5.
  • gamemode (previously m) no longer allows numerical or shorthand IDs.
  • limit (was c) No longer allows negative values.
    • Use sort=furthest instead.
  • The name argument now supports spaces (as long as it's quoted).[23]
  • Multiple of the same argument in target selectors is now possible.[24]
    • tag=foo,tag=bar,tag=!baz matches someone with foo, bar and not baz.
    • type=!cow,type=!chicken matches something that isn't a cow and isn't a chicken.
    • type=cow,type=chicken isn't allowed, because something cannot both be a cow and chicken.
  • You can specify the sorting.
    • sort=nearest is default and current behaviour (except for @r).
    • sort=furthest is the reverse of that (previously you'd use c=-5 for this).
    • sort=random for random sorting (default for @r).
    • sort=arbitrary is a new option to not sort the result, which is useful if you're optimising commands and don't need sorting.
  • Wherever a <block>, optionally [<data>] and optionally [<nbt>] was required, it's now a single <block> argument that looks like this:
    • stone
    • minecraft:redstone_wire[power=15,north=up,south=side]
    • minecraft:jukebox{RecordItem:{...}}
    • minecraft:furnace[facing=north]{BurnTime:200}
  • ID is required (though just as before, if namespace isn't set it defaults to minecraft:).
  • States are inside [], comma-separated and must be properties/values supported by the blocks. They are optional.
    • minecraft:stone[doesntexist=purpleberry] is a syntax error, because stone doesn't have doesntexist.
    • minecraft:redstone_wire[power=tuesday] is a syntax error, because redstone_wire's power 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 redstone_wire[power=15], it only checks power but ignores other states such as north.
  • 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 redstone_wire[power=15], it will set power to 15 but north will be a default value (in this case, set to none).
  • There is no such thing as block data value in 1.13. It's either a different blocks, or a state.[21]
  • Wherever an <item>, optionally [<data>] and optionally [<nbt>] was required, it's now a single <item> argument that looks like this:
    • stone
    • minecraft:stick{display:{Name:"Stick of Untruths"}}
  • ID is required (though just as before, if namespace isn't set it defaults to minecraft:).
  • 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.[21]
    • Damage, where applicable, is being moved into nbt.
    • Any other information is either a separate item or a property in nbt.

Unconfirmed features

  • The ability to change biome dependent colors (such as foliage, water, and the sky) without needing mods.[25]
  • The new ^ notation to use coordinates based on the rotations of entities.[26][27]
  • The textures of some blocks, items, mobs, effects and GUIs will change.[28][29][30]
    • New textures will be closely based on the originals, "with improved techniques and colors."[31][32]
    • Recently-added blocks (such as glazed terracotta) will be not changed[33]
    • Paintings will not be redone, although one might be added.[34]
    • Will first be released as a resource pack for feedback purposes.[35][36]
  • Ability for the recipe book to show smelting recipes.[37]
    • Customizable furnace recipe files. [38]
  • Suggesting tab-completions will be added at command input.[39]
  • Recipe book design might be changed.[40][41]



  1. a b “It'll probably be in 1.13 at this point, I'm afraid :( It'll be a more bugfixy and technical update, so it will get more love then.”@Dinnerbone, April 24, 2017
  2. “Maaaybe! The focus is to just get the game running better, and to make it easier for us to add survival changes in (for example) 1.14.”@Dinnerbone, July 10, 2017
  3. “Like resource packs but for servers or worlds. They have stuff like loot tables or advancements, instead of textures and clientside stuff.”@Dinnerbone, June 14, 2017
  4. “Mapmakers! Custom data (for example advancements or loot tables) will be moved to data packs in 1.13. The structure will probably like this!”@Dinnerbone, June 20, 2017
  5. “You can zip that and share it around just like resource packs. They'll be placed inside a world (or server) itself. Multiple can be loaded!”@Dinnerbone, June 20, 2017
  6. a b c d e f g h i j “A completely incomplete, super early preview of everything that will definitely break your maps in 1.13” – /u/Dinnerbone, July 4, 2017
  8. a b “Minecraft Java 1.13 will be more of a technical/backend update. With that in mind, here's a little something from what I'm working on.”@Dinnerbone, June 30, 2017
  9. a b “”@simsor, July 6, 2017
  10. a b "Dinnerbone drops a new feature hint on Twitter that leads to this image" – Imgur
  11. a b c “The UI is nowhere near complete because it's not my priority yet, but I got this working pretty easy:”@Dinnerbone, July 27, 2017
  12. “Quick gif of the super-unfinished-work-in-progress-completely-not-final-and-really-really-experimental highlighting:”@Dinnerbone, July 27, 2017
  14. “For trapdoors however we lacked the space to store the (powered) state .. so we didn't add it yet ..... but now I'm working on removing these limitations” – /u/_Grum, March 09, 2017
  15. “(In response to the question if data values for blocks are going away): Yep.”@Dinnerbone, August 07, 2017
  16. “Sadly I can't promise that will be in 1.12 :(”@Dinnerbone, April 24, 2017
  17. “The block id update has been scheduled for 1.13 as it's still being worked on.” – /u/Jeb_, April 12, 2017
  18. “That is ok, but that's not possible until we remove the block ID limit, which will also be happening in 1.13.”@Dinnerbone, July 28, 2017
  19. “Mapmakers: in 1.13, structures will properly use resource locations/namespaces. That means you should use yourname:foo instead of just foo.”@Dinnerbone, June 21, 2017
  20. a b
  21. a b c d e MC-105922 - block states can't be used in /give, /clear and /replaceitem, but can be used in /setblock, /fill, /execute detect, and /testforblock
  22. “This also applies to functions. Want to know if a map works in a future version? Just open it! You'll be told which commands don't work &why”@Dinnerbone, June 30, 2017
  23.; /entitydata @e[name="Spooky Scary Skeleton"] {spookiness:100} is totally a valid command too.
  24. “[tag=foo,tag=bar,tag=!baz]; will be allowed”@Dinnerbone, July 6, 2017
  25. “I have a branch with a prototype for this somewhere, might have time to work on it for 1.13 :)” – /u/_Grum, April 20, 2017
  26. “That's a really neat idea! ` is a bad symbol to use though, as if you were to type it into most chats it becomes a code block (I often write commands in blocks of code and that'd be messy. Maybe ^ instead.” – /u/Dinnerbone, May 2, 2017
  27. “/tp @s ^ ^ ^1.2”@slicedlime, June 21, 2017
  28. a b “Happy to have @JasperBoerstra on the team fixing up the pixel art in Minecraft! A small before/after preview:”@jeb_, July 18, 2017
  29. “Obviously this will be a process, but I think it's important to try it out before kneejerking because it's different”@jeb_, July 18, 2017
  30. “Yes, where it's necessary. Items, mobs, effects, GUI”@jeb_, July 18, 2017
  31. “I'm making the blocks closely to the original, only with improved techniques and colors. The majority wont change drastically like dmond [sic]”@JasperBoerstra, July 19, 2017
  32. “The colors will not change that much. All the made textures are based on the original's colors.”@JasperBoerstra, July 19, 2017
  33. “Except for some new blocks like terracotta. They already look great!”@JasperBoerstra, July 19, 2017
  34. “Nah, not going to touch them, Might make an extra one for fun if I have the time.”@JasperBoerstra, July 27, 2017
  35. “We will release all the texture changes as a resource pack first to get more balanced feedback.” – /u/jeb_, July 18, 2017
  36. “The texture pack would be an interim feedback thing. Once we're done, the textures will be "vanilla" on all editions.” – /u/jeb_, July 18, 2017
  37. a b “Currently working on:”@MiaLem_n, August 3, 2017
  38. “furnace recipes but yeah that is the plan I have no time frame though for when this will get in.”@MiaLem_n, August 3, 2017
  39. “More experimenting with the command UI. Suggesting tab-completions where possible?”@Dinnerbone, August 3, 2017
  40. a b “Trying out a new design for the recipe book button. What do you think?”@MiaLem_n, August 7, 2017
  41. “Another idea for recipe button, animated. Comments?”@MiaLem_n, August 7, 2017
  42. “Hey mapmakers. It's ab́out time I show you thís thingý. Ónly just finished it. Śeriously though. Ǵreat stuff. Ŕight? <3”@Dinnerbone, July 6, 2017
  44. “”@jeb_, July 18, 2017
  45. “Here's another edit by @JasperBoerstra”@jeb_, July 18, 2017
  46. a b “Edited obsidian, new diamond block texture. cc @JasperBoerstra”@jeb_, July 19, 2017
  47. “What do you think about the new jungle door design? cc @JasperBoerstra”@jeb_, July 19, 2017
  48. “I agree the Birch was to blurry and yellow! What do you think about this one?”@JasperBoerstra, July 19, 2017
  49. “Improved the diamond a bit! What do you think?”@JasperBoerstra, July 19, 2017
  50. “Good Friday! Here's another retexture by @JasperBoerstra”@jeb_, July 21, 2017
  51. “As promised :)”@JasperBoerstra, July 21, 2017
  52. “Hey, what do you think about the new chorus flower/plant? This is WIP, not final! but I'd like to hear your feedback.”@JasperBoerstra, August 2, 2017
  53. “Hey, what do you think of these? :)”@JasperBoerstra, August 10, 2017