Choonster

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.

Item#onCreated is called when the ItemStack is taken from the output slot of a furnace, crafting table or villager trade GUI. You wouldn't need to set the durability when the item is crafted if you used Minecraft's system of 0 being fully-repaired and X (where X is some positive number) being fully-damaged.

Your code is incorrect, you're printing "NO NBT" when the ItemStack when nbt isn't null (i.e. when it has a compound tag) and calling a method on nbt when it is null (causing the NullPointerException). If ItemStack#getTagCompound returns null or ItemStack#hasTagCompound returns false, you need to create an NBTTagCompound and call ItemStack#setTagCompound to set it as the ItemStack's compound tag. I use this method in my code to get or create an ItemStack's compound tag. You can also use ItemStack#getOrCreateSubCompound to get or create a sub-compound of the ItemStack's compound tag or ItemStack#setTagInfo to set a key of the ItemStack's compound tag to the specified NBT tag. These will both create the compound tag if necessary.

Don't extend BlockLiquid or create your own property; just use Material.WATER and include the BlockLiquid.LEVEL property. Since your Block has a property, you either need to include the property's values in your blockstates file or ignore the property by registering an IStateMapper for the Block by calling ModelLoader.setCustomStateMapper in ModelRegistryEvent. You can create the IStateMapper using StateMap.Builder. It won't render water on any side of the block not touching water:

Item#onCreated can be used to add NBT data to the result ItemStack of a crafting, smelting or merchant recipe; but it can't do so based on the ingredients.

Each overload of GameRegistry.addSmelting calls the corresponding FurnaceRecipes method. There's no difference between the GameRegistry and FurnaceRecipes methods. The NBT data on the result ItemStack you pass to these methods will be copied to the smelting result. The NBT data on the ingredient ItemStack is completely ignored.

Create a class that extends Ingredient or a subclass like IngredientNBT. Override Ingredient#getMatchingStacks and/or Ingredient#apply if you need to. Create a class that implements IIngredientFactory and returns a new instance of your Ingredient from the parse method. Specify the IIngredientFactory class in recipes/_factories.json. FurnaceRecipes doesn't check NBT, so you can't restrict smelting ingredients to specific NBT values. It does preserve the original NBT data of the smelting result, though.

The log explains exactly what the problem is and how to avoid it: Aside from that, 1.7.10 mods won't work on 1.12 (except under very rare circumstances where the mod doesn't use anything that's changed between Minecraft versions).

1.7.10 is no longer supported here, update if you want help.