Jump to content

Our website is made possible by displaying online advertisements to our visitors.
Please consider supporting us by disabling your ad blocker.
Sign in to follow this  

Info on 1.13

Recommended Posts

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



Planned additions


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 .zip files or folders with a pack.mcmeta in the root. See: Tutorials/Creating a resource pack#pack.mcmeta
  • 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.
    • Different components of commands will be displayed in different colors.
    • Errors will be displayed in red without having to run the command.
  • An nbt argument in target selectors.
  • New gamerule: structureSaveDestination.

Planned changes


Block metadata
  • Numeric block metadata completely phased out in favor of block states.
  • Customizable crafting recipes.
    • Originally planned to be added in 1.12.
Block ID
  • The upper limit of the block ID disappears
  • 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 stored in the world file will need a namespace.
    • The default namespace is always minecraft, which will likely cause conflicts in future updates.
  • Structures are saved to (world)/generated/structures/(namespace)/(file).nbt.
The "flattening"
  • The damage value parameter in /give, /clear and /replaceitem will be removed.
    • 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.)
  • 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:
    • (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)
  • Files and folders of functions, advancements, structures and loot tables have to be lowercase.


  • 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: /scoreboard ObJeCtIvEs ...
  • The output signal of a command block used to be its "success count", but now will be its "result".
Specific Commands
  • 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> <chained command> executes a command using the entity <entity> (but doesn't change position).
      • /execute at <entity> <chained command> executes a command using the position of <entity> (but doesn't change entity).
      • /execute offset <x y z> <chained command> 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> <chained command> executes a command if (or unless) <x y z> matches <block>.
      • /execute (if|unless) blocks <begin> <end> <destination> (all|masked) <chained command> executes a command if (or unless) the region between <start> and <end> matches <destination>.
      • /execute (if|unless) entity <entity> <chained command> 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> <chained command>
      • 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.
    • This has been moved into /execute.
    • /function foo if @e will become /execute if entity @e then function foo
  • /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.
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).
  • Multiple of the same argument in target selectors is now possible.
    • 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.
  • 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.
    • Damage, where applicable, is being moved into nbt.
    • Any other information is either a separate item or a property in nbt.

Unconfirmed features

These features are not confirmed for 1.13, but they were mentioned or showcased by developers during development. 
  • 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: /modifyitem

View full article

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.


Important Information

This website uses cookies to provide the best experience possible. Privacy Policy & Terms of Use