[1.10.2]Understanding Block States

EphraimFE · November 23, 2016

I'm trying to create a copy of stone bricks with a slightly different texture and some different properties. I'd like them all to be in a single class within my ModBlocks package, BlockAncStoneBrick. One form of the block is MOSSY which can either be true or false. Later on, I would have chiseled blocks but unlike vanilla's stone brick I can have chiseled mossy blocks. My plan is to have one blockstate that can read all the different varients. I've looked at https://mcforge.readthedocs.io/en/latest/blockstates/forgeBlockstates/ but I can't get it to work. I 'm getting purple and black blocks.

My Blocks class:

package eph.fe.blocks;

import eph.fe.Main;
import eph.fe.Reference;
import net.minecraft.block.Block;
import net.minecraft.block.BlockStoneBrick;
import net.minecraft.block.material.Material;
import net.minecraft.block.properties.IProperty;
import net.minecraft.block.properties.PropertyBool;
import net.minecraft.block.properties.PropertyDirection;
import net.minecraft.block.properties.PropertyEnum;
import net.minecraft.block.properties.PropertyInteger;
import net.minecraft.block.state.BlockStateContainer;
import net.minecraft.block.state.IBlockState;
import net.minecraft.util.EnumFacing;
import net.minecraft.util.IStringSerializable;
import net.minecraft.world.storage.loot.functions.SetMetadata;

public class BlockAncStoneBrick extends Block {
    public static final PropertyBool MOSSY = PropertyBool.create("mossy");
    
public BlockAncStoneBrick() {
	super(Material.ROCK);
	setUnlocalizedName(Reference.feBlocks.ANCSTONEBRICK.getUnlocalizedName());
	setRegistryName(Reference.feBlocks.ANCSTONEBRICK.getRegistryName());
	setCreativeTab(Main.ANCIENT_TAB);
	setDefaultState(this.blockState.getBaseState().withProperty(MOSSY, false));

}

@Override
protected BlockStateContainer createBlockState() {
	return new BlockStateContainer(this, MOSSY);
}

@Override
public int getMetaFromState(IBlockState state) {
	int i = 0;
	if (state.getValue(MOSSY) == true)
        	i++;
        return i;
}

@Override
public IBlockState getStateFromMeta(int meta) {
	if (meta % 2 == 0)
		return getDefaultState().withProperty(MOSSY, true);
	else
		return getDefaultState().withProperty(MOSSY, false);
}

}

Blockstate

{
    "forge_marker": 1,
    "defaults": {
        "textures": {
            "texture": "fe:blocks/anc_stone_brick_def"
        },
        "model": "fe:ancStoneBrick",
        "uvlock": true
    },
    "variants": {
        "mossy": {
            "true": {
                "textures": {
                    "texture": "fe:blocks/anc_stone_brick_moss"
                }
            },
            "false": {
            }
        }
    }
}

Model

{
    //"parent": "block/cube_all" <--whether this is here or not error persists
    "textures": {
        "all": "#texture"
    }
}

If I had to guess, I'd say there was something wrong with my model json. The documentation I had didn't mention anything about the model json (just the blockstate) so I tried to copy the pressure plate one. Anyone know what's up?[/code]

TheGreyGhost · November 23, 2016

Hi

Does the console show any missing texture errors or similar?

-TGG

EphraimFE · November 23, 2016

On 11/23/2016 at 12:26 AM, TheGreyGhost said:

Hi

Does the console show any missing texture errors or similar?

-TGG

Whenever the resources are reloaded:

[18:28:54] [Client thread/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[18:28:54] [Client thread/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[18:28:54] [Client thread/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[18:28:54] [Client thread/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[18:28:54] [Client thread/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[18:28:54] [Client thread/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[18:28:54] [Client thread/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[18:28:54] [Client thread/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[18:28:54] [Client thread/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[18:28:54] [Client thread/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[18:28:54] [Client thread/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[18:28:54] [Client thread/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[18:28:54] [Client thread/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[18:28:54] [Client thread/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[18:28:54] [Client thread/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[18:28:54] [Client thread/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[18:28:54] [Client thread/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[18:28:54] [Client thread/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[18:28:55] [Client thread/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all

robustus · November 23, 2016

are those two //'s in your code snippet above in the actual file itself??

Draco18s · November 23, 2016

By the way, if your model is that simple, why are you using it? Why not make your blockstate tell the game to use block/cube_all?

TheGreyGhost · November 23, 2016

Hmmm

I'm not so familiar with ForgeBlockStates, but at a guess:

try replacing

        "textures": {
            "texture": "fe:blocks/anc_stone_brick_def"
        },

with

        "textures": {
            "all": "fe:blocks/anc_stone_brick_def"
        },

The method you're using should work; at least it worked for me with vanilla.

Perhaps your model file isn't the one you think it is. i.e.

{
    //"parent": "block/cube_all" <--whether this is here or not error persists
    "textures": {
        "all": "#texture"
    }
}

isn't being properly referred to by your blockstates?

-TGG

EphraimFE · November 23, 2016

On 11/23/2016 at 6:24 AM, TheGreyGhost said:

Hmmm

I'm not so familiar with ForgeBlockStates, but at a guess:

try replacing

<snip>

with

<snip>

The method you're using should work; at least it worked for me with vanilla.

Perhaps your model file isn't the one you think it is. i.e.

<snip>

isn't being properly referred to by your blockstates?

-TGG

I tried it, still didnt work. Heres an example of the model using this (I think), pressure_plate_up

{   "parent": "block/thin_block",
    "textures": {
        "particle": "#texture"
    },
    "elements": [
        {   "from": [ 1, 0, 1 ],
            "to": [ 15, 1, 15 ],
            "faces": {
                "down":  { "uv": [ 1,  1, 15, 15 ], "texture": "#texture", "cullface": "down" },
                "up":    { "uv": [ 1,  1, 15, 15 ], "texture": "#texture" },
                "north": { "uv": [ 1, 15, 15, 16 ], "texture": "#texture" },
                "south": { "uv": [ 1, 15, 15, 16 ], "texture": "#texture" },
                "west":  { "uv": [ 1, 15, 15, 16 ], "texture": "#texture" },
                "east":  { "uv": [ 1, 15, 15, 16 ], "texture": "#texture" }
            }
        }
    ]
}

Note I've also tried

{
"parent": "block/cube_all",
    "textures": {
        "all": { "texture": "#texture" }
    }
}

My block's model is named ancBlockStoneBrick in my models directory. Before I started turning this block into a metablock it worked fine and displayed the default stone brick texture.

Quote

By the way, if your model is that simple, why are you using it? Why not make your blockstate tell the game to use block/cube_all?

Eventually I will have stone bricks, mossy stone bricks, mossy chiseled stone bricks, chiseled stone bricks, ornate(or something) stone bricks, mossy ornate stone bricks...etc. Eventually it will be extremely complex and I'd like to keep my blockstate all one file. Additionally, I would like them all to count as BlockAncStoneBricks so I can use them in code equally (say if I require the player to place 5 stone bricks - every variant should count which is why I'm using meta). Its also a good learning experience.

Quote

are those two //'s in your code snippet above in the actual file itself??

Nope, just in the code i posted

Animefan8888 · November 23, 2016

On 11/23/2016 at 7:38 AM, EphraimFE said:

Quote

By the way, if your model is that simple, why are you using it? Why not make your blockstate tell the game to use block/cube_all?

Eventually I will have stone bricks, mossy stone bricks, mossy chiseled stone bricks, chiseled stone bricks, ornate(or something) stone bricks, mossy ornate stone bricks...etc. Eventually it will be extremely complex and I'd like to keep my blockstate all one file. Additionally, I would like them all to count as BlockAncStoneBricks so I can use them in code equally (say if I require the player to place 5 stone bricks - every variant should count which is why I'm using meta). Its also a good learning experience.

What he means is why don't you just assign the model to the block in the blockstate to "block/cube_all" and then apply the texture using the "textures" tag like so.

"connected_down=true,connected_east=true,connected_north=true,connected_south=true,connected_up=true,connected_west=false":{
	"model": "cube_all",
	"textures": {
		"west": "westFacingTexture" //just use "all": "texturepath"
	}
}

Don't mind the insane amount of variants (connected textures done with a forge blockstate json).

Leviathan143 · November 23, 2016

Do you plan for all variants of this block to have the same texture on all sides?

You should also note that Blocks can only store 16 states in metadata(4 bits). That's 4 boolean properties max.

Draco18s · November 23, 2016

Oh I know what's wrong.

On 11/23/2016 at 7:38 AM, EphraimFE said:

{   "parent": "block/thin_block",
    "textures": {
        "particle": "#texture"
    },
    "elements": [
        {   "from": [ 1, 0, 1 ],
            "to": [ 15, 1, 15 ],
            "faces": {
                "down":  { "uv": [ 1,  1, 15, 15 ], "texture": "#texture", "cullface": "down" },
                "up":    { "uv": [ 1,  1, 15, 15 ], "texture": "#texture" },
                "north": { "uv": [ 1, 15, 15, 16 ], "texture": "#texture" },
                "south": { "uv": [ 1, 15, 15, 16 ], "texture": "#texture" },
                "west":  { "uv": [ 1, 15, 15, 16 ], "texture": "#texture" },
                "east":  { "uv": [ 1, 15, 15, 16 ], "texture": "#texture" }
            }
        }
    ]
}

Ok, so by specifing the parent as cube_all there needs to be a final non-reference value for "#all" but what you specified is this:

"all": { "texture": "#texture" }

"#all" now points to "#texture" and "#texture" points to.......nothing.

Unable to resolve reference.

robustus · November 23, 2016

On 11/23/2016 at 8:03 AM, Leviathan143 said:

Do you plan for all variants of this block to have the same texture on all sides?

You should also note that Blocks can only store 16 states in metadata(4 bits). That's 4 boolean properties max.

is there any way around this? I'm totally rewriting my mod from scratch to update to the current version. In pre 1.8 I was able to change a few textures based on conditions that didn't need metadata set, like biome, altitude etc...

Draco18s · November 23, 2016

On 11/23/2016 at 6:11 PM, robustus said:

is there any way around this? I'm totally rewriting my mod from scratch to update to the current version. In pre 1.8 I was able to change a few textures based on conditions that didn't need metadata set, like biome, altitude etc...

getActualState

Check out how vanilla walls work.

EphraimFE · November 23, 2016

On 11/23/2016 at 8:03 AM, Animefan8888 said:
Quote

Quote

By the way, if your model is that simple, why are you using it? Why not make your blockstate tell the game to use block/cube_all?

Eventually I will have stone bricks, mossy stone bricks, mossy chiseled stone bricks, chiseled stone bricks, ornate(or something) stone bricks, mossy ornate stone bricks...etc. Eventually it will be extremely complex and I'd like to keep my blockstate all one file. Additionally, I would like them all to count as BlockAncStoneBricks so I can use them in code equally (say if I require the player to place 5 stone bricks - every variant should count which is why I'm using meta). Its also a good learning experience.

What he means is why don't you just assign the model to the block in the blockstate to "block/cube_all" and then apply the texture using the "textures" tag like so.
"connected_down=true,connected_east=true,connected_north=true,connected_south=true,connected_up=true,connected_west=false":{
	"model": "cube_all",
	"textures": {
		"west": "westFacingTexture" //just use "all": "texturepath"
	}
}
Don't mind the insane amount of variants (connected textures done with a forge blockstate json).

Oh I gotcha, that's brilliant I don't know why I didn't think about that.

{
    "forge_marker": 1,
    "defaults": {
        "textures": {
            "all": "fe:blocks/anc_stone_brick_def"
        },
        "model": "block/cube_all",
    },
    "variants": {
        "mossy": {
            "true": {
                "textures": {
                    "all": "fe:blocks/anc_stone_brick_moss"
                }
            },
            "false": {

            }
        }
    }
}

With these changes, I get more errors, however.

[16:00:36] [Client thread/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[16:00:37] [Client thread/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[16:00:37] [Client thread/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[16:00:37] [Client thread/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[16:00:37] [Client thread/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all
[16:00:37] [Client thread/ERROR] [FML]: Exception loading model for variant fe:BlockAncStoneBrick#mossy=false for blockstate "fe:BlockAncStoneBrick[mossy=false]"
net.minecraftforge.client.model.ModelLoaderRegistry$LoaderException: Exception loading model fe:BlockAncStoneBrick#mossy=false with loader VariantLoader.INSTANCE, skipping

EphraimFE · November 23, 2016

Got it!

{
    "forge_marker": 1,
    "defaults": {
        "textures": {
            "all": "fe:blocks/anc_stone_brick_def"
        },
        "model": "cube_all",
        "uvlock": true
    },
    "variants": {
        // mossy is a boolean property.
        "mossy": {
            "true": {
                "textures": {
                    "all": "fe:blocks/anc_stone_brick_mossy"
                }
            },
            "false": {
            }
        }
}
}

This issue was, if you can believe it, an extra comma when I removed uvlock...whoops...

Thanks guys.

Sign In

[1.10.2]Understanding Block States

Recommended Posts

EphraimFE

TheGreyGhost

EphraimFE

robustus

Draco18s

TheGreyGhost

EphraimFE

Animefan8888

Leviathan143

Draco18s

robustus

Draco18s

EphraimFE

EphraimFE

Join the conversation

Announcements

Recently Browsing

Posts

Topics

Who's Online (See full list)

Browse

Activity

Important Information