Choonster

You don't need to use an Iterator to iterate through an Iterable , just use an enhanced for loop. Blocks don't have a single recipe or image. There are many recipes, some of which may output a specified block. Each block can have a model per state, each model can use multiple textures. CraftingManager#getRecipeList returns the recipe list, IRecipe#getRecipeOutput returns the recipe's default output (may be null ). Recipes can change their actual output based on the contents of the crafting grid, so the default output may not be what the player actually gets when they craft it. BlockModelShapes#getModelForState returns the model for the specified block state. IBakedModel#getParticleTexture returns the model's particle texture (could be used as the default texture). IBakedModel#getQuads returns a list of BakedQuad s, BakedQuad#getSprite returns the quad's texture.

The ForgeRegistries class exposes each registry (blocks, items, etc.) as an IForgeRegistry . This extends Iterable , so you can iterate through the registry's values with a for-each/enhanced for loop. You can also use IForgeRegistry#getEntries to get the entries (keys and values).

I have a working loot table here.

I suggest looking at the dragon's code. When the dragon is dying, it spawns EXPLOSION_LARGE and EXPLOSION_HUGE particles (from EntityDragon#onDeathUpdate , EntityDragon#onLivingUpdate and PhaseDying#doClientRenderEffects ), these are the grey and black particles. The purple and white beams are rendered by LayerEnderDragonDeath .

Each loot pool (object in the "pools" array) must have a "name" field containing the name of the pool. This must be unique within the loot table, but not globally unique. This requirement was added by Forge as part of the LootTable interaction system.

Mods are already resource packs, you can build your project in your IDE and then reload resources in-game any time you add/change a resource. There are no thirdperson or firstperson display transformations in 1.9+ (they were split into left/right hand), so your iron_sword model is using the transformations specified by your handheld model. Minecraft will automatically load a model for each Item , but it won't actually use that model unless you tell it to by calling ModelLoader.setCustomModelResourceLocation / setCustomMeshDefinition in preInit (only on the client side). If that's not the issue, upload your FML log (logs/fml-client-latest.log) to Gist and link it here. It should tell you what went wrong.

Your blockstates file must include every possible variant of the block, i.e. every combination of property values. Your pressure plate has a single property called powered with two possible values ( true and false ), so you need a variant called powered=false and one called powered=true . This page introduces blockstates files.

You must register Biome s using GameRegistry.register in preInit, just like every other IForgeRegistryEntry implementation.

You must register Biome s using GameRegistry.register in preInit, just like every other IForgeRegistryEntry implementation.

Use TileEntityLockableLoot#setLootTable (inherited by TileEntityChest ) to set the loot table and seed used to generate loot when the chest is first opened. Minecraft stores the ResourceLocation s of its loot tables in LootTableList .

Use TileEntityLockableLoot#setLootTable (inherited by TileEntityChest ) to set the loot table and seed used to generate loot when the chest is first opened. Minecraft stores the ResourceLocation s of its loot tables in LootTableList .

A NullPointerException means you tried to call a method on or access a field of a null value. The only thing that could be null on line 101 of InfusionMachine is Magijern.infusion_machine_lit . Side note: I'd recommend using a single Block with a boolean property called something like LIT , there's no reason to have a separate Block for each state.

A NullPointerException means you tried to call a method on or access a field of a null value. The only thing that could be null on line 101 of InfusionMachine is Magijern.infusion_machine_lit . Side note: I'd recommend using a single Block with a boolean property called something like LIT , there's no reason to have a separate Block for each state.

The indexes of ArmorMaterial#damageReductionAmountArray were reversed in 1.9. In 1.8.9, it was {head, chest, legs, feet} ; in 1.9+ it's {feet, legs, chest, head} .

The indexes of ArmorMaterial#damageReductionAmountArray were reversed in 1.9. In 1.8.9, it was {head, chest, legs, feet} ; in 1.9+ it's {feet, legs, chest, head} .

You need to remove the existing modifiers added by ItemSword from the Multimap before adding your own. You can see how I do this here.

You need to remove the existing modifiers added by ItemSword from the Multimap before adding your own. You can see how I do this here.

Ah, my version of the method takes an IBlockAccess argument. I can't see any obvious issues. I suggest you step through the code in a debugger.

Ah, my version of the method takes an IBlockAccess argument. I can't see any obvious issues. I suggest you step through the code in a debugger.

eAngelusCards#onItemUse (called when the item is right clicked on a block) tries to instantiate one of the card Item s using a constructor that takes a World argument, but O_card_Fire doesn't have this constructor. It also never calls a method on this new instance. eAngelusCards doesn't override Item#onPlayerStoppedUsing , so it does nothing when the player stops using it. It also has several override methods without @Override , you should always use this annotation so the compiler ensures that the methods actually override a super method. That said, your design is a mess. You shouldn't be creating Item s on the fly or using Item s that haven't been registered. What you should do is create a Card class with all the necessary methods and then have each card type extend this and override the appropriate methods to implement their functionality. You should then have a single card Item that stores an instance of each card type and overrides various Item methods to call the corresponding Card method. If you wanted to make this system more extendable, you could create a registry for Card s using Forge's registry system ( IForgeRegistry / IForgeRegistryEntry ) and store the card type in either the NBT (as its registry name) or in a Capability of the ItemStack . Edit: Fixed the formatting.

eAngelusCards#onItemUse (called when the item is right clicked on a block) tries to instantiate one of the card Item s using a constructor that takes a World argument, but O_card_Fire doesn't have this constructor. It also never calls a method on this new instance. eAngelusCards doesn't override Item#onPlayerStoppedUsing , so it does nothing when the player stops using it. It also has several override methods without @Override , you should always use this annotation so the compiler ensures that the methods actually override a super method. That said, your design is a mess. You shouldn't be creating Item s on the fly or using Item s that haven't been registered. What you should do is create a Card class with all the necessary methods and then have each card type extend this and override the appropriate methods to implement their functionality. You should then have a single card Item that stores an instance of each card type and overrides various Item methods to call the corresponding Card method. If you wanted to make this system more extendable, you could create a registry for Card s using Forge's registry system ( IForgeRegistry / IForgeRegistryEntry ) and store the card type in either the NBT (as its registry name) or in a Capability of the ItemStack . Edit: Fixed the formatting.

getTileEntity is a method from the BlockTileEntity class extended by BlockModChest , it's not a vanilla method. It is just a wrapper around World#getTileEntity though. BlockRedChest has a copy of this method, did it not work? That doesn't tell me much. What actually happens? Side note: BlockRedChest#removedByPlayer is missing the @Override annotation, I suggest you add it so the compiler ensures that it actually is an override method.

getTileEntity is a method from the BlockTileEntity class extended by BlockModChest , it's not a vanilla method. It is just a wrapper around World#getTileEntity though. BlockRedChest has a copy of this method, did it not work? That doesn't tell me much. What actually happens? Side note: BlockRedChest#removedByPlayer is missing the @Override annotation, I suggest you add it so the compiler ensures that it actually is an override method.

Post your code and the FML log (preferably using Gist), which should contain some indication as to what's going wrong. You should be using Forge's ModelLoader.setCustomModelResourceLocation (for metadata-based models) or ModelLoader.setCustomMeshDefinition (for arbitrary ItemStack to ModelResourceLocation mappings) methods in preInit rather than ItemModelMesher#register in init.

Post your code and the FML log (preferably using Gist), which should contain some indication as to what's going wrong. You should be using Forge's ModelLoader.setCustomModelResourceLocation (for metadata-based models) or ModelLoader.setCustomMeshDefinition (for arbitrary ItemStack to ModelResourceLocation mappings) methods in preInit rather than ItemModelMesher#register in init.