Choonster

Create a class that extends ItemBlock and overrides Item#getItemBurnTime and then register an instance of this as the Item form of your Block.

That should be @SubscribeEvent, not @EventHandler.

Don't call TileEntity#writeToNBT unless you actually need to serialise the TileEntity to NBT (e.g. to store the data in an ItemStack). Minecraft automatically calls it when the chunk is written to disk. Your TileEntity's data should be stored in regular fields and only written to NBT when necessary.

Judging by the "ForgeData" tag, it looks like you're using TileEntity#getTileData somewhere; don't do this. The tag returned by TileEntity#getTileData is for mods to store custom data on external TileEntities; but the capability system is a much better way to do this. When you call TileEntity#writeToNBT, pass an empty compound tag as the argument.

1.11.x has these methods and it has the registry events. All of the advice you've received here still applies.

Subscribe to GuiOpenEvent instead, it can be cancelled to prevent the GUI from opening.

There are three overloads of IForgeRegistryEntry.Impl#setRegistryName (which is inherited by Item): (String) (ResourceLocation) (String, String) Even if it did require a ResourceLocation, it's not a very complicated class: it's simply a domain (your mod ID) and a path (the name of your Item).

That doesn't change anything, it still shouldn't be used.

You need to use submodels to combine multiple models. Are you sure you actually need multiple models and not just a single model with multiple textures?

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.