Choonster

When you want to do something similar to an existing feature, look at how that feature is implemented. In this case, look at how CommandBlockBaseLogic executes commands.

Post the FML log, it should tell you why the model didn't load. Side note: In 1.9+, basic item models should extend item/generated rather than builtin/generated . This extends builtin/generated and defines the standard display transformations for you. Also, the thirdperson and firstperson display transformations no longer exist; they were split into left/right-hand versions.

When asking for help, always specify the Minecraft version you're using and post your code and the FML log/crash report. In this case, the issue is almost certainly that you're using the vanilla ItemAxe(ToolMaterial) constructor and it's crashing with an ArrayIndexOutOfBoundsException . This is due to the constructor using the ToolMaterial 's ordinal as an array index, so it only works with the vanilla ToolMaterial s. The solution is to use the ItemAxe(ToolMaterial, float, float) constructor added by Forge instead.

Store the registry name (and any other ResourceLocation ) as a string, convert by calling toString . Use the ResourceLocation(String) constructor to convert the string back to a ResourceLocation .

World#isRemote is true on the client and false on the server, so you're doing everything on the client instead of the server. The server is in charge of the game state, so the changes you make disappear when the client next synchronises with the server. You may want to use the World#rand field instead of creating your own Random each time. Similarly, consider using the specialised methods like BlockPos#up instead of the more general BlockPos#add when only changing one coordinate of a BlockPos . There's no real performance difference, but your code will be a bit clearer.

This is true, but recent versions of Forge explicitly warn the user if they're using an old version of Java and have mods that require Java 8 installed. If none of their mods require Java 8, Forge will still display a big warning telling them that they should update Java.

Those are SRG names, they're automatically generated obfuscated names that remain stable between Minecraft versions. When Forge decompiles the Minecraft code, it maps each SRG name to an MCP (deobfuscated) name using the MCP mappings version specified in build.gradle. If a field/method/parameter doesn't have an MCP name, the SRG name is used. MCPBot can tell you what the current MCP name of a field/method/parameter is for a Minecraft or MCP version.

You can see how I automatically add a GUI entry for each config element in my mod here. I think I adapted this from EnderIO a while back.

You have various colour-related methods in your FIItem class, but Minecraft doesn't know anything about them. You need to register an IItemColor implementation for any Item you want to colour. Do this by calling ItemColors#registerItemColorHandler in init from your client proxy. For examples, look at ItemColors#init or my mod.

Any method that took a block position as individual coordinate arguments now takes a single BlockPos argument instead. Use World#getBlockState to get the IBlockState at a BlockPos or World#setBlockState to set it. Use IBlockState#getBlock to get the Block represented by an IBlockState . Use IBlockState#getValue to get the value of an IProperty in the IBlockState . Use Block#getDefaultState to get the default IBlockState of a Block , then chain IBlockState#withProperty calls to get the IBlockState with the specified property values set. Blocks usually store their properties in static fields. In this case, BlockLiquid.LEVEL is the property you want to query the value of. This uses the same values as the metadata in earlier versions, so 0 is a source block and 15 is the smallest amount of liquid. Forge's documentation explains how to play sounds in 1.9+ here. BlockPos has methods to offset the position in each cardinal direction (i.e. add the specified amount to a single coordinate) and to add an arbitrary amount to each coordinate. Use these instead of manually re-creating BlockPos objects where possible, this will make your code easier to read. All of the casts to double and float are pointless, int s are automatically promoted to float s, float s are automatically promoted to double s. You only see that in the vanilla code because the compiler generates the casts for you. You check if a single ItemStack 's Item is equal to all of your armour Item s; but it can only be one of them, not all of them. You later compare the Item using its unlocalised name; this is a bad idea since unlocalised names aren't unique and can change at any time. A class generally shouldn't be checking for specific instances of itself, use instanceof to check if the player's equipped items are your armour and the ItemArmor#armorType field to check which equipment slot this is for. Your onArmorTick method has a random IBlockState argument and doesn't override the super method.

Your client proxy class doesn't exist.

ItemThrowableTorch#onItemRightClick doesn't override Item#onItemRightClick because it has the wrong signature, so it's never called from anywhere. Always annotate override methods with @Override so you get a compilation error if they don't actually override a super method.

Don't use block IDs. Get the block registry from ForgeRegistries.BLOCKS , the Block from its registry name by calling IForgeRegistry#getValue and then the IBlockState from the metadata by calling Block#getStateFromMeta .

The deprecated GameRegistry methods tell you their replacements in their doc comments. The registration process is the same for any IForgeRegistryEntry implementation (e.g. Block , Item , Biome ): Call setRegistryName to set the registry name of the object Call GameRegistry.register(IForgeRegistryEntry) to register it The main change from the old system is that GameRegistry.register won't create an ItemBlock for your Block , you need to create and register it yourself. Some older tutorials will tell you to use the unlocalised name as the registry name or model location, don't do this. Registry names are IDs, they must be unique and can't change. Unlocalised names are only for translation/display purposes, don't have to be unique and may change at any time. The default model loaded for every Item is the one with its registry name, so use this as the default model location for your items. If the registry and unlocalised names of an object are the same, set the registry name and then set the unlocalised name to the registry name ( setRegistryName("foo"); setUnlocalisedName(getRegistryName()); ). This has the benefit of including your mod ID in the unlocalised name, preventing localisation conflicts with other mods. If the unlocalised name changes later on, set it separately instead of using the registry name.

You've done something wrong. This page explains how to correctly set up a ForgeGradle workspace and IDE project.

It doesn't exist. World#getBlockState is the replacement for both World#getBlock and World#getBlockMetadata .

Methods relating to Block s and metadata now use IBlockState instead. Forge's documentation has an introduction to block states here.

Extend Block and override Block#hasTileEntity(IBlockState) and Block#createTileEntity . Don't implement ITileEntityProvider .

Minecraft uses LayerBipedArmor to render armour on bipeds. This uses a pair of ModelBiped s (one for the legs, one for the other pieces) with a larger scale than the entity's model. To use a custom model for your armour, override Item#getArmorModel .

Where are you trying to open it from? If it's on the server (e.g. when the player right clicks a block/item), just call EntityPlayer#openGUI directly and FML will send a packet to the client telling it to open the same GUI. If it's on the client (e.g. when the player presses a key), send a packet to the server and then call EntityPlayer#openGUI in the handler.

Send a packet to the appropriate side with the necessary information and then open a GUI from your packet handler. Are you sure you need to send a packet? What type of GUI is this and where are you opening it from?

Forge's documentation has a section on networking here. This includes the Simple Network Implementation, which you should use to send your packets.

This is why you should always annotate override methods with @Override : Several of the methods you're trying to override have a different signature to your methods, so you're not actually overriding them. If you annotate a method with @Override , you'll get a compilation error if it doesn't override a super method. Your IDE should also be able to auto-generate override methods for you. The call to getRenderType in your constructor is pointless, the method does nothing but return a value and you never use that value. Once you understand what you've done wrong with the override methods, I'd recommend extending BlockBush instead of Block . Keep in mind that there's no reason to override a method if your method will do exactly the same thing as the super method.

Post your code.

When asking for help with a crash, always include the FML log or crash report. In this case, the issue is that you're using the vanilla ItemAxe(ToolMaterial) constructor that uses the ToolMaterial 's ordinal as an array index. The array only contains values for the vanilla ToolMaterial s, so using a custom one crashes with an ArrayIndexOutOfBoundsException . The solution is to use the ItemAxe(ToolMaterial, float, float) constructor added by Forge. This takes the attack damage and speed as arguments instead of getting them from the vanilla array.