Draco18s

Probably the same way as CoFH. Using the LivingAttackEvent.

Except that I don't think other player's inventories are synced to your client.

You also need: @Override public boolean isOpaqueCube(IBlockState state) { return false; }

Go look at BlockCrops.

You will need to create your own property. It's not hard. As in, you could literally copy-paste it and change one number. Move it out of your blocks class and into your client proxy.

If your IDE told you to remove the override annotation then actually, there is a problem. And it's not with the annotation. It's with the method signature.

Why do you not have methods marked with @Override?

Function? You mean init and postInit? Those methods have been around since forever. If you mean Items.REGISTRY (which is a field) I don't know when it was added.

Items may still be being created by mods (that load after yours) during preInit, but after preInit (init, postInit, during game) the registries are finalized and cannot be modified. So yes.

Not entirely true. As items/blocks/etc can only be registered during PreInit, then any point after that will see every item that exists, regardless of mod load order.

It is not. When a chunk is generated fresh, it gets saved, regardless of if anything changed or not.

Look at Items.REGISTRY

And now I'm reminded of a time when I poked around with a Microsoft HTML tool that was so buggy I had website images displaying inside the program's UI (completely breaking it).

Personal preference, though users of one will generally espouse some feature that makes their IDE better.

ShadowFacts has one. He does some things that make me twitch (such as having his Item or Block class contain the rendering registration code...) but it is up to date. There's also Forge's own docs, although in some respects it doesn't have everything.

Not to mention other things that work fine for him, but which are unnecessary and make it more difficult for new modders to efficiently understand what's going on, and when asking for help, able to quickly supply the code more experienced folks want to look at. For example, if I asked you to post your main mod class so I could look at your mod lifecycle events (to see when and how you are registering your items, recipes, and renderers) would I find that information, or would there just be a proxy.preInit(ev), ModBlocks.preInit(ev) or similar line making me have to ask for that class too?

Probably because the item is still being given to the inventory as 0/4/8/12 but you registered an item renderer for a different metadata value. i.e. this chunk: @SideOnly(Side.CLIENT) public void getSubBlocks(Item itemIn, CreativeTabs tab, List<ItemStack> list) { // item , amount, meta list.add(new ItemStack(itemIn)); list.add(new ItemStack(itemIn, 1, 4)); list.add(new ItemStack(itemIn, 1, 8)); list.add(new ItemStack(itemIn, 1, 12)); } If you're going to change your metadata values in one place, you need to change them in the other. THIS IS IMPORTANT, IT IS NOT ARBITRARY. Most importantly, you need to use the metadata values that your block actually drops when broken. If it exists in your inventory, then you have an item. item = new ItemMultiTexture(tudorSet, tudorSet, ModBlockTudorSet.subTypes; Surprise, there it is. In order to override the unlocalized name you need a custom ItemBlock class. Surprise! Alternatively, pass a name function to the ItemMultiTexture's constructor. E.g. here is how vanilla handles the stone variants: registerItemBlock(Blocks.STONE, (new ItemMultiTexture(Blocks.STONE, Blocks.STONE, new Function<ItemStack, String>() { @Nullable public String apply(@Nullable ItemStack p_apply_1_) { return BlockStone.EnumType.byMetadata(p_apply_1_.getMetadata()).getUnlocalizedName(); } })).setUnlocalizedName("stone"));

You need to register an entity renderer. Try this thread:

Again, that method is only used for populating the Creative inventory. Name: you need to override the getUnlocalizedName method in your item in order to supply a name that can be localized. Meta: I don't understand your question I am not sure what you want to know here

Try setting the opacity as white, but at 1% opaque. When rendering transparency as transparent, Minecraft ignores transparency values below about 10%.

That's the list of all renames. Its not terribly well organized, but it is the list.

https://github.com/ModCoderPack/MCPBot-Issues/issues

It's not a Forge issue. But yeah, try starting over from scratch and use the Forge blockstate format. It's a lot nicer.

I don't know then. Because they look fine to me and I've never had that particular error crop up when there wasn't something obviously wrong.

It's a thing that vanilla did in 1.10 and Forge never supplied a good default (or never altered the method to supply a good default, I'm not sure which). The default method is "replace the TE if the TE is not a vanilla TE" which is pretty much worthless. Are there TEs that should refresh when the blockstate changes? Probably. Is it the vast majority? No.