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
51
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

76 Comments

Please sign in to leave a comment.

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

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

  • 17
    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.

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

  • 17
    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.

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

  • 11
    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.

     

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

  • 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.)

  • 9
    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.

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

    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?
  • 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.)

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

  • 8
    Registered User commented
    Comment actions Permalink

    It was mentioned that this change would add future extensibility which is super exciting! I'm really hoping that in the future, new components are added that take on the role of currently-hardcoded item properties like:

    • Max Stack Size (could make unstackable items stackable or vice versa)
    • Total Durability (item breaks when Damage exceeds this value)

    And as others have mentioned, it would be great to be able to add components to crafting results, and hopefully also have the option to require certain components on crafting ingredients!

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

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

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

  • 7
    Registered User commented
    Comment actions Permalink

    These changes have potential to bring a lot of exciting new features to the game. As for now I am on the fence about the changes since at the moment we have only seen what can already be done (granted, it is still only early days) but I think I speak for us all when we'd like an update on WHY this change was necessary and what will be achieved by the change. As far as for "improved performance" or "faster load times" on the surface it doesn't seem quite worth it. 

    We'd like to see revolutionary new features that weren't capable before, such as custom crafting recipes that support these new components, abilities to effectively create new custom items that don't just rely on a retexture of existing items, custom armour models, perhaps custom blocks even. Changing a system that has been essential to the game for the past 6+ years, as tens of thousands of hours of tutorials and who knows how many YEARS of work in custom maps is seemingly being upended. Perhaps a tool that could convert old NBT data in command blocks and data packs into the new component tags wouldn't go amiss, even if it's not 100% perfect for all cases it would not go unappreciated by the community.

    PS: Huge respect to how you lot at Mojang have approached this, the post announcing it was very clear and concise as well as thoughtful about the implications. Hopefully together we can work on a system that benefits the community as a whole to progress the creativity enabled by this change <3

    PPS: R.I.P camelCase :(

  • 7
    Registered User commented
    Comment actions Permalink

    SUGGESTION TO CHANGE THE "FOOD" COMPONENT:

    • Firstly, I really like the new components! Yes, we need to redo all our item commands, but we get a whole bunch of new features in return! I'm writing this on the day 24w12a came out which added even more components.
    • So I really like the "food" component but I suggest changing it to "consumable" making items also be able to be cunsomed as a drink (like: milk, potions, honey) and play the appropriate sounds when consuming the item.
    • When an item has been consumed, maybe there should be a field to specify what item will be left behind, like with drinking a potion (leaves a empty bottle), eating a stew (leaves a bowl) and drinking a bucket of milk (leaves a bucket). You get the idea. It could be pre-programmed to be one of the items already with liquids or food inside (like the items I mentioned) or it could be completely customizable by typing any item you would like to be left behind after consumption. 

    I hope this is some good feedback and you like my idea!
    I really like what you have been doing with the components so far. It's a welcome change. Keep it up Mojang!
    (P.S. English isn't my first language so I apologize for the spelling errors I made...)

  • 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

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

  • 6
    Registered User commented
    Comment actions Permalink

    As a server developer, this change is likely to break many things and set back years of progress on servers. It will also alter the way plugins are made. This might be too much of a change for some plugin authors, and sadly, we may lose a lot of amazing work out there.

    NBT data is at the core of many servers and how we create custom items. It doesn't only apply to items for players to use; it is also crucial in making custom HUDs, mobs, and buttons and much more. I can foresee many servers choosing not to update to this version, potentially creating a significant divide among Java players.

    All the other features you have added in this update are great, but I urge you to reconsider and revert this particular change. I don't believe you fully grasp how detrimental this could be for servers, and it might even jeopardize the future of Java Minecraft.

    You need to provide a way to implement both methods. While I understand this update aims for performance improvements, the question remains: at what cost? Is it worth sacrificing the incredible work already done and risking servers packing up and leaving?

    Out of everything you have sever implemented please please reconsider this. There are genuine big plugin dev scared of this update.

  • 6
    Registered User commented
    Comment actions Permalink

    Please add a repair material component

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

  • 5
    Registered User commented
    Comment actions Permalink

    I will stay on 1.20.4 if this change goes through, I have spend many months working on a datapack, and while this is not as big as some others, and not as technical, this will ruin many systems that have already been put in place. Ruining minecraft commands and tutorials from the past few years is probably the one thing I was hoping Microsoft wouldn't do, I don't mind if some bad decisions are made, but simplifying commands, and changing the entire syntax is a horrible decision

    First, this will ruin any pre-existing tutorials for commands

    Second, this will make everybody have to re learn a new system, that may not be any better, it's (in my, strong, opinion) a stupid choice to make people have to re learn a new system for a minor increase in performance, if this will make datapacks a TON easier, or if there is a tool to translate old code, this I like this, I think that a change is needed, but not one where it will ruin all work that has been made up to this point. I like the new updates, and I want to see them, and I don't want to be one of the people who stays in the old versions because I'm an "oldie", but I cannot see how this will make commands easier to write, if your serious about commands, you use datapacks, and tools that autocomplete commands for you. What I'm saying, if it isn't very obvious by now, is that I don't support this, and I'm pretty sure that every single person who uses commands seriously will at least minorly not like this change.

  • 5
    Registered User commented
    Comment actions Permalink

    I understand that those Changes were made with good intentions for future Minecraft Maps,however think about all of the Thousands of Maps that were made before the Stack Component Changes and that also contain custom Items.

     

    I myself am a Map Maker,and seeing that such a good Change affects my Maps so negatively is truly devastating.That's why I offer two solutions to fix all of the outdated Maps and make them compatible with Snapshot 24w09a and above Versions:

     

    1.Make a Command Conversion system that automatically converts any Item Component using the old method to the new one.This might seem hard,but considering that you managed to make old and new chunks in 1.18 blend,you could easily do it. :)

     

    2.Create a Toggle to either activate or deactivate the Stack Component Changes.It could either be an Option in the Settings where the player could choose between the new system (E.G: "Advanced Stack Components") and the old one (E.G: "Classic Stack Components") or maybe an Experimental Datapack that adds the new Components.

     

    I hope you understand that this Change has brought more outrage than joy amongst the Minecrafft Mapping Community,and I also hope that at least one of these solutions gets applied to the Game in the next 1.20.5 Snapshot (If it's even a Snapshot and not a Pre-Release...).

    Thank you in advance,

                                                                -TheBlockyGoat72

  • 5
    Registered User commented
    Comment actions Permalink

    Please allow the "charged_projectiles" component to include all projectiles such as snowballs, eggs, fireballs, etc instead of only allowing arrows.

  • 5
    Registered User commented
    Comment actions Permalink

    One of the things that is impossible to do now that was possible before was the functionality of the HideFlags.  I cannot use the /item command to hide the flags of an enchanted item without overriding all of the enchantments on that item.  This is because "show_in_tooltip" is linked to the enchantment itself in set_components in item_modifiers.  This also applies to other components as well besides just enchantments.

    An easy solution would be to separate the tooltip component from its respective component by adding more components like the already existing "hide_additional_tooltip" component, i.e., "hide_enchantment_tooltip," "hide_unbreakable_tooltip," or maybe even "hide_all_tooltips".

    Another SUPER USEFUL solution would be to add an "add_components" function to item_modifiers, because set_components just doesn't cut it in all cases, especially given that we can't use the /data command to modify player data and have to rely on the /item command.

    I don't know if this comment will ever get read, but I really hope it does, because I have been upgrading my data pack for my map to every single snapshot for the past 2 years, but this limitation of components will bar me from ever getting to update my data packs again :(

  • 5
    Registered User commented
    Comment actions Permalink

    With the new components, there are several parity issues and inconsistencies that should be addressed:

    'minecraft:food': component lacks 'using_converts_to' - this is a string in addon components that allows food items to turn into another item after being eaten.

    'minecraft:rarity': is odd and limiting.  It should likely be converted to 'minecraft:hover_text_color' to match Bedrock's component.

    'minecraft:enchantment_glint_override' is wordy and could just be converted to 'glint' to match with Bedrock?