We have begun migration of most wikis to our new host, Amazon Web Services. All but the top 100 wikis are in read-only mode until the migration is complete. Estimated completion: End of Week.

1.13

From Minecraft Wiki
Jump to: navigation, search
1.13
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.[1][2]

Planned additions

General

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.

Commands

Commands
  • 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

General

Block metadata
  • Numeric block metadata completely phased out in favor of block states.[14][15]
Crafting
  • 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
  • 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
  • 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.[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.[20]
    • 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.)[20]
  • Removing the block entity for flower pots, mob heads (except player heads) and note blocks.[20]
World Files[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)
  • Files and folders of functions, advancements, structures and loot tables have to be lowercase.

Commands

General[6]
  • 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".
  • New command parsing library known as brigadier[21][22]
Specific Commands[6]
/clear
  • 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.
/clone
  • 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
/difficulty
/effect
  • 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>]
/execute
  • 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 0 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!
/experience
  • /xp is now an alias for /experience.
  • Split up into 3 different subcommands:
    • /experience add <players> <amount> [points|levels]
      • Adds <amount> of either points or levels to the target <players> (defaults to points).
      • Adding points can cause players to level up, as usual.
      • Negative numbers are supported, to subtract points instead.
      • Subtracting points can cause players to level down.
    • /experience set <players> <amount> [points|levels]
      • Sets <amount> of either points or levels on the target <players> (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.
    • /experience query <player> (points|levels)
      • Returns either the number of points or levels on the given <player>.
/fill
  • 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
  • /function no longer accepts [if|unless] <entity> arguments.
/gamerule
  • /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).
/give
  • 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.
/replaceitem
  • 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
  • /scoreboard had [<dataTag>] removed from its commands, as they're no longer needed.
/setblock
  • 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.
/stats
  • 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
/toggledownfall
  • 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.
Blocks
  • 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.[20]
Items
  • 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.[20]
    • 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 to be more consistent with other mobs[25]

Unconfirmed features

Gallery

References

  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. “Remember that 1.13 is a technical update to make things crash less, run faster, & easier for us to add/change stuff later. Like new blocks!”@Dinnerbone, October 16, 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
  7. https://bugs.mojang.com/browse/MC-80856?focusedCommentId=392861&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-392861
  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 “t.co/lI178rmP6G”@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
  13. https://gist.github.com/Dinnerbone/943fbcd763c19be188ed6b72a12d7e65#file-minecraft_commands-txt-L139
  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 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
  21. Comment on “A completely incomplete, super early preview of everything that will definitely break your maps in 1.13” – /u/Dinnerbone, July 4, 2017
  22. #mcdevs IRC chat log, between 2017-07-31 22:47:04 and 2017-07-31 23:49:05
  23. https://www.reddit.com/user/Dinnerbone/comments/6l6e3d/a_completely_incomplete_super_early_preview_of/djtiws0/; /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. https://minecraft.net/en-us/article/meet-horse
  26. “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
  27. “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
  28. “/tp @s ^ ^ ^1.2”@slicedlime, June 21, 2017
  29. a b “Currently working on:”@MiaLem_n, August 3, 2017
  30. “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
  31. “More experimenting with the command UI. Suggesting tab-completions where possible?”@Dinnerbone, August 3, 2017
  32. a b “Trying out a new design for the recipe book button. What do you think?”@MiaLem_n, August 7, 2017
  33. “Another idea for recipe button, animated. Comments?”@MiaLem_n, August 7, 2017
  34. “Possible new 1.13 command: /modifyitem” – /u/Dinnerbone, August 28, 2017
  35. “Whilst I'm changing all the commands, I kinda want to change save-all, save-on, save-off into: '/save', '/save enable', '/save disable'”@Dinnerbone, October 5, 2017
  36. “(The same goes for ban/pardon/banip/unbanip)”@Dinnerbone, October 5, 2017
  37. a b “Trying to make the /particle command easier to use. A little easier. Kinda. Slightly. (The "gold_block" bit is new)”@Dinnerbone, October 10, 2017
  38. “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
  39. https://imgur.com/biyOSGR
  40. “Oh hey I forgot to mention this is a thing in things like /entitydata”@Dinnerbone, October 6, 2017