Choonster

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.

Skins are downloaded and applied to players asynchronously, so you can't immediately replace the player's skin with your custom skin. When an AbstractClientPlayer is instantiated, it calls SkinManager#func_152790_a . This downloads the the name of the player's skin and cape textures from Mojang's session servers and calls SkinManager#func_152789_a for each one. This downloads the texture in a separate thread (if it hasn't already been downloaded) and then calls SkinManager.SkinAvailableCallback#func_152121_a (implemented by AbstractClientPlayer ) on the next tick to store the ResourceLocation of the texture in the appropriate field of AbstractClientPlayer . I'd recommend subscribing to EntityJoinWorldEvent (only on the client side) and checking if the entity is an AbstractClientPlayer . If it is, call SkinManager#func_152790_a with your own implementation of SkinManager.SkinAvailableCallback#func_152121_a that that the Type is Type.SKIN and then sets the player's locationSkin field.

Wouldn't it make more sense to override Item#hasCustomEntity and Item#createEntity to spawn a custom EntityItem class directly instead of using the event?

Ah, I gave you the SRG name of 1.8's NetworkPlayerInfo#locationSkin field instead of 1.7.10's AbstractClientPlayer#locationSkin field. The SRG name you want is actually field_110312_d . In future you should include the Minecraft version in the title so people know which version you're working with.

This is the same error as before: you're only using the deobfucated (MCP) name, not the obfuscated (SRG) name. You need to pass both names to ObfuscationReflectionHelper.getPrivateValue (and other methods in the same class that take a String array/vararg of field names). You can find the SRG name of a method/field in the MCP mapping CSVs, which can be found in your Gradle cache. For recent 1.7.10 versions of Forge, the CSVs are in ~/.gradle/caches/minecraft/net/minecraftforge/forge/<forge_version>/unpacked/conf (replace ~ with %USERPROFILE% on Windows). You can also download the mappings from the MCPBot Website.

To answer the question in your previous post, only use reflection when you can't use a normal method call/field access. Examples of this include accessing non-public methods/fields or methods/fields with a dynamic name/argument list and instantiating a class that's only known at runtime (i.e. you have a Class object you want to create an instance of).

Potion effects can only be applied to living entities, so you need to check if the entity is an instance of EntityLivingBase , cast it to EntityLivingBase and call EntityLivingBase#addPotionEffect on it.

Yes, override Block#getSelectedBoundingBox to return an AABB with the BlockPos 's x/y/z as the minimum coordinates and x/y/z + 1.0 as the maximum coordinates (like this).