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

    I love most of these changes except for this one:

     

    Stack size is now limited to the maximum stack size of the item

    The old functionality allows for stack sizes up to 127 for all items, and I'm concerned this would break stuff that makes use of these custom stack sizes (for example, coins that stack to 100 for more convenient counting). Could we maybe get a component that sets the maximum stack size of an item?

  • 1
    Registered User commented
    Comment actions Permalink

    Please don't do this 😭
    I've gotten so used to the way the item tags work in commands and just in general. Changing this would make me and so many other people need to completely relearn techniques, commands, etc.

    I love the way we currently do iron_pickaxe{Damage:10}, iron_sword{Enchantments:[{id:sharpness,lvl:5}]}, and more.

    The new iron_pickaxe[damage=10], iron_sword[enchantments={levels:{'protection':2}}], etc. is PAINFUL.

  • 1
    Registered User commented
    Comment actions Permalink

    Hi!🫠

     

  • 1
    Registered User commented
    Comment actions Permalink

    to put just how much work updating our datapacks will be into perspective, i've taken a look at my Very Small Simple pack, i have 383 functions total, and 92 of them will need to be updated

    i'm not a professional, this is a personal project that's hardly public, this is something i work on for fun to have something to do and to have a place to hang out with my long distance friends

    making some vague assumptions, lets say each of the 92 functions has only one command that needs to change, and each one of those commands will only take one minute to fully update (which is a gross oversimplification, i've got a villager summoning command in one of the functions), that'd be an hour and a half being generous, that's assuming i didn't miss any functions that'd require an update- i was Really guesstimating with some functions, and that's with the "one minute per command" and "one command per function that needs updating" assumptions!!! and i'm supposed to look through all 92+ functions and search for something that'd tell me they're out of date and then look up each and every component i need to replace them, i'm a hobbyist. REAL MAPMAKERS will be taking DAYS to update their 500-1000+ function packs AND PLUGINS (and i'm not even mentioning the advancements and loot tables, i know a site to help update those semi-automatically but still a lot of work, probably averaging a minute each too!)

    please reconsider your approach or delay this change to 1.21

    also 64th comment, like a stack hehe :3

  • 3
    Registered User commented
    Comment actions Permalink

    It would be really important to provide a tool / gamerule / setting which automatically updates your commandblocks.

    If that doesn't happen, lots of map builders like me will probably quit, which would be quite bad for the minecraft communtiy as a whole.

  • 2
    Registered User commented
    Comment actions Permalink

    I think that everyone who is getting so annoyed hasn't read the 24w10a features, since it sounds like they did this so that they could add NBT Crafting. It's been requested for SOOOO long and I'm willing to have to reformat most of my Datapacks if it means that future Datapacks can be less buggy and have proper custom crafting support! Only complaint with the custom crafting is that the recipe reformat doesn't apply to ingredients, but I could care less. Keep it up Mojang!!

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

  • 4
    Registered User commented
    Comment actions Permalink

    with the new max_stack_size, i understand three digits is crowded on the inventory screen, but i think there's a number of possible solutions that'd be really simple and not change how things look too much

    1: align the 3rd digit further to the right when you reach 100+. just 2 or 3 pixels over to the right could significantly improve how things look and read

    2: make the last digits smaller upon reaching 100+ (the 2nd would stay the same in 2 digit numbers). add a second smaller font exclusively for the 2nd and 3rd numbers in triple digit item counts that's a 4x5 footprint instead of 5x7

    3: align the count lower by 2 pixels when you reach 100+. this wouldn't get in the way of any textures very much besides blocks and would significantly reduce how much of the item is covered by the count

    4: a combination of all 3, smaller last digits, the last digit pushed 3 pixels to the right, and the number moved down by 2 pixels. i've mocked this up and it's readable

    5: a continuation of bonus 4, just make Every digit smaller at 100+, this would make things slightly harder to read, but that's where my other suggestion comes in-

    6: add a count number in the tooltip, in the bottom right, white text, just ##x or x##. it could even be an accessibility feature to move the count number around, like it defaults to bottom right of the slot, but you can move it to any corner, even toggling it off, and then another option for the tooltip count, this wouldn't get smaller with the earlier proposed changes

  • 6
    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?

  • 4
    Registered User commented
    Comment actions Permalink

    This is excellent, thank you for this. You've been making some amazing technical changes recently. I have only two comments:

    1. I am concerned about the 99 stack limit. In my view, this is a regression. Developers will likely at least want the stacks to reach 100. Considering the count value is now an integer, aside from UI reasons, why should this be limited to such a small number?
    2. I hope this change is applied to entities, too. I am not a datapack user but judging by the other comments I expect they would rather this change be applied to everything at once instead of items first, then entities. I personally do not mind the order it changes though.
  • 6
    Registered User commented
    Comment actions Permalink

    Please add a repair material component

  • 1
    Registered User commented
    Comment actions Permalink

    hi i've started updating my datapack to 1.20.5 and i've already run into one issue brought on by the component system, namely i used to use fireworks with a flight duration of -127 to add an element of randomness to using them, but even without the inconsistency i'd still appreciate the ability to create fireworks with less flight duration than 0, despite having valid values of -128 to 127, negative numbers just underflow into 255. unfortunately i really can't see any way to make either randomized or instant fireworks anymore, i hope i don't run into any more problems like this as i continue updating my datapack.

  • 2
    Registered User commented
    Comment actions Permalink

    I feel like the tradeoff with all the recent additions makes it worth it, although making it so that there was a component to change the models of armour would be greatly appreciated

  • 0
    Registered User commented
    Comment actions Permalink

    🌪️🌪️🌪️🌪️🌥️

  • 0
    Registered User commented
    Comment actions Permalink

    TLDR: Please make it possible to check for the existance of a component.

    There is now no way to check for a charged crossbow anymore across survival or creative. Before, I could check for "charged:1b". Now, the tell is whether the "minecraft:charged_projectiles" component exists on the item. But from what I can tell, there is no way to use a command to check if the selected item has a certain component on it at all. I can only check for an exact match to the total contents.

    In changelogs:
    minecraft:charged_projectiles
    - Replaces Charged and ChargedProjectiles tags

    If it truly replaces the "charged" tag, then please let me simply check if it exists. I used to do:
    execute if entity @a[nbt={SelectedItem:{id:"minecraft:crossbow",tag:{Charged:1b}}}]
    , and it would work whether you were in survival or creative.

    But now, the contents of "minecraft:charged_projectiles" changes depending on your gamemode, and you have to check for an axact match of an arrow or something, so you can't even search for a crossbow that is charged in general.

    So far, the only way I've found to almost do what I could before is this:
    /execute as @a if items entity @s weapon.mainhand crossbow[charged_projectiles=[{id:"minecraft:arrow"}]|charged_projectiles=[{id:"minecraft:arrow",components:{"minecraft:intangible_projectile":{}}}]]
    , which relies on checking for survival arrow crossbows OR creative ones, but still doesn't cover fireworks and stuff.

    Please make it so that there is a way to simply check for any charged anything still. My recomendation:
    /execute if entity @a[weapon.mainhand:{crossbow[charged_projectiles]}]
    Something like that ^, just to check if an entity holding a crossbow that has a "charged_projectiles" field exists.

    This would help in many, many other situations too.

  • 0
    Registered User commented
    Comment actions Permalink

    There have been a lot of comments about how this change breaks many different types of creations. When it was released it automatically updated preexisting items (in inventories and chest) to the new component format. It would be cool if there was something that could be used to update command blocks or data packs to the new format.

  • 0
    Registered User commented
    Comment actions Permalink

    bring back item tinting please