Choonster

Follow the instructions in the Getting Started guide to set up your IDE project correctly. If you follow these instructions, you'll have the forgeSrc-<version>.jar library referenced in your IDE project with the source code attached to it.

The Crafting Table is implemented in the BlockWorkbench,ContainerWorkbench and GuiCrafting classes. Recipes are managed by CraftingManager, mod recipes are loaded by CraftingHelper. Vanilla recipe files are located in the assets/minecraft/recipes directory. The Furnace is implemented in the BlockFurnace, TileEntityFurnace, ContainerFurnace and GuiFurnace classes. Recipes are managed by FurnaceRecipes. The Anvil is implemented in the BlockAnvil, ContainerRepair and GuiRepair classes. There are no anvil recipes, the output is managed by ContainerRepair#updateRepairOutput (which fires AnvilUpdateEvent to allow mods to add custom item combinations). To open a class by name, use Navigate > Class (Ctrl-N) in IDEA or Navigate > Go To > Type... in Eclipse.

It looks like several exceptions occurred, but due to where they were thrown the name and message were logged without the stacktrace or cause. This makes it very difficult to see what the problem is by looking at the log. The "Could not dispatch event" message is logged by the anonymous SubscriberExceptionHandler class created in the LoadController constructor. Set a breakpoint in the handleException method of the anonymous class and look at the Throwable argument and its cause in the debugger when the breakpoint is hit. This should explain what the problem is.

I don't think there's many tutorials on this, since each machine is different. All I can suggest is to look at the examples in Vanilla/Forge and in open source mods.

You can still add smelting recipes with GameRegistry#addSmelting, since smelting recipes weren't changed in 1.12. By "custom recipe", I thought you were talking about creating you own recipe class with custom logic, which isn't possible for smelting recipes. Yes, you can create your own machines with their own set of recipes.

FurnaceRecipes still uses a Map of input ItemStacks to output ItemStacks, you can't create your own smelting recipes with custom logic.

Use PlayerList#getPlayers to get a list of players on the server or PlayerList#getPlayerByUUID to find a player by their UUID. Use MinecraftServer#getPlayerList to get the server's PlayerList instance.

Look at the DefaultStateMapper#getModelResourceLocation method to see how it returns a ModelResourceLocation with the Block's registry name as the domain/path and a property string of the IBlockState's property and values as the variant. You need to extend StateMapperBase and implement StateMapperBase#getModelResourceLocation to return a ModelResourceLocation with your blockstates file's domain (your mod ID) and name as the domain/path and the property string as the variant. If your mod ID is jwa and your blockstates file is called withered_debris.json, use "jwa:withered_debris" as the first argument of the ModelResourceLocation constructor. Once you've created this class, register an instance of it for your Block by calling ModelLoader.setCustomStateMapper. Do this in ModelRegistryEvent.

32767 is the value of OreDictionary.WILDCARD_VALUE, which tells the Ingredient to accept any metadata value of the item. This allow an Iron Helmet with any amount of damage to be used in the recipe. Minecraft uses the metadata as the amount of damage the item has taken, so 0 is no damage and X (where X is the maximum damage) is just about to break. ShapedArmourUpgradeRecipe clamps the output item's damage between 0 and its max damage, so if the Iron Helmet has more than 77 damage (the max damage of a Gold Helmet), the damage on the Gold Helmet will be clamped to 77. This means that an Iron Helmet with anywhere from 0 to 88 durability will be converted to a Gold Helmet with 0 durability.

Weather & Tornadoes was discontinued and replaced by Weather, Storms & Tornadoes, a.k.a Weather2 and Localized Weather & Stormfronts. It hasn't been updated to 1.12 yet.

Your replacement Block doesn't have the BlockGrass.SNOWY property, so Minecraft tries to load the model from the minecraft:grass#normal variant, which doesn't exist. You should include this property in your Block. You should also register an IStateMapper for your replacement Block so that its models are loaded from a different blockstates file. This will prevent resource packs that replace the minecraft:grass blockstates file from replacing your Block's models (though resource packs that replace your blockstates file will still work, this is intended). Your IStateMapper can extend StateMapperBase and implement StateMapperBase#getModelResourceLocation to do something similar to DefaultStateMapper#getModelResourceLocation, but use the location of your blockstates file as the domain and path of the ModelResourceLocation instead of using the registry name. Your replacement Block needs to extend BlockGrass.

First update your workspace to 1.12 by editing build.gradle. Change the ForgeGradle version from 2.2 to 2.3, change the Forge version to a 1.12 version and change the MCP mappings version to a 1.12 version. After doing this, re-run setupDecompWorkspace and refresh your IDE project. Then start fixing any compilation errors in your code. The main changes from 1.11.2 to 1.12 are overhauls of the registry and crafting recipe systems: GameRegistry.register is now private, use the registry events instead. Recipes are now loaded from JSON files and managed by a Forge registry. There have been several threads about both of these changes, I suggest searching for them if you have any questions. If you can't find the answers, ask here.

Then it's probably an issue with your code rather than the Forge issue I linked. Please post your code, the relevant JSON files and the FML log (logs/fml-client-latest.log in the game directory) using Gist or Pastebin.

Please answer these questions:

Does the model work in single player?

That could be related to this issue. Are you using the latest version of Forge?

There is no registered Item with the name wllcsam:genevirus. Have you spelled the name correctly? Do you register an Item with this name anywhere?

It does if you create your own recipe class and factory, as I explained in my previous post.

It will work in 1.11.2 and probably in 1.12, but it may not work in future versions. Registry events are the recommended way to register things.

There's already an option for this in Forge's config file: client -> replaceVanillaBucketModel

When you view a Vanilla or Forge class, does a yellow bar appear at the top of the editor saying "Decompiled .class file, bytecode version X.X (Java X)"? If so, click on the "Choose sources..." link and the Attach Sources window should appear with the directory containing the Forge JAR opened. Select the forgeSrc-<version>-sources.jar (the JAR containing the source code for Minecraft and Forge) in this directory and then click OK. The name of the method is irrelevant, what matters is the parameter type. When you create a method annotated with @SubscribeEvent that has a single parameter that extends from net.minecraftforge.fml.common.eventhandler.Event and register the class/instance with the appropriate event bus (e.g. by annotating the class with @Mod.EventBusSubscriber), Forge will automatically call the method whenever that event is fired. The documentation explains events properly here. RegistryEvent.Register<T> is fired once for each registry when that registry is ready to receive registrations. The type argument is the registry's type. Subscribe to RegistryEvent.Register<Block> to register your Blocks, subscribe to RegistryEvent.Register<Item> to register your Items, etc. Registering in preInit is the old way to do things, the registry events were introduced so modders can register their registry entries (Blocks, Items, etc.) at the correct point in the loading process without worrying about when that is. For example, RegistryEvent.Register is fired for most registries directly before preInit (in 1.10.2-1.11.2) or directly after preInit (1.12+); but in 1.12 it's fired for the recipe registry slightly later. Eventually, it's planned for recipes to be loaded at server start, so RegistryEvent.Register<IRecipe> will be fired then instead of between preInit and init.

What exactly do you want from the recipe? Are you trying to create a recipe that accepts any metadata value of one or more ingredients? Are you trying to create a recipe that outputs a different item depending on the ingredient items? You can use an array of ingredients anywhere a single ingredient is expected to create a compound ingredient that matches any of its child ingredients. Minecraft uses this for recipes like minecraft:crafting_table, which accepts any of the 6 valid metadata values of minecraft:planks. You can also use 32767 (the value of the OreDictionary.WILDCARD_VALUE constant) as the metadata value of an ingredient to match any metadata value of the specified Item.

Did you follow the Getting Started guide in the Forge documentation? It should explain exactly how to set up your ForgeGradle workspace and IDE project. As of 1.9+, you now register the ItemBlock separately from the Block, like you would any other Item. The Forge documentation explains how to register Blocks, Items and other IForgeRegistryEntry implementations using registry events here.

Post your recipe file and the FML log (logs/fml-client-latest.log in the game directory) using Gist or Pastebin.

Recipes now use the Forge registry system, so subscribe to RegistryEvent.Register<IRecipe> and register an instance of the recipe using IForgeRegistry#register. When possible, you should register recipes through JSON files rather than in code. To allow your IRecipe class to be used by JSON files, create an IRecipeFactory class for it and specify it in _factories.json. You can see some examples of IRecipe and IRecipeFactory implementations here, the _factories.json file here and the recipe files here.