Leaderboard

Thank you, changing that to true solved the problem

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 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.

Take a look at the forge documentation on events. For a non-static event handler method, you need the @SubscribeEvent annotation, and to register an instance on the MinecraftForge.EVENT_BUS. The @EventHandler annotation is only for FML lifecycle events (preInit, init, etc) in your main @Mod class.

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.

User was banned for using a cracked launcher

It looks correct, apart from this: When you create a Slot, you pass it an inventory (IItemHandler) and a slot index (the slot in that inventory to read from/write to). Two instances of the same Container class will generally have Slots with the same inventories and slot indexes. Your villager Containers should have one Slot for slot 0 of the villager's inventory (the only slot) and 36 Slots for slots 0-35 of the player's inventory (the main inventory section).