Back to minecraft.net

We've split up the commands, scripting and mods, and add ons category! Please be sure you get your thread in the right place.

← Commands
42
Follow

Let's talk about Feature Item Stack Components!

Pinned

With the latest 24w09a snapshot, we are making some large changes to how Item Stack-specific properties are stored and represented, replacing the current NBT 'tag' with structured components.

For a more comprehensive list of these changes and what they will enable us to do, please refer to the snapshot changelog!

We understand that this is a significant breaking change for many datapacks and custom maps which will require significant effort to upgrade. We do however believe that this builds critical foundations for future extensibility. We're shipping these changes all at once, with the hope to avoid future, incremental changes requiring many small updates to packs.

The current NBT 'tag' has existed for quite some time, and we are aware that a lot of clever techniques have been developed with this for commands and data packs. Although we have made our best effort to identify these cases, some of these techniques rely on undocumented or undefined behavior with certain tag configurations.

We want to ensure that no functionality is lost without a suitable alternative, but due to the undocumented nature of these techniques, we have very likely not caught everything! We hope to address any regressions over the remaining course of this snapshot cycle, but we need you help to do so. Therefore, we invite you to use this space to inform us of any edge cases that have been missed.

Avatar
Registered User shared this idea

74 Comments

Please sign in to leave a comment.

Date Votes
Sorted by oldest
  • 8
    Registered User commented
    Comment actions Permalink

    Will it be possible to define custom components or do we have to use the "minecraft:custom_data" for it? Would like to use this for creating custom items, it would be a lot easier if I could put data for my items in my own component that would not interfere with other components.

  • 6
    Registered User commented
    Comment actions Permalink

    To be completely honest, this is the worst thing which could happen. Wish me luck redoing the ~ 4000 commandblocks in my adventure maps :c

  • 8
    Registered User commented
    Comment actions Permalink

    Maybe a setup for nbt custom crafting recipes but now without nbt? Please yes?

  • 9
    Registered User commented
    Comment actions Permalink

    On Servers, the limit of 64 lore lines only will hamper the ability for showing users UI elements alone with their custom lore that is integral to the game.

    An example is shown below, from the server Hypixel in their game "SkyBlock"

    This example has 57 lines of lore, coming dangerously close to the limit, and is not "optimized" for the most amount of lore an item could have on this game.

    Below is shown the current limit on a 1080p screen in the newest snapshots with 64 lines.

    As you can see, there is a lot of space that could actually be utilized still, it may be a lot of text, but I'd prefer that this would be increased to something higher just so this limit isn't enforced for servers wanting to do something interesting with their lore on their items.

     

  • 15
    Registered User commented
    Comment actions Permalink

    PLEASE add an "intangible_item" component that prevents non-creative mode players from picking up an item, and/or a component that prevents picking up an item unless you're the player who threw it.

  • 15
    Registered User commented
    Comment actions Permalink

    I guess I submitted a post to the wrong area, but this new system is catastrophic to years and years of work and tutorials etc. on datapacks and NBT format. For datapacks that have a lot of items, it is going to be incredibly difficult to port them between 1.20.4 and 1.20.5/1.21 because the established system is being replaced. Regardless of the tiny bit of performance it could save, making years of commands and datapacks completely obsolete is, in my opinion, a bizarre decision and I hope this gets reverted, or left in only as an alternative. I'm working on a datapack that currently has over 100 "custom" items using NBT, and the new snapshot completely breaks all of them. I don't want to have to re-make every single command and function for all of that, and I'm sure a lot of people will agree! It'll be time consuming, and feels terrible knowing that all that work will have gone to waste

  • 2
    Registered User commented
    Comment actions Permalink

    I have just looked at the new updated format for player heads, and have three main questions:

    1. Where did the (nbt.SkullOwner.Id) vanish to? 
    2. What is the new *required* (component.properties.name) supposed to be? A uuid? a unique identifier (like "daisy.oreblock1")? or is it just something that can be filled in with "e" all the time?
    3. And a burning question, why is there a list of textures for the properties field when the player head only displays the first one?

    Another thing I am thinking is if hex values should be usable for colors (and it converts to the int value when storing)

    edit: Ok so properties.name must be included, cannot have spaces, must be less than 16 characters, and must be "textures", are there plans for a future type of texture for player heads?
    edit 2: profile.name is now required? I don't think that should be a problem as it wasn't before.

  • 3
    Registered User commented
    Comment actions Permalink

    Maybe I'm just being picky and pedantic about this but... why exactly are the "minecraft:hide_additional_tooltip" and "minecraft:intangible_projectile" components specified by an empty object? Wouldn't it be easier to just make them true/false (booleans)?

  • 16
    Registered User commented
    Comment actions Permalink

    Does this mean that all custom maps will break upon updating? Will all maps relying on commands blocks and/or datapacks need to be reworked?

    If this is true, this is going to make me more upset about any change than ever before. Forget chat reporting, mob votes, and all the other things people don't like seeing in updates. Why do I care so much? Because I poor all my free time into making maps for the server I run. I have dozens of maps on one server relying on mostly command blocks and some datapacks to create unique multiplayer experiences, and I simply don't have the time to spend 2 years of my life redoing these, as I have major changes to my schedule soon that won't give me that time anymore.

    I ask that if the changes are to be furthered with, tools are provided by Mojang to automatically update these commands/datapacks to fit with the new format. Something similar like MCStacker, but an official tool that upgrades it for you. This could be a part of some config file, either existing or added in. If it means using AI to rewrite code, I don't care. Make it happen.

    If the changes go on without an easy way to upgrade, I will probably abandon my server ownership, and my enjoyment of Minecraft alltogether.

    Could others please answer my original question and provide more ideas as to how this feature could be improved? I have faith that these changes, if executed correctly, will be for the better, but from what I have seen, I am disgusted.

  • 6
    Registered User commented
    Comment actions Permalink

    As a developer for modded servers, those changes are really exciting and will make it a lot easier for me and others to create nice custom content in Minecraft. 
    I also really appreciate the new syntax for /give, which is much nicer to use in-game than the old one. I also was very positively surprised that custom NBT tags were being moved to the custom_data component - I fully expected those to get completely deleted, being unsupported and all.

    I believe I and many other developers would appreciate if a component for the block itself could also be added. While its possible to change the block state properties of the placed block, its currently not possible to change the placed block itself. If you are using for example Noteblocks for custom blocks, as many people who don't do client-modding are doing, being able to define the block and state would be useful.
    However I wouldn't be surprised if we soon no longer need hacks like noteblocks for custom blocks, so maybe this isn't necessary at all. 

  • 6
    Registered User commented
    Comment actions Permalink

    This caused a lot of bugs to arise as a result.

  • 1
    Registered User commented
    Comment actions Permalink

    It sounds like this might make giving villagers custom trades in game easier, which I'm all for. Every update I have to add the new spawn eggs to some of my custom villagers to make use of custom/blank spawners (which I have set to silk touch diamond+). Every update I forget the command because it's so finicky and so long since the last use.

    Additionally, I'm using a mod which will read a datapack so I can fully customize the trades to make them what I consider fair (such as librarians only offering best trades at Expert/Master, removing point of trade cycling). As it stands, some of the datapack uses this...

    "functions": [{
        "function": "minecraft:set_nbt",
        "tag": "{StoredEnchantments:[{id:\"minecraft:efficiency\",lvl:1}]}"
    }]

    ...to set the custom trades. I'm looking forward to a more straight-forward section to customize the NBT based trades.

    And this is what is used for randomly enchanting gear via trades with the mod/datapack combo:

    "functions": [{
         "function": "minecraft:set_count",
         "count": 16,
         "add": false
    },
    {
         "function": "minecraft:set_count",
         "count": {
              "type": "villagerconfig:reference",
              "id": "enchantLevel"
         },
         "add": true
    }]
    "functions": [{
       "function": "minecraft:enchant_with_levels",
       "levels": {
          "type": "villagerconfig:reference",
          "id": "enchantLevel"
       },
       "treasure": false
    }]
    "reference_providers": {
         "enchantLevel": {
              "type": "minecraft:uniform",
              "min": 5,
              "max": 19
         }
    }
  • 8
    Registered User commented
    Comment actions Permalink

    There is a missing feature about Custom Model Data that is missing and would be a great thing for the community: being able to use Custom Model Data from multiple resource packs. I think now would be a good time to do it while you are working on items.

    Actually, when you use multiple packs with custom model data for the same item, the models override and you lose the predicates from the packs that are under.

  • 10
    Registered User commented
    Comment actions Permalink

    My general impression: This seems like a ton of development work for Mojang and datapack developers for not that much gain. Was it really worth it? I hope the mentioned future expandability makes up for it.
    More specific feedback:
    > `enchantments={levels:{'minecraft:protection':2},show_in_tooltip:false}`
    Why not something like `enchantments={protection:2,unbreaking:3,show_in_tooltip:false}`?
    `AttributeModifiers.slot` only allows one. If multiple were allowed, that would shorten item descriptions. I have often seen attributes copied 6× for all the slots. Now it would be 2, but could be 1. The case of all 6 could also be solved with another option "all"/"any", but a list would make combinations like legs+offhand easier. Maybe someone uses that for something.
    Why do potions and stews use different formats? Same question for bundles, boxes and barrels (or any other prefilled container).

    (BTW, if you are wondering about little feedback: Login here is broken since December, tracked in WEB-6665. On the mobile website, the character count stays at 0 and the "submit" button stays disabled. Trying to open the desktop website just leads to slightly shifting elements, but still the same issue. Please consider switching to a different tool, this one has had tons of problems since the beginning. Directing people to Discord is also not helpful if nobody can enter there.)

  • 7
    Registered User commented
    Comment actions Permalink

    I think this is probably a good idea in the long run, but it shouldn't be in 1.20.5 and should wait for a major update. Also, this new system needs a proper name, like how NBT was the name for the old system. "The components system" is generic and confusing, and "ISC" or "FISC" for (Feature) Item Stack Components sounds weird and unwieldy.

  • 3
    Registered User commented
    Comment actions Permalink

    /data get block 4 56 -19 Items[0].count
    doesnt give the count of items if the stack is 1 big, only 2 big or more. is it possible to have 1 size big itemstack also to get a count for 1?

  • 7
    Registered User commented
    Comment actions Permalink

    The syntax with the ! is great (the example was {"!minecraft:damage"={}} in the "components" field) but it seems we can't use this with things like the /give command. In order to give myself a sword with its damage component removed, I have to actually summon an item and give it data that way, because there seems to be no way to actually edit the "components" field using the /give command, and the ! operator doesn't work with /give either.

    I feel like either support for ! in /give or /clear should be added, AND/OR there should be a way to edit / test for properties of the "components" field directly using /give and /clear respectively.

  • 9
    Registered User commented
    Comment actions Permalink

    A few things I noticed:

    • Spawn eggs with custom data created with the old system are broken/haven't been properly converted 
    • Shulker boxes with custom items inside are now completely empty
    • Probably more of a feature request than anything else but it is no longer possible to modify the size of item stacks beyond vanilla limits (per changelog: "Stack size is now limited to the maximum stack size of the item"). Would it be unreasonable to bring this back in some form?
  • 21
    Registered User commented
    Comment actions Permalink

    Please provide a tool to automatically convert a datapack into the new component system.

  • 9
    Registered User commented
    Comment actions Permalink

    I don't mind that NBT tags are being replaced, however, I think this should be done in 1.21 instead, not 1.20.5. I expect there to be at least some form of interoperability between minor versions of the same version, the ten versions 1.8 had (1.8.0 - 1.8.9) being an example thereof.

    If I were to play a world made for 1.20.1, I expect that same world to work in 1.20.5 like it does in 1.20.1 (bugfixes in the meantime aside - but even those shouldn't have such a great impact like the changeover from NBT tags to components). This also includes commands which affect NBT tags. With the way components were introduced for 1.20.5, this is not the case. I don't (nor shouldn't) expect a world made for 1.20 to work the same in the next major version, which currently is 1.21. There will always be things which work differently major version to major version, even by the tiniest amount. The change from NBT tags to components slots in exactly just there, not in 1.20.5, nor 1.20.6, nor a hypothetical 1.20.24.

    I know Minecraft never followed semantic versioning (nor do I mind it), but at least save these impactful changes for major versions. It's not a competition for how many breaking changes one can introduce in minor versions.

    (As a side note, with what's happening to 1.20, it looks exactly like what happened to 1.8 and 1.9: an endless amount of snapshots. They're just called differently.)

  • 3
    Registered User commented
    Comment actions Permalink

    This may be a very good update for future new technologies, but it doesn't seem to bring anything new for now. However, I would like to see your emphasis on datapack.

  • 3
    Registered User commented
    Comment actions Permalink

    We also need to grant players permission to modify their NBT, which allows us to do more interesting things and optimize the parsing of physical NBT and block states.

  • 11
    Registered User commented
    Comment actions Permalink

    It would be really really nice if this finally meant custom item data (enchants, names) could be specified in recipe results and ingredients.

  • 1
    Registered User commented
    Comment actions Permalink

    cool update let my datapack revolve
    but actually improved some customability.

  • 7
    Registered User commented
    Comment actions Permalink

    - Confusing/inconsistent when to use [ ] and when to use { } (ex. /give uses [ ] for components and testing for components uses { } ).
    - It is not obvious that [ ] is the components tag (may prove confusing for new players when testing for items just like tag used to be).
    - Seeing the list of all components is awesome! (when inside [ ] )
    - The list includes everything, even impossible components, which is confusing/inconsistent (ex. snowball[base_color="orange"] ).
    - Component is much longer than tag to type. A shorter word would be preferable especially since it's on every item. Something like bit or piece or even keeping tag with updated component syntax would work better.
    - Forcing namespacing on all components is tiresome to type as well. "minecraft:" nearly doubles all option lengths when testing for items, which is a common practice.

  • 13
    Registered User commented
    Comment actions Permalink

    I have never ever made feedback on this site before, because I've pretty much rolled with every change.  However, I cannot stress enough how bad of an idea I think switching from NBT to components is.  Literally every single data pack and/or command in existence that utilizes items is now broken.  I understand that there are certain bugs that come about from the current NBT implementation, but I think that those bugs should be addressed without completely getting rid of a system that has been around for nearly a decade.

  • 5
    Registered User commented
    Comment actions Permalink

    This change causes an unfathomable amount of issues to arise dealing with copying nbt with both commands and loot tables.  I hope that there is work done to alleviate these issues, so I'll list some here:

    • Firstly, there's no longer a way to copy the nbt of an item stack to storage (or other entity nbt), and use it elsewhere.
      It used to be possible to copy data from components directly back into items with the command:
      `/data modify storage somestorage stored_tags set from entity @s SelectedItem.tag`.  Copying the components tag no longer works in other contexts.
      You used to be able to use `minecraft:copy_nbt` item modifier to copy that nbt from storage back into the item's tag data.  However, the two replacement functions no longer act in the same way.
    • The `minecraft:copy_custom_data` is functionally useless in this instance since the nbt added no longer affect the items.
    • The `minecraft:copy_components` is also not useful in this instance as it doesn't allow copying from sources like storage.  Even if it did though, it's required to specify which components are stored, meaning you can't use this function dynamically.
    • because the format of commands is different and now uses formats like [damage=5] instead of {damage:5}, you can no longer macros within commands to dynamically assign nbt to items.
      ex: `/give @s diamond_pickaxe$(stored_tags)` or `/item replace entity @s weapon.mainhand with diamond_pickaxe$(stored_tags)`

    I'm hoping solutions are worked out for these issues, thank you!

  • 3
    Registered User commented
    Comment actions Permalink

    very good

  • 1
    Registered User commented
    Comment actions Permalink

    It's all very exciting.

    We may regret the major break change it creates, which means a huge amount of work, but the long-term benefits are well worth it.

    This new Components system is incredibly more efficient and easier to use than the current NBT system. The fact that it's listed in the "data_component_type" registries, and can be used in command autocompletions is amazing. All this leads that editing items or comparing several seemingly identical items, will be much easier than through a massive and poorly structured NBT tag.

    Else:

    1. My biggest and real problem is that this change is made for 1.20.5. I understand that there has been a policy change in Minecraft's version strategy (with the use of "experimental feature"), but this change is far too big for a "minor update". Such a big change should occur in the "final phase" of the 1.21 release.
    2. The four Components "lore", "enchantments", "repair_cost" and "attribute_modifiers" are present by default in all items, even though they are empty. What's more, some of these Components are irrelevant to the vast majority of items. It would be much cleaner to have 0 Components by default as much as possible, and to put empty Components only if they are really relevant and/or fundamental to that item (maybe it's a legacy of the old NBT, but then it would have been nice to take the opportunity to clean it up).
    3. Like many, I hope that in the future it will be possible to specify Component values in the Recipes output.
  • 0
    Registered User commented
    Comment actions Permalink

    Why does the newly named set_custom_data function in an item modifier still use the "tag" property and string value format? Shouldn't it be "minecraft:custom_data": { test: 123 }

    [
      {
        "function": "minecraft:set_custom_data",
        "tag": "{test:123}"
      }
    ]