Choonster

You should have the Minecraft and Forge source code available in the forgeSrc-<version> referenced library, so you can either browse to the Chunk class inside of it or use your IDE's Navigate To Class (IDEA, Ctrl+N)/Open Type (Eclipse, Ctrl+Shift+T) feature to open the Chunk class directly.

Use BlockStateContainer.Builder to create the BlockStateContainer, you can call BlockStateContainer.Builder#add once for each array of properties

ModelLoader methods must be called before init, they won't do anything if called in init or later. Since you're still registering your items/blocks in preInit, register the models in preInit as well. I recommend moving your registration to the registry events and registering the models in ModelRegistryEvent, this will make it easier to update to 1.12+.

While using a lang file and the TextFormatting enum is the proper way to do this, it should still be possible to use formatting codes inline. Your issue was probably happening because your code wasn't saved or compiled as UTF-8.

Vanilla special-cases the rendering of Items for Blocks that are rendered by TESRs in TileEntityItemStackRenderer. You can register your own item TESR with ForgeHooksClient.registerTESRItemStack, but this is deprecated and marked for removal as soon as possible. Instead, you should just create a regular baked model and use that for the item form. I created a JSON version of the chest model here. Ideally you should also use a baked model for the block and use Forge's animation system to animate the lid, but unfortunately there's not much documentation on it.

Item#isValidArmor receives the EntityEquipmentSlot that's being checked as an argument, only return true if it's EntityEquipmentSlot.HEAD.

Not every axe (or axe-like tool) will extend ItemAxe. For example, the base class for Tinkers' Construct's tools extends Item and the harvest tools override Forge's harvest level/tool class methods (like Item#getToolClasses) to determine the tool classes based on the tool type and the harvest levels based on the tool's materials.

You need to supply the actual tool ItemStack that the player has placed in the machine so that mods like Tinkers' Construct can read the NBT and determine the harvest level based on it. If you supply an empty ItemStack or one without any NBT, Tinkers' Construct won't know what the harvest level is.

The MCP to SRG obfuscation performed by the build Gradle task only changes field and method names, class names are always the same between MCP and SRG. This means that NoClassDefFoundError can't be caused by lack of reobfuscation. Usually it's caused by accessing a client-only class from code that runs on the dedicated server.

@SideOnly restricts classes, methods and fields to a specific physical side. The integrated server runs on the physical client, so it has access to things annotated with @SideOnly(Side.CLIENT) (though it should never actually use these). The dedicated server runs on the physical server, which doesn't have access to things annotated with @SideOnly(Side.CLIENT). Use InventoryPlayer#hasItemStack to check if an ItemStack is anywhere in a player's inventory, matching the Item and metadata but not the NBT or capabilities.

InventoryPlayer#getSlotFor is a client-only method (i.e. it's annotated with @SideOnly(Side.CLIENT)), so it doesn't exist on the dedicated server and can't be used from common code (like an event handler running on the logical server).

The crosshair texture is in the assets/minecraft/textures/gui/icons.png file.

Event handlers with the same priority are called in the order that they were registered in. This isn't documented, so it's probably best to consider it an implementation detail that shouldn't be relied upon.

I explain how to get an InputStream from a SoundEvent here:

The forge launcher profile isn't actually configured to use a Forge version. You need to set it to a Forge version in the Launch Options tab.

That doesn't appear to be the FML log. Please find the file named fml-client-latest.log in the logs folder of the game directory and then upload it to Gist and link it here.

Post the FML log (logs/fml-client-latest.log in the game directory) using Gist or Pastebin. This should tell us why it's crashing.

I explained how to sync item capabilities here:

That code looks like it's from a Bukkit plugin (or a plugin for a similar system) rather than an old Forge mod. You need to use IBlockState#getValue to get the values of the various properties stored in the BlockDoor class from the state. This will tell you the door's facing and hinge position diesieben07 explained which properties you need and which block to get their values from earlier in the thread.

I must have confused getHitVec with the hitX/Y/Z arguments of Block#onBlockActivated, which I'm pretty sure are between 0 and 1. I don't have my IDE in front of me, so I might be mistaken (again). Edit: The hitX/Y/Z arguments of Block#onBlockActivated are between 0 and 1.

You register the Class object with the event bus, which means your event handler methods need to be static. The Forge documentation explains this in more detail here.

getHitVec is the position on the block that the player clicked (in the range 0-1), not the position of the block in the world.

Are you definitely registering your event handler properly? Post the registration code.

Which version are you using? By the looks of it, it's not 1.12; which is where the new registry system was introduced. Before 1.12 there was the substitution alias system (GameRegistry.addSubstitutionAlias), though I never managed to get it working properly myself.