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

77 Comments

Please sign in to leave a comment.

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

    After updating to this version and testing the changes, oh boy we are in a big trouble.

    The data packs are completely broken and every single line of command needs a re-work. This will be a nightmare for developers who maintain several data packs at once. I like the idea of simplifying the NBT structure. However, this is probably the worst way of doing it. Minecraft 1.20.5 is not even a major update and this feels really unnecessary, at least for now. Also, many component syntaxes seem unconventional (For example: the enchantment one) compared to the old NBT syntax.

    Only thing I really like is being able to see all the components in " [ ] ". Auto-fill function in components is useful.

    I highly disagree with this update and wish for it to be reverted.

  • 4
    Registered User commented
    Comment actions Permalink

    I think this update is not bad overall, but there are some points that are to me mandatory for a change as big as the nbt system :

    - All the old existing items using NBT must be translated to the new system seamlessly, and this needs to be thoroughly tested to avoid any items that would lose some data. (i.e. skulkers at the moment)


    - An option to automatically convert the contents of commands blocks must be provided. I know that this will most likely not fix all creations using them, but this would make the work to convert a map to the new version way less painful.


    - A tool to do the same translation must be provided to the community for automatically updating data packs. As with the command blocks, this will not fix it all but will, in my opinion, make it less painful.

  • 1
    Registered User commented
    Comment actions Permalink

    Was wondering how you would go about copying data, from say a chest boat Items property, onto an item using an item modifier? I see there's a copy_components function, but the snapshot post said that the source could only be "block_entity". I tried that on a shulker box block, and couldn't get it to copy any data when using the "minecraft:container" or the "minecraft:block_entity_data" component id. I can't figure out how to make this work. It would be nice if we could copy from storage data like the old way, or copy from an entity like a chest boat.

  • 1
    Registered User commented
    Comment actions Permalink

    Allow item displays to hold empty items (id:"minecraft:air" or no id and just custom_data property) for data usage like the old way, or provide entities with the custom_data property.

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

  • 3
    Registered User commented
    Comment actions Permalink

    If you guys are implementing this for Items, youre obviously planning on doing it for entities too. If youre gonna implement it later on that means youre gonna break datapacks twice. Rather do it in one go so people only have to relearn once. Also, please add a component that lets us detect items the player is moving with the mouse aas this data isnt available in the current setup.

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

  • 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 :(

  • 4
    Registered User commented
    Comment actions Permalink

    Seeing a lot of comments here about how awfully time-consuming this change will make for creators of datapacks, maps, etc.  I don't have much experience with this stuff, so I may not be qualified to shoot any ideas here, but would it be possible to have some kind of script to automatically rewrite NBT tags to the new format in worlds upgraded from previous versions, or something like that?  It does sound like it would be a ton of work to pull off, but if it works then it would save lots of time for those creators all over the world.  From what I can tell, most of the ISCs have the same function as the NBTs, so it should leave most things unbroken if done properly.  Again, I have no idea if this is feasible or not, please correct me in replies if I'm wrong.  Also if my sentence structure is incoherent please let me know and I'll do my best to clarify what I mean.

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

  • 1
    Registered User commented
    Comment actions Permalink

    I'm perfectly fine with it, in fact, I am happy about it, but only if it comes to Bedrock Edition. Why does java get all the cool stuff?

  • 4
    Registered User commented
    Comment actions Permalink

    This change looks great for making new commands, but maybe there could be a way to make both ways available to not break the old maps/datapacks people have been working for months/years?

  • 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

  • 3
    Registered User commented
    Comment actions Permalink

    Item Stack is meaningless. Item Stack brought nothing helpful to datapacks and with a lot of problem(almost all of the datapacks have to be overhauled). It will make a lot of datapacks stay at 1.20.4(just like a lot of mods stay at 1.12.2).I think the best way to improve performance is to replace OpenGL with Vulkan. 

  • 2
    Registered User commented
    Comment actions Permalink

    This new ISC approach is very interesting and, as stated above, will allow for more flexibility and extensibility in the future. However, I believe it is not a good idea to just replace the existing NBT syntax.
    With a breaking change like this that will affect many maps, data packs, and servers, more should be done to ease the transition and reduce the incredible amount of effort required to update all affected commands.

    Ideally a tool should be provided to update commands in any provided file or Minecraft world to use the ISC syntax, but of course making such a tool takes a lot of effort, and would open the door to the distribution of malicious scripts posing as this conversion tool.
    Another idea would be to support the storage of the older tag data alongside the new ISC data for a few versions. This would buy more time for everyone to update maps, data packs, and servers.

  • 3
    Registered User commented
    Comment actions Permalink

    is there any way the "custom_model_data" component/model predicate could have a namespace option? like if you wanted to set any item to whatever the apple model is (in the highest active resource pack) [custom_model_data="minecraft:item/apple"] or adding a custom model to something without needing to change the model file of the item itself with [custom_model_data="minecraft:item/custom/baseball_bat"] and such? i think it'd open up a lot of options

    another idea i had would be an optional "usable" component, that would simply allow the item (Any item) to be right clicked and detected by advancements, it'd be a simple true/false component and probably wouldn't break anything? i'm just a little tired of using carrots on sticks for everything

    i wish i had some actual functionality that exists that i think y'all missed but unfortunately all i have are suggestions for new functionality...

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

  • 4
    Registered User commented
    Comment actions Permalink

    Issue: Making items Default to a count of 1 stops us from making a distinction between single items and more than one item. Please make single items still have a count tag so we can make the distiction without the need of irritating work arounds. 

    The command: /execute if data entity @s Inventory[{Slot:11b,count:1}]

    will never pass as there is no count:1 on an item with count 1. 

    Mojang, i dont want to have to say the obviouse, but dont make the game worse with new updates. 

  • 1
    Registered User commented
    Comment actions Permalink

    This is a good change, but I would like, and I think many others would too, some way to convert 'old' commands to the new format? Many people are annoyed with big changes like this, but having a way to upgrade every command in a Minecraft world could be great if possible, similar to how worlds were upgraded to the 1.18 world height and depth.

  • 1
    Registered User commented
    Comment actions Permalink

    I can no longer charge crossbows with air, please allow them to use all projectiles like someone already submitted and air if we want the crossbow to shoot nothing as it was possible before :(

    Btw It would be very nice if you could add a component that locks the item in the current slot except for creative players, like curse of binding (The best would be a way to disable drop and/or change item mainhand and/or move the item in inventory)

  • 0
    Registered User commented
    Comment actions Permalink

    This is not a valued change, I don’t think the syntax of [nbt=] caused any issues and actually made things more consistent. Having to rework massive groups of command blocks for slight optimization when they ran fine to begin with isn’t a good idea, in my opinion.

  • 0
    Registered User commented
    Comment actions Permalink

    Not a fan tbh

  • 3
    Registered User commented
    Comment actions Permalink

    So... Now that we can put components on crafting results, the next step would appear to be to require certain components on the recipe ingredients. I get that this is a bit trickier, and I have a couple suggestions of how I think it could be made to work.

    Say, for example, that you wanted to make a recipe using a "Bronze Ingot", which is a Copper ingot with some components on it:

    copper_ingot[custom_name="Bronze Ingot",custom_data={id:"bronze_ingot"}]

    We wouldn't want to just test for the above components, because you want the Bronze Ingot to still work if the player has renamed it. However, we DO want the name "Bronze Ingot" to show up in the Recipe Book when you're previewing the recipe. So here's what I suggest:

    The ingredients in the JSON file should actually have two separate fields: "optional_components", and "required_components". Required components are what the item is tested against when you actually craft the recipe, but when the item is displayed in the recipe book, that display takes from both the optional AND required fields. So in the example above, the custom_data would be a required component, and the custom_name would be an optional component.

  • 4
    Registered User commented
    Comment actions Permalink

    With “minecraft:enchantments” and “minecraft:stored_enchantments”, I can no longer change the enchantment name or levels individually because they’re coupled together: {“minecraft:power”:5, “minecraft:smite”:4} . I can’t specify which or how many enchantments I want to check either because they’re set in a tag rather than a list.

    This is problematic because it breaks my functionality. I used to be able to transpose book ids and levels across, and now I can’t do custom enchanting without it. please fix!

    suggestion: [{id:”minecraft:power”,level:5},{id:”minecraft:smite”,level:4}] 🙏

  • 1
    Registered User commented
    Comment actions Permalink

    Bad idea

  • 1
    Registered User commented
    Comment actions Permalink

    I have an issue with the old nbt {} now only defaulting to custom data and components needing square brakets[] (in a give command for example). This stops us from dynamicly changing components using macros in datapacks, take this command for example:

    $item replace entity @s inventory.$(Slot) with $(id)$(components) $(count)

    the data being given to the funciton is data taken straight out of the players inventory:

    {components: {"minecraft:custom_name": '"example"'}, count: 1, Slot: 9b, id: "minecraft:netherite_axe"}

    This is the format it is saved as in the players data, but if i was to run this command, the components are saved into the "custom_data" component instead. This means that you the item given is not the same as the item taken. I think a simple fix wouyld be tosave components as an array instead on player data but idk how feasable this would be, as that opens up other issues in the formatting. Perhaps just swap the square brakets for curly ones and have 2?? 

    minecraft:apple{"custom_name":'"example"'}{other_customdata:1b}

    Edit: This raises the question as why components are loaded into an item as an array but comes out as an object literal. Is "custom_data" being saved from {} only a temporary thing for the snapshot?

     

  • 0
    Registered User commented
    Comment actions Permalink

    Will it be possible to make a spawn egg with a custom name, such as "Charged Creeper Spawn Egg" without the mob spawning in having a name at all? I know it's possible if you specify a name for the mob for it to be different, but it's not possible for it not to be named at the moment. I feel it would be better if when you named a spawn egg on an anvil, it should change the name and the entity name at the same time, instead of the entity name defaulting to the item name.

  • 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 :(

  • 0
    Registered User commented
    Comment actions Permalink

    I would like to point out a lost function with the item stack change.

    Enchantments and StoredEnchantments tags were used to be arrays. This allowed developers to dynamically adjust the values, whether it is the enchantment id or the level. Now they are a compound and we cannot detect the position of an enchantment. For example, Enchantments[-1] allowed me to find the bottom-most enchantment. We can no longer do that.

    A simple solution would be reverting to the original formatting and moving "show_in_tooltips" into somewhere else.

  • 3
    Registered User commented
    Comment actions Permalink

    I've been playing Minecraft as a technical command-block coder for 15 years now.

    Good: NBT data will be structured sensibly! Very good for performance -- especially for servers and adventure maps that use thousands of entities.

    Bad: This change is only for items?! If this change is introduced, it should be made for all NBT in the game in the same update -- block entities, regular entities, and items -- not just item data. Consistency is more important than partial efficiency.

    Good: Component data will be easier to read and understand than NBT tags.

    Bad: ALL NBT commands in the history of all of Minecraft will be broken and need to be re-coded. Please include an in-game tool to covert worlds and datapacks to the newer version -- INCLUDING all the code inside command blocks inside adventure maps. The whole community will support this change IF migrating existing adventure maps and datapacks is easy.

    -Bluesting_Stone