Choonster

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.

Recipe files need to be in src/main/resources/assets/<modid>/recipes.

Minecraft 1.11+ requires all asset file names to be lowercase.

Sorry, I misread the code and thought oldPrefix was the mod ID rather than the specified domain. Still, is there a proper way to avoid this warning?

When overriding a registry entry, the replacement needs to have the same registry name as the original. This requires setting the registry name to one with a domain that isn't your mod ID, but attempting to do so logs the "Dangerous alternative prefix" warnings and ignores the domain you specified, using your mod ID instead. Is there a better way to avoid this than temporarily replacing the active ModContainer with the Minecraft ModContainer when setting the registry name and setting it back to the previous ModContainer when registering the override?

I don't think it's possible to override vanilla advancements without messing around with the internals of the advancement system, since mod advancements are loaded with the mod ID as the domain of the advancement ID. You can suppress this error message by overriding the minecraft:wooden_button recipe with a no-op IRecipe as diesieben07 suggested here.

Not really, the recipe removal needs to be done in code and the replacement should generally be added via JSON; so replacing recipes via the registry override system (registering a new value with the same name) usually isn't practical.

JSON recipes always have your mod ID as the domain of their registry name, so they can't directly override a vanilla recipe. Removing a vanilla recipe and then loading your own to replace is it possible, as you discovered.

What do you mean by "In Minecraft pack CPacketCustomPayload spike"? What do you mean by "forge batch system"? Why is it bad?

The handler for the vanilla book edit/sign packets specifically checks if the ItemStack's Item is Items.WRITABLE_BOOK, so you can't use them for your own item. You should do the same thing in your packet handlers but check for your own Item instead of the vanilla one.

This method is marked as client-only in 1.11.2, so you can't call it directly. Instead, you need to create your own method that does the same thing. It's no longer client-only in 1.12 (because Forge patches Item#getSubItems and the methods used by it to be available on both sides), so you can use it directly.

Many Block methods (like Block#isOpaqueCube) have been deprecated by Mojang to signal that they should be overridden but not called; the corresponding IBlockProperties methods (inherited by IBlockState) should be called instead. Other methods have been deprecated by Forge to signal that they shouldn't be used at all, these usually include a comment explaining which method to use instead.

In your packet, you're reading an ItemStack and a compound tag from the byte buffer and then setting the compound tag as the ItemStack's compound tag; but then you do absolutely nothing with the ItemStack and it's garbage collected some time after the packet is received. You need to make the changes to the ItemStack in the player's inventory, but make sure you check that the NBT data and the ItemStack's Item are valid to prevent malicious clients arbitrarily modifying item NBT. Look at the "MC|BEdit" and "MC|BSign" sections of NetHandlerPlayServer#processCustomPayload for examples of how to validate the data and modify the ItemStack in the player's inventory. There's no reason to send the compound tag separately from the ItemStack, ByteBufUtils.writeItemStack includes the ItemStack's compound tag.

You didn't answer these questions: I did notice this error in the log: BlockSuppressionTower#breakBlock is throwing a NullPointerException.

Block#onEntityWalk is called when an entity (that can trigger walking) walks on top of a block. If a block has a collision bounding box smaller than a full block, Block#onEntityCollidedWithBlock is called when an entity collides with the block. You can override one of these two methods to check if the entity is an instance of EntityLivingBase and then use EntityLivingBase#addPotionEffect to add a potion effect to the entity.

Override Block#getBlockLayer to return BlockRenderLayer.CUTOUT or BlockRenderLayer.CUTOUT_MIPPED. The Grey Ghost explains render layers in more detail here. Override Block#isOpaqueCube to return false.

No, EntityItems should still be spawned with World#spawnEntity. How exactly is it not working? What do you expect to happen? What actually happens? Post your code and the FML log.

There is no property with the name "LEVEL" in your Block's BlockStateContainer, so BlockStateContainer#getProperty returns null and you call StateMap.Builder#ignore with this null value. The name of the BlockLiquid.LEVEL property is "level". Don't call Block#createState yourself, don't store the BlockStateContainer in a static field and don't use BlockStateContainer#getProperty to get the property. Just reference BlockLiquid.LEVEL directly.