Choonster

You're storing compound inside of itself, leading to infinite recursion when Minecraft tries to write the NBT to disk.

This is incorrect. There's nothing in the Forge build system that removes @SideOnly classes from the JAR, since Forge mods are universal (i.e. required on both sides) by default. You may be thinking of Mojang's build system for Minecraft, which doesn't include client-only classes in the server JAR or server-only classes in the client JAR. ForgeGradle adds @SideOnly to client- or server-only classes, fields and methods when it merges the client and server JARs for the development environment.

Have you tried my suggestion?

You can probably make use of the active item use mechanic used by bows, food, shields, etc. Try overriding Item#onItemRightClick to do the following: Call EntityLivingBase#isHandActive to check if the player is actively using an item. If they aren't, call EntityLivingBase#setActiveHand to make the player start using your item and then perform the effect. If they are, do nothing. You'll also need to override Item#getMaxItemUseDuration to return the maximum duration in ticks that the player can actively use your item (bows and shields use 72000, which is 1 hour), and optionally Item#getItemUseAction to return something other than EnumAction.NONE.

Enchantments are managed by a Forge registry, so the numeric IDs are automatically assigned per-save and shouldn't be used. Use the registry name in the JSON instead and store the Enchantment instance in the Ingredient for matching.

You can use the Capability system to store additional data on Vanilla TileEntities.

What are you trying to achieve? There's probably a better way to do it than replacing the TileEntity completely.

You'll need to create a copy of IngredientNBT and override Ingredient#apply to perform a partial NBT match instead of a full NBT match. You'll then need to create an implementation of IIngredientFactory that creates an instance of the Ingredient class from the provided JSON object; you can use CraftingHelper.getItemStack to parse an ItemStack from JSON. Register this factory by adding the fully-qualified name to your _factories.json file; you can see an example here. The name you specify for the factory in _factories.json is the name you'll use in the type property of the ingredients in your recipe files. Edit: You might want to use an NBTPredicate for the NBT matching rather than storing a full ItemStack. This isn't really what the OP is looking for, since the conditions are only evaluated once when the recipe is loaded.

Resource packs can't modify server-side files like recipes, structures and loot tables; but the data packs being added in 1.13 probably will be able to.

Override FluidHandlerItemStackSimple#fill and FluidHandlerItemStackSimple#drain to call the super methods and then damage FluidHandlerItemStackSimple#container if the super method returned something other than 0/null and the doFill/doDrain parameter is true.

You don't write the patches yourself, you set up a Forge workspace, make your changes to the appropriate Vanilla classes and then run the genPatches Gradle task to re-generate the patches with your changes. Forge's documentation explains how to contribute to Forge here and here.

active=true,facing=south is not the same as facing=south,active=true. If you use Forge's blockstates format, you can specify the effect of each property value individually and you don't need to list the properties in a specific order (except when using fully-defined variants).

See the bot's help page.

An ItemStack with zero count is automatically empty; you don't need to return ItemStack.EMPTY.

Running mh isTransparent on MCPBot tells me that Particle#func_187111_c was renamed from isTransparent to shouldDisableDepth on 2017-02-18 by kashike.

If you look at ItemBlock#getCreativeTab, you'll see that it always uses the Block's creative tab and ignores the one set with Item#setCreativeTab. You need to use Block#setCreativeTab instead.

The field is protected, so it can only be accessed normally from a subclass of RenderLivingBase or from a class in the same package as it. Since your code is neither of those, you'll need to access it via reflection.

CommonProxy subscribes to RegistryEvent.Register<Block> and calls BlockRegistry#register, which registers all of your Blocks. BlockRegistry also subscribes to RegistryEvent.Register<Block> and registers the same Blocks a second time, resulting in this warning. Also see Code Style Issue 1. Your registration code should be largely self-contained, the class that registers the Blocks and Items should be the same one that subscribes to RegistryEvent.Register; there's no reason to subscribe to it in one class and call methods in another class to do the actual registration. You can see how I handle Block and ItemBlock registration in my mod here.

The main point of IItemColor is to separate the colour methods from the Item class (where they used to be in older versions), so you shouldn't implement it on your Item. You should implement IItemColor with a lambda or anonymous class instead. You can see how I implement and register my mod's IBlockColors and IItemColors here. ColorHandlerEvent was added in a recent 1.12.2 build, before that you needed to register them in init.

That should work. Could you post your entire model and IItemColor implementation?

There are two overloads of Block#hasTileEntity: one with no parameters and one with an IBlockState parameter. Only the one with no parameters is deprecated, the one with the IBlockState parameter is the one to override.

You haven't specified a tint index for any of the quad faces of your models, so they're not recoloured at render time. builtin/generated automatically specifies a tint index equal to N in the quads it generates for each layerN texture.

My harvest swords can be repaired with the ToolMaterial's repair item in anvils and I don't override any repairing-related methods or subscribe to any anvil-related events to achieve this; it just works by default. It looks like ModTools.initRepairs isn't being called from anywhere, since it's private and not called in ModTools. This means that your ToolMaterials' repair items aren't being initialised; which would explain why your tools can't be repaired. What do you mean by "it won't register"? Did you try to use the ItemAxe(ToolMaterial) constructor with a non-Vanilla ToolMaterial only to find that it threw an ArrayIndexOutOfBoundsException? You need to use the ItemAxe(ToolMaterial, float, float) constructor for modded ToolMaterials; the ItemAxe(ToolMaterial) constructor uses the ToolMaterial's ordinal as an index for the ATTACK_DAMAGES and ATTACK_SPEEDS arrays, which only have values for the Vanilla ToolMaterials.

That's correct.

Sneak-right clicking on a Block with an Item will only call Item#onItemUse by default, ignoring Block#onBlockActivated. To change this behaviour, either override Item#doesSneakBypassUse to return true (for your own Items) or subscribe to PlayerInteractEvent.RightClickBlock and call PlayerInteractEvent.RightClickBlock#setUseBlock with Result.ALLOW (for Items from Vanilla or other mods). This is handled in PlayerInteractionManager#processRightClickBlock on the server and PlayerControllerMP#processRightClickBlock on the client. Don't compare to ItemStack.EMPTY directly, it's just one of many possible empty ItemStacks. Use ItemStack#isEmpty instead.