Draco18s

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

BiomeGenBase -> Biome (based on my having just looked it up for unrelated reasons)

Crafty.

It does, getSlots . ....How in the hell did I overlook that. I think that entirely depends on how the block handles its inventory. For example, if I have a block like the furnace which I want to have sided access I need to return a different capability depending on the side (or the possibility of inputting to the output slot exists). Ergo: inputSlot = new ItemStackHandler(1); outputSlot = new ItemStackHandler(1); How would I then go about returning both in the case of a null side?

You don't have to. Every ID is unique to the mod, and every mod has their own set of unqiue IDs that will NEVER clash.

Feels like a bit of an oversight that the ItemStackHandler class doesn't have a "how many slots do you have" method, especially considering that it throws a runtime exception if you try to access a slot outside its size. On top of that, there doesn't appear to be a suggested way for a block to tell its own TE to drop all of its contents without performing a cast from TileEntity to something else (either its own TE type or custom interface) as there's no ability to be certain (using generic code) to determine that "yes, I've accessed every ItemStackHandler capability the tile can provide." I mean, I'm fine creating my own helper interface that I apply to my TEs so I can just do this: public void breakBlock(World worldIn, BlockPos pos, IBlockState state) { TileEntity tileentity = worldIn.getTileEntity(pos); if (tileentity instanceof IInvenCapHelper) { ((IInvenCapHelper)tileentity).dropAllItems(worldIn, pos); } super.breakBlock(worldIn, pos, state); } And then manually looping through all the slots my TE knows it has for all of its ItemStackHandler instances: @Override public void dropAllItems(World worldIn, BlockPos pos) { ItemStack stack; //magic number `n` because ItemStackHandler does not have a .getSize() for(int i=0; i < n; i++) { stack = inputSlots.getStackInSlot(i); EntityItem entityIn; if(stack != null) { entityIn = new EntityItem(worldIn, pos.getX(), pos.getY(), pos.getZ(), stack); entityIn.setDefaultPickupDelay(); worldIn.spawnEntityInWorld(entityIn); } } //repeat for outputSlots and any other ItemStackHandler instances } Or am I missing something?