Choonster

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.

Recipes and entities are managed by registries, so register them in RegistryEvent.Register<IRecipe> and RegistryEvent.Register<EntityEntry> respectively. Use EntityEntryBuilder to create the EntityEntry. World Generators aren't managed by a registry and there's no dedicated event to register them, so do it in preInit/init/postInit.

You can also check which player died by checking their UUID. Usernames can change, it's best to compare UUIDs instead as they're constant and unique.

The client only needs Forge installed if the server's mods need to be installed on the client. If none of the server's mods are required on the client, a Vanilla client can join. In what context? If you have a MinecraftServer argument available, use that. If you have an object with a method that returns MinecraftServer (e.g. World#getMinecraftServer), use that. If all else fails, you can use FMLCommonHandler#getMinecraftServerInstance.

serverSideOnly just tells the client to skip loading the mod if it's installed, you need to set the acceptableRemoteVersions property to "*" as well. This tells it to accept any remote version, including none.

1.7.10 is no longer supported by Forge, which means it won't receive updates and you won't get any help with it on this forum.

ArmamentHaki's post. I'll edit in a quote. Edit: I don't think I can on mobile.

For the record, I'm not a moderator; I've just spent a lot of time on here.

Using the JSON system is the recommended way to add recipes (and should be used wherever possible), but you can instantiate and register the recipe from code during RegistryEvent.Register<IRecipe> if necessary.

You've told us what you're trying to do, but you haven't told us what's not working or what you need help with. I'd recommend splitting the active light and facing into two separate properties, which will allow you to use Forge's blockstates format to specify the model once, the texture for each active light and the rotation for each facing rather than having to make a model for each combination of active light and facing.