Internal code changes have basically confirmed that the basic framework for datadriven items and blocks is in place! with these new changes in 24w09a and the sentence ("Continue to evolve the game to enable the creation of dynamic content") I hope that we might see some of this in the next few snapshots!
Having a "blocks" and "items" subfolder inside a datapack would be THE DREAM. So much hype around this snapshot cycle, I can't wait to see what happens in the next few weeks.
Honestly, just from how the format looks, this is so much better formatting than what we had before. I'm really excited to try this new system for some of my projects!
They just announced custom components for bedrock edition, we've had java scripting for a while now integrated in addons but now you can register a Javascript function as a custom component for a custom item or block. I love that they are constantly working to improve the game for every type of player rather than just updating the survival mechanics
this new format looks so much cleaner in my opinion, i really really really hope that with this new system we get nbt crafting, it would make creating custom items much easier and the separation of custom tags might also make easier to detect custom items as well
I just hope they add more functionality to the custom items and if they add that you can use textures inside a datapack, it would be a revolution for datapacks. give @s stick[right_click="mydatapack:function",texture="items/nether_star",model="items/iron_sword"] Nice video!!
That right click idea would be AMAZING! We'd be able to say goodbye to the awful ticking-command system of the Carrot on a Stick forever. The model within a datapack idea is also something I've been wanting for ages lmao
Imagine if they had a fully supported event listener that could track any key on the keyboard, that'd be sick. something like /give @s stick[event_listener={{"right_click","mydatapack:function"},{"numpad_1","mydatapack:function2"}}]
@@feintha me personally? no, not really. mods specifically made to supplement Datapacks/MCcmd creation never really made any sense to me. Im sure someone else might find it cool, though.
Could be like minecraft:on_right_click=… which takes in a string containing the command. Could also be used for left click, middle click, key presses, etc. Much more intuitive than the carrot on a stick and scoreboard method.
@@checkmate1284 that would work really well actually! Maybe even add triggers for other buttons and actions too like “jump” or other things you can do.
@@conure512the issue with this is that if QOL mods become unsupported that's a massive gap in the modding community, because hybrid servers are.. not viable
@@oude_henky No one said that you would lose mods. What he is saying and where I agree is that the majority of mods even complex mods like the Aether mod will soon be able to he fully realized as Data Packs instead. And using Java Code based injection mods will only be used to expand the game engine with new features. That those Datapacks might want to use. If you are familiar with Bethesda game Modding (Skyrim, Fallout) there we have mods that are made with the official developer kit that use the games script language and database structures to add mods to the game (similar to Datapacks and Resourcepacks) those (usually, unless there is a big engine upgrade but even then 99% of them are fine) don't break with updates and don't require knowledge of advanced "proper" programming languages to make. But there is for each of their games a script extender that is kinda like a mod loader that adds new tools to the existing script language (Data+Resourcepacks in MC) and allows the loading of custom engine altering code mods which also can be referenced by the "datapacks". So we will possibly see a similar system emerge for Minecraft soon where making Datapack "mods" will get easier, more powerful and more common and where "proper" mods are just dependencies and frameworks that get used by said data packs to do things the vanilla engine can't do (yet).
5:26 Aged like fine wine lmao You can actually get different durabilities, stack size, NBT crafting AND more like if something is eatable and if it works like a axe or pickaxes!
I was just getting started with making datapacks and got quite confused, but on the other hand I won't have to relearn all that much. It will however probably take a while for good support and documentation to be available I guess, so I might have to wait a bit on it. Can't wait to see what feedback the professionals are giving to mojang so they can these changes as good as possible
Given that the snapshot changelogs have been getting more detailed lately, the wiki has actually been pretty on top of it when it comes to providing info! Here's the wiki page for this snapshot, it's already got a lot of useful content minecraft.wiki/w/Java_Edition_24w09a
As a data pack creator that absolutely *adores* vanilla custom items ever since meeting them in hypixel, I cannot wait to see what kind of things the minecraft community can come up with. Especially with the 24w10a snapshot and above that ALLOWS CUSTOM NBT for items.
Being able to store custom data of any name (and values for) is very useful, especially if there are commands that can check for these. With custom data and the components seen thus far I can imagine functions where: - You can make items that would previously stack no longer stack by giving them each different custom data tags. - Items that appear identical but actually have unique properties. - Determine forgeries of craftable items that are meant to be given by a quest or other source. - Possibly allow for any time to function like a different item by removing/giving components belonging to another. (Visually: Flower / Reality: Flame sword) - Hide the properties and glints of items to make it less clear what any given item actually does, which the player can discover by usage. - Modify what specific blocks an item can break or be placed on, a resource that could also be limited. - Give an item a custom score/time that can increase/decrease via command blocks; score/time that could affect what happens the longer the player has it. - Give previously mundane items special properties that normally don't exist for it - Change the entity properties of spawn eggs to make them behave differently or otherwise spawn in a specific state Honestly the possibilities with this are quite vast.
Exactly! This stuff has all been possible already because items were able to accept any NBT data into their "tag" field, but this change is just serving to rework (and streamline?) that whole process by making only one component that can hold any generic data (minecraft:custom_data).
It’s nice to see an actual data pack creator speak on the changes, I’ve seen so many people with zero data pack experience scream at the feedback website that if they don’t change this back then everyone will stop playing
I started playing in 1.4, the command block update :') sooo many changes that have been hard to keep up with, especially when irl stuff has been way more full-time if u get me. Very grateful for ur tutorials :)
I hope they are adding in the future a way to add entire new blocks, itens and entities throw datapacks, adding custom dimentions and biomes would really be used if this was the case
This is going to break thousands upon thousands of lines of code. I'm thinking of just porting my datapack to a mod. I'm excited for the future support from Mojang, but unless I can write a Python regex script to easily update my datapack, this is going to basically force me to rewrite so many files.
Now I am so hyped for what's to come! After already giving us new attributes, and basically "variables" for our code. I feel extremely spoiled for technical features!
I had said for a while that 1.20.5 was gonna be "The Attribute Update", and I'm gonna have to revise that view because they managed to do something even MORE game-changing lmao
Okay you scared me with the first part - but after you explained what it was replaced with, that is going to make things so much easier to differentiate. Great addition and its a super easy fix as well.
I have hope this system will make custom crafting, right click and left click, easier I won’t have to relearn everything but let’s see how far they could make this concept go
From what I can tell, almost all old modpacks with modified item data can be converted to the new system fairly easily. I could see someone creating a converter that does it automatically for any pack.
Yes! And I'm sure we'll see some automatic datapack converters as well, but there's no way they're gonna cover everything (some packs will definitely need to be updated manually). The Component system changes /give in a way that's really easy to just algorithmically replace, sure, but it also changes the internal NBT storage format of items. So data paths will also need to be updated, and it would be VERY hard to write an algorithm that updates those accurately and without accidentally breaking other data paths. And then when you factor in the existence of Macros, all bets go out the window lmao
It may be possible to make a program that can convert the old NBT stuff into this new format which would greatly ease the pain of datapack developers. I don’t have any skin in the game anymore, but I might still try just to test my algorithm and coding abilities.
This change is great! It gives me hope for things like maybe finally being able to have custom recipes with components, right/left click triggers, custom durability on all items, switching item ids while maintaining the same components, etc..
I remember when the /execute was added. I absolutely didn't know how to use and was pretty mad, because my previous knowlage was now useless, because of that I even quit mc for a year or two. Then when I rediscovered my passion for commands, I watched a couple tutorials and saw how much potential layed there in this single command. Probably the same case here but on a smaller scale.
As someone who hasn't really dealt with this before the changes are actually really nice to make it easier to do without a reference. I never really used to know the options. Breaking things always sucks but I'll look on the good side for this one.
Ngl, this is actually sick. All the command changes and additions in the past year or so have been amazing, from display entities to camera commands on bedrock, and now this! Command block creators are eating good
It's my understanding that the biggest benefit with the new components system is performance. Apparently, with the old NBT system, everytime minecraft wanted to query some data from an item, the game had to compile the item's entire NBT, even if the game just needed a single value. The worst culprit of this where dyed and/or trimmed armor, which had to compile their NBT every single frame just to figure out what color/trims the game should render. Now with the new components system, an item's data is only compiled upon creation, which should bring with it a notable performance improvement, especially for items with a large amount of NBT which previously had to be compiled every single frame. I'm guessing that now with the new system, things that would have once been detrimental to performance, such as having a field to specify a custom texture of an item is now feasible. Previously, if a custom texture field existed, and if it where universal to every single item, then for every frame for every item being rendered in the world, the game would have had needed to compile the item's entire NBT just to query "does this item have a custom texture?", which 99.99% of the time would return "false", but now since the game only has to compile an item's data upon creation, something like a custom texture field is now feasible. The biggest question I have is: Why create an entirely new data format? Surely, Mojang could have just reworked how NBT is processed in the back end, granting enhanced performance, and in turn allowing for more functionality without needing to create an entirely new data format? My best guess is that Mojang has been wanting to change how NBT is processed, stored, and is set by commands for a while now, and have used this opportunity to do so all at once, and hence, the new components system.
You can actually do many more things : enchantments are less restricted to specific items (yes that means multishot piercing bows and infinity crossbows), you can put more projectiles in crossbows (more than 3 multishot) and there could be more to be discovered
I'm creating a datapack since 3 years (it's taking a long time bc i do it as a hobby) and i have to change near 75% of the code. But, if this change comes with new things in the upcoming updates, I'm happy with that
i wonder how much this will change mod creation as well because recently i've been making some stuff that uses nbt to track stuff but now im wondering if i'll have to rewrite all of that and will i also be able to make my own custom components for my own functionalities? and will datapackers be able to make and use custom components as well?
I tried custom components already, and no, at the moment they don't seem to work. The custom_data component can hold any NBT data tho, so we're pretty much covered there in terms of adding custom things to test for.
What I want is: Minecraft:durability Minecraft:break_tier (string. It allows editing of tier via tags, such as "needs_diamond_tool") Minecraft:tool_type (ditto, but the type of tool) Minecraft:Efficiency (the break speed of the tool) Minecraft:max_stack Component crafting, including the display of the item, and what the item actually needs
That would be cool! People have speculated that this might be coming to the game ever since they added the /tick command (apparently that command was originally part of a mod that also added movable tile entities, and that mod's developer is now working for mojang.) I'm not good enough at redstone to appreciate what movable tile entities would allow us to do, but it definitely feels like it would be gamechanging haha
If I understand correctly, this won't break datapacks where nbt wasn't being changed, right? So like if I have a datapack that adds a custom structure to the game (like a village), that should still work?
While data packs were added in 1.13, 1.12 already had functions, so you could already have your commands outside of command blocks. Another benefit of the item component change is the ability to validate the format of components and provide more useful tab completion, which eases the burden of memorizing item NBT formats. This kind of parallels the 1.13 command changes, where I found the new /execute syntax less daunting than the old one. (Though I don’t mess that much with commands to begin with.)
I only really got into commands 2 times in my life, spending months to learn to code and use nbt and make datapacks, and somehow it was the two times minecraft did a COMPLETE REWORK of the coding system just after... I can't dude, all of that work is GONE :'(
Oof, I feel for ya bro. IIRC I actually quit for a while after 1.13 dropped as well. All I can say is, look out for the next few snapshots, because I guarantee they're gonna add something that'll make it worth it to come back and re-learn the syntax haha Also may I just say, you have the best profile pic here hands down
I'd love less janky blocks and items. Especially the ability to not need to use entities to create them. And the ability for commands recognise inputs.. and more powerful ways to change our GUI, like the ability to add extra slots or create non-janky solutions for custom blocks.
This will fuck my current datapack hardly... well, not really, but I have like 30 items there and I need to remake all of them from 0. Good thing I started using predicates to detect stuff instead of direct NBT in execute, so it should be fairly easy to change it. I will wait tho, untill they change smth else or add something that I really want to try to actually force myself to change from 1.20.4 to 1.20.5
Im actually excited to see the upcoming changes, like how much more freedom do we get and how close will datapacks now be to modmaking, now obviously mods will probably be still the bigger thing but i wouldn't be surprised if bigger mods from the past could be made entirely in a datapack, which would be amazing since that would also reduce the amount of work a mod maker would need to do, no more updating the mods every time a new update comes, no more compatibility problems etc. If Mojang truly manages to make datapacks and commands more advanced then im up for the change since these kind of changes are on a similar level as updating a mod for a newer version its gonna be a bit of work to update those datapacks sure but you probably only need to do it once and then they most likely will be stable for the future unless Mojang makes a similar big change but i doubt they will do atleast not in the near future after this update so all in all im excited to see what new possibilities we are getting
I am waiting for the moment that datapacks can make plugins irrelevant. ( thats a joke ofcourse, however there is some truth in this in the fact that mojang is constantly improving commands )
Enchantments, firework explosions and probably other stuff have a ton of problems with this system. Also stack size limits are dumb imo. Enchantment glint is great. For now I'm happy with the new changes and I think these could be a solid infrastructure to work with, however until they fix the problems and change the few dealbreakers (for me) I won't work with datapacks. This is also a problem cause I'm making a map that has features from 1.20.5 snapshots, so I can't downgrade nor upgrade and I might quit the project altogether if anything
I really like the change. However, the formatting for enchantments irritate me so much. Why the heck it isnt just the same as before or maybe enchantments:{"minecraft:sharpness":1...}? That "levels" doesnt make any sense at all
I think it's so they can also have the "show_in_tooltip" field without having to make a new component for it. And who knows, they may also add more formatting options that dont fit the "key:level" format (which is what the levels field seems to be for).
You mean the example with the "Damage" field? That exact example was described in the official snapshot changelog, I know PhoenixSC explained it that way and I did too because it's honestly a great intuitive example lol
With the existence of the attack range/speed/damage and mining speed attributes, the ONLY thing preventing us from making 100% custom tools is the item durability. I'm REALLT hoping they add support for custom durability at some point...
Every time a namespaced feature is added, my hopes rise that it will be expanded to datapacks. So far it hasn't happened too often, but I can still hope!
They could 100% change the innerworkings of NBT and still maintain the same interface as before, with curly brackets and cammel case and try not to break all datapacks BUT INSTEAD they chose to migrate everything to brackets and snake case for literally no reason other than aesthetics lmao This update can be good but it's really bad implemented, it's like reworking an API internals and for no reason other than "nah it will look better" change all endpoints params to another casing just because. As a dev this make me so angry ngl
{} is dedicated to NBT. This is completely different from NBT. Mashing namespaced keys into NBT syntax would be really messy and difficult to make work. they didn't break compatibility for fun, they did it because, logistically, they're required to
@@thegoose2071 To clarify this a bit, item components ARE technically still NBT (at least they're internally stored that way), it's just now a much more optimized system and the front-facing commands like /give and /clear are being changed to make interacting with these components feel more intuitive than before.
