Hi,

 

Is it somewhat illegal to create an ItemStack of Blocks.cake? The following code is throwing a NullPointerException for me:

 

new ItemStack(Blocks.cake).getDisplayItem()

 

The root of the problem is that such an ItemStack has a null item internally. Why is that? This doesn't seem to be the case for ItemStacks of other types of blocks...

Try using Block.getItemForBlock(Blocks.cake) or something like that. If that doesn't work, then the cake block doesn't have a corresponding ItemBlock (like doors), but a special Item, so you'd use Items.cake or whatever it's called instead.

Cake does not exist as an itemblock, you want Items.cake

Mojang removed the "technical" block items that should never be in you inventory (like unlit redsome torches)

If that doesn't work, then the cake block doesn't have a corresponding ItemBlock (like doors), but a special Item, so you'd use Items.cake or whatever it's called instead.

 

This is the case. Cake and a few other blocks have separate

Item

forms that aren't regular

ItemBlock

s.

Items.cake

stores the

Item

form of Cake.

 

Look for usages of

ItemBlockSpecial

(1.9) or

ItemReed

(1.8.9 and earlier) to see which blocks have separate

Item

forms.

I see. I'll do some exploration, but at least now I understand what is happening. Is there any generic way to know if I have such a block in hand? Ideally, I want to be able to receive any block in a method and call getDisplayName (or something similar) on it, being it one of those special blocks or not. But then, I guess I would need a generic way to get the item corresponding to the block, in other words, a non-hardcoded way to know that Blocks.cake corresponds to Items.cake for example. Is there such a thing available or should I write a mapping myself?

 

Thank you guys!

Minecraft doesn't have any mapping between these blocks and their custom items, as far as its concerned they're completely unrelated. It only maintains a mapping for blocks that use a standard

ItemBlock

.

 

There are two ways you can create this mapping:

• Hardcode the vanilla block-placing

  Item

  s (that don't extend

  ItemBlock

  ) and their corresponding

  Block

  
  

• Iterate through the item registry, find any instances of

  ItemBlockSpecial

  /

  ItemReed

  and extract their

  Block

  
  

 

The first way will obviously only work for vanilla blocks.

 

The second way will work for any vanilla and modded blocks that use

ItemBlockSpecial

, but not ones that use their own unrelated

Item

class (e.g.

Items.sign

, which is an instance of

ItemSign

).

 

This mapping may not be 1:1, it's possible for there to be several

Item

s that place the same

Block

or for a single

Item

to place multiple

Block

s (e.g.

ItemSign

can place

Blocks.standing_sign

or

Blocks.wall_sign

).

So, if I'm understanding correctly, we can always go from Item to Block (or multiple blocks sometimes), and going from Block to Item is usually possible but will sometimes fail?

So, if I'm understanding correctly, we can always go from Item to Block (or multiple blocks sometimes), and going from Block to Item is usually possible but will sometimes fail?

 

For most

Block

s,

Item.getItemFromBlock

and

Block.getBlockFromItem

will convert between the

Block

and its

ItemBlock

.

 

Some

Block

s have a separate

Item

form, but there's no 100% reliable way to convert between these. You can hardcode the vanilla instances and/or check for the vanilla classes, but you can't cover mods that use their own

Item

class.

 

Some

Block

s don't have any

Item

form.

 

Some

Item

s (in fact most of them) don't place a

Block

at all.

And some are weirdly related, like seeds.  Seeds are absolutely not the item form of a block, yet when used they create a block, when that block is middle-clicked, you get a seed, and when the block is broken, you get the seed (usually!)

 

But you can also get seeds from breaking tall grass (which has its own itemblock!)

I see, lots of weird relations indeed. So for something like Block.grass I probably would not have any other option than to hardcode some arbitrary relation, I guess. No big deal but good to know. Thank you guys!

Blocks.grass

uses a standard

ItemBlock

that will be returned from

Item.getItemFromBlock

.

After some exploration around this topic, I'm puzzled with one specific case. Why can't Item.getItemFromBlock(block) work for the door's blocks? Apparently, all of them have their counterparts, like Blocks.acacia_door and Items.acacia_door, so what is wrong with that?

(getPickBlock is probably going to be the more useful option in the general-case)