What Is Metadata In Minecraft, So, I Don&#39T Understand Metadata : Feedthebeast

The reason I presume this is because the 1.13 move away from metadata seems to be mostly received as a positive. For a mod like Forestry for example, which has pages and pages of items which are nearly but not quite identical, will they just have to make a new item for every one now? Won't that be insane? Even a small example, like there being 17 different honey combs. Will it really be an improvement to have to create 17 different classes for these nearly identical items. Obviously not, hence the title. Thanks!

9 comments
share
save
hide
report
67% Upvoted
This thread is archived
New comments cannot be posted and votes cannot be cast
Sort by
best

*

level 1
2 years ago
The basic idea is this(IIRC, Please correct me if im wrong):

Items that are completely different -> split into two seperate items, usually these are two seperate classes in the first place so its really just changing the id.

Đang xem: What is metadata in minecraft

Items that are similar -> 1 item class that handles all its data through nbt/tag system.

See https://gist.github.com/williewillus/353c872bcf1a6ace9921189f6100d09a for more info.

6
Share
ReportSave
level 2
Ender IO Dev2 years ago

You will have unlimited IDs in 1.13, so for example if your mod adds a bunch of different ingots (just different textures/names) you wouldn't use nbt for those, because each can have its own ID. Nbt based items already exist and will probably remain the same (E.g. Bees in forestry). Currently items use meta data (or damage value) to store multiple items within the same ID, but this won't be needed in 1.13 because the IDs are unlimited. Using nbt for different types of ingots for example would be a nightmare for pack makers, so just take advantage of unlimited IDs!

2
Share
ReportSave
level 2
Multi-NerdOriginal Poster2 years ago

I hadn't though about using NBT for the items, that does make sense.

1
Share
ReportSave
level 1
highlysuspect.agency2 years ago · edited 2 years ago

The big takeaway here is that block IDs don't refer to classes, they refer to instances of classes. Same for item IDs and the like.

Read more: Lyrics To The Song All I Know Bow Wow, Lyrics To The Song All I Know

As an example, vanilla's BlockStairs has a constructor that takes a blockstate as an argument. It means you don't need to make a whole bunch of BlockStoneBrickStairs, BlockBrickStairs, BlockPurpurStairs classes, one for every stair in the game – you can pretty much just call new BlockStairs(Blocks.STONEBRICK.getDefaultState()), and poof – it's already a stair block, that behaves in all the ways you would expect stairs to behave. And, despite using two block IDs, there's only one BlockRedstoneTorch class; it just takes a boolean parameter for whether the torch should be “lit” or not. Same for BlockRedstoneLight, which is in charge of both redstone lamps. Iron bars and glass panes are both BlockPanes, a class that takes one Material argument and one boolean determining if you need Silk Touch to collect it.

Frankly I'm really surprised they didn't start doing this much, much earlier! Slabs are horrendous. They tried to shove as many slab types as possible into 16 data values, which (surprise) ended up being a nightmare to maintain. There is a wooden slab that behaves like a stone slab, an artifact of Minecraft 1.2, that still exists in 1.12, simply because it is so hard to remove. Not to mention they ran out of metadata values so they had to make a stone_slab2, then came to their senses and made a purpur_slab… Fuck. Metadata.

The best part, though, is that the way a block looks is nearly entirely defined by its model. If you want two blocks that behave in exactly the same way, you don't even have to pass in an argument in the constructor – you just have to make another instance.

Vanilla Minecraft actually already does this in a couple of places. There's a handful of blocks, such as iron blocks, coal blocks, purpur blocks, end stone, etc. that don't even have a class all to themselves, being registered only as new Block() with a handful of setters chained on to the end. There's a similar thing going on with BlockFence and BlockFenceGate.

Read more: wow deep ocean vast sea

(Of course there's some historical weirdness in vanilla Minecraft – there's a BlockNetherrack class, for example, which extends Block, but only consists of things that could have been set without using a custom class at all. Ah well. Hopefully that goes away in 1.13.)

And by the way, “flattening” and removing metadata actually allows for simplifying a bunch of things. Right now, most blocks that use metadata for distinct “variants” (such as how stone bricksm chiseled stone bricks, and cracked stone bricks all share the same block ID) need to have a class all to themselves, so they can work out which item that the block should drop. You won't even need to make a block like that in the first place in 1.13. Flattening blocks also means I can get rid of all my getMetaFromState/getStateFromMeta methods, which are just boring tedium to write.

Leave a Comment