[1.8] have different unlocalized names for different blockstates, yet same block

[sigurd4]

like with stone, graphite, andesite etc.

i found the code that does it in vanilla in net.minecraft.item.Item.registerItems(). it seems to be in the registration of the item of the block that you can choose to use a different unlocalized name based on itemstack, which again makes it possible to check for blockstate properties.

        registerItemBlock(Blocks.stone, (new ItemMultiTexture(Blocks.stone, Blocks.stone, new Function()
        {
            private static final String __OBFID = "CL_00002178";
            public String apply(ItemStack stack)
            {
                return BlockStone.EnumType.byMetadata(stack.getMetadata()).getUnlocalizedName();
            }
            public Object apply(Object p_apply_1_)
            {
                return this.apply((ItemStack)p_apply_1_);
            }
        })).setUnlocalizedName("stone"));

however, this is impossible to do this way since forge's block registration thing seemingly won't allow this (i've looked in net.minecraftforge.fml.common.registry.GameRegistry). i might just be bad at searching, but i seriously have no idea what to do. or is there a much simpler way that i've overlooked?

[coolAlias]

If your block variants, you need to add each one to the ModelBakery using the unlocalized name by which you plan to retrieve it.

 

Then, make a custom ItemBlock to return the correct unlocalized names for each damage value, or set up your names to use a standardized format that can take advantage of the naming function from ItemMultiTexture, e.g. either using your Block's EnumType or as 'tile.your_block_base_unlocalized_name.specific_type'.

[Ernio]

Literally this:

https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe03_block_variants

[jabelar]

I think the first thing to ask is whether you really want to control variants using block states at all, versus just creating different custom blocks for each type (they can all extend a common type to share most of their code). While block states aren't that hard, it means that you need to process them in many cases (for the models, for the drops, for any other difference in behavior).

 

I personally would suggest using block states mostly for things that can actually change during the game (i.e. an actual "state"). If it will always stay the same for that block during the game, I would suggest that it may be easier to manage them as separate extended classes. For example, if I were making wooden chairs I might make a BlockChair class and then extend it into BlockChairAcacia, BlockChairOak, etc. For those latter classes, you'd only have a little bit of code to write. Since an acacia chair never turns into an oak chair, I personally think it is more logical to do it this way, it saves metadata space for other needed block state information, and probably will lead to less bugs for beginning programmers.

 

But if you're confident in your understanding of block states and metadata you can certainly do it that way too. To further explain the general idea, you need to understand that what you're registering is an instance of the class. So for each instance you can set (either using methods in your class or making a constructor to apply them) the value of the block state. Then you can create all the various instances you want with different block state values, and then just use the GameRegistry.registerBlock() method to assign each unlocalized names.

[sigurd4]

thanks! i've got it now.