Choonster

Java's tutorials do use the term "static nested classes".

If the handler is a static nested class (which it should be), attempting to access instance fields of the message results in a compilation error.

When you use nested classes depends on your code style. There's not really a specific area where you need to use them, they mostly behave just like normal classes. One common use is nesting the IMessageHandler in the corresponding IMessage class to keep the message and its handler together.

If you're not using Forge, why are you asking for help on the Forge forums? If you want to modify the base classes directly, you need to use MCP. Your edits will likely make the mod incompatible with Forge and any other JAR mod that changes the same classes.

In short: You don't. Forge exists to allow compatibility between mods, editing base classes leads to incompatibilities. You can usually achieve what you want in some other way, e.g. with an event or by replacing a field. If you tell us what you're trying to achieve, we can tell you how to do it. It is possible to modify base classes using ASM, but this is highly discouraged and you won't get any help with it here.

args was length 0, so attempting to access index 0 threw an ArrayIndexOutOfBoundsException. You're already checking if the length is 0 before printing the help text, you just need to return from the function after doing that instead of trying to access index 0.

That chat message is sent when ICommand#execute throws an exception. The exception is logged when this happens, so look at the log to see what happened.

No. If you look at the code that calls it, you'll see that it's only called when the Block changes.

Block#breakBlock is called when a block is replaced by another block, regardless of what caused the replacement.

Override GuiButton#drawButton to set GuiButton#displayString based on the villager's following state and then call the super method.

That looks correct, but you should use NBTTagCompound#getCompoundTag rather than NBTTagCompoundTag#getTag in readEntityFromNBT. There's no need to read/write values that are already handled by the parent class, e.g. the Forge profession.

In writeEntityToNBT, call INBTSerializable#serializeNBT to serialise the ItemStackHandler to a compound tag and then call NBTTagCompound#setTag on the compound tag argument, passing the serialised ItemStackHandler compound tag as the second argument. In readEntityFromNBT, call NBTTagCompound#getCompoundTag on the compound tag argument to get the serialised ItemStackHandler compound tag, then pass it to INBTSerializable#deserializeNBT to deserialise the ItemStackHandler. That's not an error, that's someone printing a UUID to stdout. I don't think Vanilla or Forge do this, so it's probably your code.

That's correct. @Mod#acceptableRemoteVerions expects a version range, not just a single version. It's parsed using VersionRange.createFromVersionSpec, which has a doc comment explaining the format.

That's the right method, but you actually need to store the compound tag returned by it in the compound tag you receive as an argument to writeEntityToNBT. Currently you're just discarding it. You also need to do the reverse with INBTSerializable#deserializeNBT in the readEntityFromNBT method. Why are you checking World#isRemote? It's not necessary in these methods and may break things.

You never write the IItemHandler to or read it from NBT, so it's not persisted when the entity is unloaded/reloaded. Do this using the INBTSerialializable methods implemented by ItemStackHandler.

You're registering the Class with the event bus, but your event handler method isn't static. If you register the Class, you need to use a static method. If you register an instance, you need to use an instance method. The documentation explains this. There's no reason to create a new object of a known class and immediately call Object#getClass on it, just use a class literal.

@Mod.EventHandler is only for FML lifecycle events that extend net.minecraftforge.fml.common.event.FMLEvent, e.g. FMLPreInitializationEvent or FMLServerStartedEvent and only works in your @Mod class. @SubscribeEvent is used for gameplay events that extend net.minecraftforge.fml.common.eventhandler.Event, e.g. PlayerInteractEvent.RightClickItem or TickEvent.ServerTickEvent. Forge's documentation explains events in more detail here. The ItemStack returned by PlayerInteractEvent#getItemStack will never be reference equal to an ItemStack you've just created, because they're not the same object (which is what the == operator checks). To compare ItemStacks, either get the Item, metadata, etc. and compare those or use the static equality methods in the ItemStack class. Since you're only checking the Item, use ItemStack#getItem to get the Item and check if it's equal to (==) Items.GLASS_BOTTLE.

Forge tries to load the item model first and only tries to load the model from the blockstates file if that fails. I have a more detailed explanation of the model loading process here. If it's not loading your item models, the FML log should have an error message explaining why.

Upload the log to Gist and reply here with a post containing the URL.

Post the FML log (logs/fml-client-latest.log in the game directory) using Gist.

It's a plain text file, open it in a text editor like Notepad.

In short, you don't. 1.12 isn't ready yet:

If you update to the latest MCP mappings, DamageSource#getSourceOfDamage/getEntity have been renamed to DamageSource#getImmediateSource/getTrueSource respectively. This makes it clearer which entity is which.

I encountered several issues with your code: You're registering two different IMessageHandlers (HireVillagerPacket and ChangeFollowPacket) for the same IMessage class (MessageSendEntityId), which doesn't work. Each IMessage class can only have a single IMessageHandler. These classes are poorly named. HireVillagerPacket and ChangeFollowPacket are packet handlers, not packets. MessageSendEntityId tells me what the packet sends, but it doesn't tell me the most important piece of information: why the packet is sent, i.e. what action does it perform? You use Packet in the handler names but you use Message in the packet name, pick one and stick with it. GuiHandler#getClientGuiElement incorrectly returns a Container instead of a GuiScreen for the Hauler ID. GuiIvVillagerHauler uses ContainerIvVillagerHireNitwit instead of ContainerIvVillagerHauler. ContainerIvVillagerHauler adds 15 Slots for the villager's inventory, but the IItemHandler created in IvVillager only has one slot. The Button_Hire and Button_Follow classes no longer serve a purpose, you can replace their usages with regular GuiButtons. When you have an if statement that does nothing but set the value of a boolean variable (like in GuiIvVillagerHireNitwit#actionPerformed), you can move the expression used as the condition of the if statement directly to the initialisation of the boolean variable and remove the if statement. When you have a boolean variable declared directly before and only used in the condition of the if statement, you can move the expression used to initialise it directly into the condition of the if statement and remove the boolean variable. If the condition of an if statement is particularly complex, it can be clearer to keep some parts of it as variables. I've fixed these issues and pushed the changes to GitHub. You can view and/or merge the changes here. You appear to be using GitHub's web UI to upload changes to your repository, I highly recommend using a proper local Git client instead. This will allow you to create more fine-grained commits with descriptive messages rather than lumping all your changes into a single commit with a message like "Add files via upload".

You don't create the RenderManager or RenderItem instances yourself, you use the instances Minecraft has already created. To register a Render for an Entity class, call RenderingRegistry.registerEntityRenderingHandler(Class<T>, IRenderFactory<? super T>) in preInit. In the IRenderFactory#createRenderFor implementation, create and return the Render instance. You receive the RenderManager instance as an argument of IRenderFactory#createRenderFor and you can get the RenderItem instance using Minecraft#getRenderItem. This advice applies to all versions from 1.8.9 onwards. 1.7.10 and earlier are still available for download, but they're not supported on this forum. I believe 1.8.9 is still supported, but you should really update.