Draco18s

I don't know because you haven't shown me which direction you're facing in Minecraft.

Well. That second one is the same as your first attempt. The first one there is much closer. You fixed on axis and got the other one wrong. Seriously, not that hard. I can't tell you which axis you need to set to having a different value because your result images don't contain which direction your facing (X positive, Z negative...)

Unless your mod ID is "nlxdodge/universalcache" then your blockstate files all of your assets are in the wrong place. $10 says your mod ID is "universalcache" and that you've added an extra subdirectory you don't need.

Do you still have a problem? If so, what is it?

Or get a logger from the FML events: public static final Logger logger; preInit(FMLPreInitializationEvent event) { logger = event.getModLog(); }

That's because the origin point for all blocks in Minecraft isn't the center of the block, its the corner. You notice how you have it correctly aligned on the Y axis (in your modeling program the bottom edge of the cube is at Y0)? Do the same thing for the X and Z.

You didn't specify an inventory variant in your blockstate file.

You need a TileEntity in order to store more than 4 bits of data.

You need to create a json model resource which refers to the texture.

bool1 | bool2 << 1 | bool3 << 2 | bool4 << 3

No. You need a json file in the blockstates folder that is named "red_ribbon_present.json" and it contains a variant named "color" with a valie of "black." "variants": { "color": { "black: { "textures": { ... } } } } The "..." here is where you tell the game where to find the new texture to use. You can name it whatever you want.

Metadata. And it really isn't that hard: 1) Override BlockStateContainer : This is where you define what properties your block has @Override protected BlockStateContainer createBlockState() { //These properties can be whatever, here you can see a custom one and a Directional return new BlockStateContainer(this, new IProperty[] {Props.AXEL_ORIENTATION, BlockHorizontal.FACING}); } 2) Override getStateFromMeta and getMetaFromState : This is how you tell your block to convert between States/Properties and metadata (you're still limited to 4 bits) @Override public int getMetaFromState(IBlockState state) { int axel = state.getValue(Props.AXEL_ORIENTATION).getOrdinal()<<2; int face = state.getValue(BlockHorizontal.FACING).getIndex() - 2; //bitwise magic to not make UP and DOWN take up an extra bit //I actually get 'UP' back in the axel orientation property, because it would be mutually exclusive //with the other values,and I don't need 'DOWN' if(face < 0) face = 0; return axel | face; } @Override public IBlockState getStateFromMeta(int meta) { int face = (meta & 3) + 2; //reverse bitwise magic return this.getDefaultState().withProperty(Props.AXEL_ORIENTATION, Props.AxelOrientation.values()[meta>>2]).withProperty(BlockHorizontal.FACING, EnumFacing.VALUES[face]); } 3) Create a variants file. Look how I even handle two different variants: { "forge_marker": 1, "defaults": { "textures": { "particle": "blocks/log_oak" }, "model": "harderores:axel", "uvlock": true }, "variants": { "normal": [{ }], "inventory": [{ }], "axel_orientation": { "none": { }, "gears": { "model": "harderores:frame" }, "hub": { }, "up": { "x": 270 } }, "facing": { "north": { "y": 0 }, "east": { "y": 90 }, "south": { "y": 180 }, "west": { "y": 270 } } } }

TheThingYouSeeOnScreen=TheThingYouWantToSee Really, is it that hard?

Go look at any of the Minecraft blocks that have a directional facing or are colored (e.g. wool, carpets)

Yes. You'll have to lookup how to do fullbright yourself (that's what it's called, but Mojang decided to use the keyword "shade" or "shading" or somesuch nonsense in the json files) but two layers is easy. Here's a block I did: Model: { "parent": "block/block", "elements": [ { "from": [ 0, 0, 0 ], "to": [ 16, 16, 16 ], "faces": { "down": { "uv": [ 0, 0, 16, 16 ], "texture": "#all", "cullface": "down" }, "up": { "uv": [ 0, 0, 16, 16 ], "texture": "#all", "cullface": "up" }, "north": { "uv": [ 0, 0, 16, 16 ], "texture": "#all", "cullface": "north" }, "south": { "uv": [ 0, 0, 16, 16 ], "texture": "#all", "cullface": "south" }, "west": { "uv": [ 0, 0, 16, 16 ], "texture": "#all", "cullface": "west" }, "east": { "uv": [ 0, 0, 16, 16 ], "texture": "#all", "cullface": "east" } } }, { "from": [ 0, 0, 0 ], "to": [ 16, 16, 16 ], "faces": { "down": { "uv": [ 0, 0, 16, 16 ], "texture": "#overlay", "cullface": "down" }, "up": { "uv": [ 0, 0, 16, 16 ], "texture": "#overlay", "cullface": "up" }, "north": { "uv": [ 0, 0, 16, 16 ], "texture": "#overlay", "cullface": "north" }, "south": { "uv": [ 0, 0, 16, 16 ], "texture": "#overlay", "cullface": "south" }, "west": { "uv": [ 0, 0, 16, 16 ], "texture": "#overlay", "cullface": "west" }, "east": { "uv": [ 0, 0, 16, 16 ], "texture": "#overlay", "cullface": "east" } } } ] }

Something something something update to the new BlockState methods so this won't happen again.

In 1.10 the method is called "getLightFor(EnumSkyBlock, BlockPos)" (that's the environemtn I have open at the moment). I can't recall the 1.7.10 name off the top of my head ("getSavedLightValue?"), but it's named pretty similarly and takes an EnumSkyBlock parameter (which has two values: BLOCK meaning torches, etc. and SKY meaning the sun). It doesn't check day/night (that's "getSkylightSubtracted"). But yeah, any "cave" location is going to have 0 sunlight.

public static Item Red_Dyed_Water_Bottle; Oh good! We have a spot in memory for an Item ! It is currently null. ^..^ public void preinit(FMLPreInitializationEvent event) { Ooh! This got called! Yay! CRSoda.register(Red_Dyed_Water_Bottle); Lets register an item! GameRegistry.register(i.setUnlocalizedName(i.getRegistryName().toString())); OH GOD, THE ITEM WAS NULL! D: The code never gets here: CRSoda.init(); Red_Dyed_Water_Bottle = new Item_Red_Dyed_Water_Bottle().setRegistryName(CRSoda.MODID, "Red Dyed Water Bottle");

Was your first thread insufficient?

Your blockstate json file is misnamed. It should be "cropTomato.json" Also: Don't use GameRegistry.registerBlock, use GameRegistry.register Don't use getUnlocalizedName().substring(5), use .setRegistryName and .getRegistryName Don't use Minecraft.getMinecraft().getRenderItem().getItemModelMesher(), use ModelLoader.setCustomModelResourceLocation Don't use any client side code (the entire ModelMesher, ModelLoader system) in common code, use a proxy or you'll crash the dedicated server Do setUnlocalizedName(getRegistryName), then your block has your modID prefixed to the unlocalized name, preventing conflicts Make sure: That either ModItems either runs after ModBlocks or that your tomato seed doesn't take your tomato crop block as a parameter ModBlocks (and ModItems) have their init() method called during FMLPreInitialization (preInit) not FMLInitialization (init) or nothing will work right (models and such must be registered during preInit)

MDKexample contains inside it, many things. For it is a folder. Inside that folder you will find a list of referenced libraries. One of those is called "forgeSrc-xxx-yyy.jar" (where xxx is a Minecraft version and yyy is a forge version) Inside that is the Minecraft source.

Good job following directions.

That's not the problem: Does the class get loaded at all server side? If yes, you can't use Minecraft.getMinecraft at all, ever, zero nadda, zip zilch.

http://mcforge.readthedocs.io/en/latest/blockstates/forgeBlockstates/#sub-models