Choonster

There should be some errors in the log telling you what went wrong. The Grey Ghost has a guide to troubleshooting block and item rendering here.

Yes. I'd recommend creating a separate class each for your blocks and items and using those classes to instantiate, register and store your Block / Item instances. You can see an example of what I'm talking about here. You should keep the registration out of the constructor, that way you can more easily use the same class for multiple block/item types.

You've created a recipe for an ItemStack with a null Item . This is because you've registered your recipes before instantiating and registering your blocks. You should instantiate and register your items and blocks in preInit (don't instantiate them in field initialisers) and then add recipes in init.

Forge's Blockstates format can reduce the number of individual models you need to write.

RenderingRegistry.addNewArmourRendererPrefix is an alternative to overriding Item#getArmorTexture . You can call it with the prefix of your textures and pass the returned int to the ItemArmor constructor so it's assigned to the ItemArmor#renderIndex field, the prefix will then be used for your item's armour texture. Look at RenderBiped.getArmorResource to see how it's used. I didn't know about this beforehand, I just used my IDE to look at the source of RenderingRegistry.addNewArmourRendererPrefix and find usages of the array it populates. You're better off overriding Item#getArmorTexture instead of using RenderingRegistry.addNewArmourRendererPrefix , since the former allows you to specify the resource domain of your textures instead of requiring them to be in the minecraft domain.

You're calling a method ( RenderingRegistry.addNewArmourRendererPrefix ) that references a client-only class ( RenderBiped ) on the server. All rendering-related stuff should only be registered from your client proxy, that way it's only called on the client. In your base proxy type, create a method called something like init or registerRenderers (the name doesn't really matter) and then override it in your client proxy to call RenderingRegistry.addNewArmourRendererPrefix and any other client-only stuff that should be called in the same phase. Call this method on your proxy instance from your FMLInitializationEvent method (i.e. MainRegistry.load ).

To get the source code from a built mod, you'll have to use BON or BON2 to deobfuscate the mod and then use a Java decompiler to decompile it into source code. I list some decompilers and explain how to use BON in this thread. Keep in mind that most closed source licenses don't allow you to use the code in your own mod.

You've done something wrong. Post the latest versions of the ItemHSteelHelmet and HSteelArmor classes. Every item class must directly or indirectly extend Item . The inheritance chain for your armour classes should be something like ItemHSteelHelmet -> HSteelArmor -> ItemArmor -> Item (where -> means "extends from").

There are two types of events in Forge: Events that extend FMLEvent and are handled by a method with the @Mod.EventHandler annotation in your @Mod class (e.g. FMLPreInitializationEvent , FMLMissingMappingsEvent ) Events that extend Event and are handled by a method with the @SubscribeEvent annotation in a class registered on the appropriate event bus (e.g. BlockEvent.HarvestDropsEvent , PlayerEvent.ItemSmeltedEvent ) You're trying to handle an FMLEvent like it's an Event .

ItemHSteelHelmet , etc. should extend HSteelArmor instead of extending ItemArmor . This is what diesieben07 is telling you. If you look at line 236 of CraftingManager , you'll see that it's calling ItemStack#copy on the result of HashMap#get (the HashMap maps each character to its corresponding ingredient ItemStack ); get is returning null , causing the exception. This means that you passed null as an ingredient to GameRegistry.addRecipe on line 124 of MainRegistry . You should instantiate and register your items/blocks in preInit and add recipes in init. You shouldn't be doing anything in the constructor of your main class.

If you look at the usages of the playerLocation field you'll see it's only used for sleeping, it's not usually set to the player's current position. To get an Entity 's position as a BlockPos , use Entity#getPosition or the BlockPos(Entity) constructor.

setTextureName is the deobfuscated (MCP) name of the method, which is only used in the development environment. In the normal client, it has an obfuscated (SRG) name instead. You need to build your mod using the build Gradle task (either from the command line or IDEA's Gradle window), this compiles and reobfuscates the mod so it uses SRG names instead of MCP names. The built mod will be in the build/libs folder of your project.

Custom Main Menu is the mod causing the crash. Mods will usually say on their download page if they're client-only.

The blockstates JSON is parsed in BlockStateLoader.load .

Override Item#getContainerItem(ItemStack) to return the appropriate ItemStack (just return the argument if the item should remain unchanged) instead of calling Item#setContainerItem . By the way, use [ code ] [ /code ] tags (without the spaces) for code. You can also use a site like Gist or Pastebin to post code with syntax highlighting.

For a standard Block , using Material.water as the block's material will make it render with water around it while in water. I can't find the part of the rendering engine that handles this, so I'm not sure if it still applies to models rendered using TESR . You don't need to extend BlockContainer to have a TileEntity , just override Block#hasTileEntity and Block#createTileEntity .

Use PlayerEvent.Clone to clone IEEP data from the old instance of a player to the new one after they respawn. You shouldn't need to store the data in any kind of proxy, and there's no point in implementing IGuiHandler unless you're actually using the class as your GUI handler.

No, the models for each stage of the crop should be in assets/if/models/block. Your blockstates file should only use the resource domain and name of each model, don't include the block/ prefix. Look at assets/minecraft/blockstates/wheat.json for an example.

If you look at the method that threw the exception ( ItemSeeds#getPlant , line 61), you'll see it's trying to call getDefaultState on this.crops . The only possible value that could be null on that line is this.crops , which is set from the first argument of the constructor. This means you're passing null to the ItemSeeds constructor, probably because InsaneFoodsInit.init is called before InsaneBlocks.init .

You could probably make an IRecipe that only matched a stack of gold nuggets, but SlotCrafting#onPickupFromSlot specifically decrements the stack in each slot by 1.

The vanilla crafting table only supports recipes that require a single item for each slot, you can't create a recipe that consumes multiple items from a single slot.

You'll want to use [url=http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/1571567-forge-1-6-4-1-8-eventhandler-and]IExtendedEntityProperties[/url] for that.

I believe the InstantiationException is thrown because Handler is a non-static inner class and thus can't be instantiated by itself (I think a constructor that takes an instance of the outer class is generated when the code is compiled, so there's no zero-argument constructor for Class#newInstance to call). Handler should either be a static inner class or a separate class entirely.

Use your IDE's Find Usages/Call Hierarchy feature to look for usages of EntityConstructingEvent and you'll see that it's fired from the Entity constructor. If you look for usages of EntityPlayerMP (the server-side player class), you'll see a new instance is created when a player logs into the server ( ServerConfigurationManager#createPlayerForUser ) or respawns after dying or conquering the End ( ServerConfigurationManager#respawnPlayer ).

This is the case if you're using the vanilla ItemModelMesher#register methods (like the OP is), but Forge's ModelLoader#setCustomModelResourceLocation and ModelLoader.setCustomMeshDefinition methods (which do the same thing as the vanilla methods) need to be called in preInit rather than init.