Choonster

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.

You should create the ToolMaterial once (probably in the same class where you instantiate and register your items, just before you do that) and then reference it for your tools. Multiple tools can share a ToolMaterial (e.g. all vanilla wooden tools use ToolMaterial.WOOD ). You can also just use an existing ToolMaterial . The Set is the Block s that the tool is effective against, but Forge replaces that with the harvest level system so it's not actually used unless some mod decides to ignore Forge's system and use the vanilla system. Just in case, you should pass an empty Set (just create a new HashSet ) instead of null ; that way the vanilla system won't crash with a NullPointerException .

Extend ItemTool and call setHarvestLevel("someCustomToolClass", toolMaterial.getHarvestLevel()) in the constructor. As long as the ItemTool#toolClass field is null (which it will be if you extend ItemTool directly), getHarvestLevel and getToolClasses will return the result of the super methods (which use the values set by Item#setHarvestLevel ). You can then call Block#setHarvestLevel with the same tool class to allow a block to be harvested by that tool.

Use OreDictionary.getOreIDs to get an array of ore IDs for an ItemStack and OreDictionary.getOreName to get the ore name from an ore ID. See this code for an example.

RegistryNamespaced#getNameForObject will return a ResourceLocation of the object's name (e.g. minecraft:iron_ingot ). Item.itemRegistry contains a reference to the item registry. If you have an ItemStack , you should use ItemStack#getUnlocalizedName to get the item's unlocalised name and ItemStack#getDisplayName to get the item's localised display name. If you only have an Item , use Item#getUnlocalizedName to get the item's unlocalised name and StatCollector.translateToLocal(item.getUnlocalizedName() + ".name") to get the item's localised display name.