Choonster

You can use Block#getBlockState to get the BlockStateContainer of a Block . You can then use BlockStateContainer#getProperties to get the block's properties or BlockStateContainer#getValidStates to get the block's valid states. You can also use Block#getStateFromMeta to get the state represented by a metadata value. Minecraft uses StateMapperBase#getPropertyString to create a variant string from an ordered map of properties and values (e.g. the one returned by IBlockState#getProperties ).

This is an issue with a mod calling itself "Harvest", it's not a Forge issue. Report it to the mod author. In future, post the full FML log.

Put OptiFine in the mods folder and it will be loaded as a Forge mod. Note that OptiFine isn't supported by Forge, so removing OptiFine is one of the first things you'll be asked to do if you encounter any problems while using Forge.

Either add the enchantment to the output ItemStack before you add the recipe (only that recipe will result in the enchanted item and the enchanted item will be displayed as its output) or override Item#onCreated to add the enchantment to the ItemStack argument (the item will be enchanted any time it's crafted, smelted or bought from a villager but the player won't see the enchantment until they've picked up the item from the output slot). Use ItemStack#addEnchantment to add the enchantment. When posting code, please use [nobbc] [/nobbc] tags, upload it to Gist/Pastebin with syntax highlighting or use a repository hosting site like GitHub/BitBucket. 1.7.10 is extremely outdated and no longer supported, you should update to 1.10.2.

Create an instance of StateMap.Builder Call StateMap.Builder#ignore to ignore the properties that don't affect your model Call StateMap.Builder#build to create the IStateMapper Call ModelLoader.setCustomStateMapper to register the IStateMapper for your Block Side note: You should be using ModelLoader.setCustomModelResourceLocation / setCustomMeshDefinition in preInit rather than ItemModelMesher#register in init to register your item models.

Register the IStateMapper in the same class where you register your item models during preInit. I'd recommend doing this in a dedicated client-only class.

Your block has two properties ( stage and type ), neither of which you've specified in your blockstates file. If these properties don't affect the model, you can register an IStateMapper with ModelLoader.setCustomStateMapper . The easiest way to create an IStateMapper is to use StateMap.Builder .

This isn't the case. It's entirely possible to have a Block with no Item form (e.g. air, water and lava) or an Item that isn't a standard ItemBlock (e.g. cake, sugar cane). If a Block has no Item form, it simply can't exist in inventories.

Using block/cross as the model's parent should display the texture in a cross like vanilla saplings. Post your FML log (logs/fml-client-latest.log), it should say exactly what went wrong with the model/texture loading.

Models specified in blockstates files are always relative to assets/<domain>/models/block.

To use the ore_density=7 variant of the assets/harderores/blockstates/hardore.json blockstates file as an item model, use new ModelResourceLocation("harderores:hardore", "ore_density=7") as the location. Either pass this to ModelLoader.setCustomModelResourceLocation or return it from your ItemMeshDefinition and pass it to ModelBakery.registerItemVariants . You can see how I register item models for my blocks with variants (using their blockstates files) here.

More details of the problem and solution are available in the OP's Minecraft Forum thread.

The main changes are: An overhaul of Forge's registry system More singleton classes (e.g. Biome ) having registries instead of arrays with manual IDs Most player interaction methods having an EnumHand parameter and an ActionResult / EnumActionResult return value due to the addition of dual wielding For more detailed changelogs, look the Releases section. I wouldn't recommend updating to 1.9, you should update straight to 1.9.4 or 1.10.2 (which is 99% backwards compatible with 1.9.4).

Your 1.9+ example uses Forge's blockstates format and should work in any version since 1.8.

Use builtin/generated and define the standard display transformations (the "display" block). You may want to create the equivalent of item/generated yourself to act as the parent for your item models.

Gradle caches most of the libraries it downloads and the files that ForgeGradle generates in the .gradle directory. This allows the files to be shared between multiple ForgeGradle workspaces on the same computer.

You have the correct structure there, the paths on that page are actually relative to src/main/resources/assets/<modid>/.

Minecraft encountered an exception of some kind while loading your item models (likely either a FileNotFoundException or a JsonSyntaxException ) and then encountered a FileNotFoundException when it tried to load the blockstates files with the same names (because those files don't exist). Unfortunately 1.8.9 won't tell you what the item model exception was, this was fixed in newer versions. Now that I look at your item models, I see that you're using item/generated as the parent. This model doesn't exist in 1.8.9.

Were you testing this with the integrated (single-player) server or the dedicated server? FMLStateEvent#getSide returns the physical side that the code is running on, i.e. the client or dedicated server. This isn't the same as the logical side, i.e. the client thread or server thread. This page explains sides in more detail. You almost never want to use FMLStateEvent#getSide . Anything that depends on the physical side should be in the appropriate proxy class, anything that depends on the logical side should check World#isRemote .

None of this has changed recently. This page explains where each type of file need to be located.

You don't register a model for the Item in that code snippet, so Minecraft doesn't give it one. You must call ModelLoader.setCustomModelResourceLocation (for metadata to ModelResourceLocation mapping) or ModelLoader.setCustomMeshDefinition (for arbitrary ItemStack to ModelResourceLocation mapping). If you use the latter, you must also tell Minecraft to load all possible ModelResourceLocation s returned by the ItemMeshDefinition by calling ModelBakery.registerItemVariants ; the former does this for you. All of this must be done in preInit from your client proxy (or a class called from it). I have an explanation of the model loading process and how ModelResourceLocation s are mapped to models here.

Is the texture displayed correctly when you place the block in the world? Have you definitely registered a model for the item form (i.e. have you called ModelLoader.setCustomModelResourceLocation / setCustomMeshDefinition )?

Try setting a breakpoint in GenerationHandler#generate , running Minecraft in debug mode and generating new chunks; is the breakpoint hit? Also set a breakpoint in GameRegistry.generateWorld and see if the GenerationHandler instance is in worldGenerators , worldGeneratorIndex and sortedGeneratorList .

Edit the first post and add "[solved]" to the topic title.

Call EntityPlayerSP#sendChatMessage on Minecraft#thePlayer .