Choonster

Send the villager's entity ID in the packet. Don't send the number of emeralds to drop, let the server determine that itself. Malicious clients can send whatever packets they want, they could tell the server to drop a hundred emeralds. You don't need to send the player, the packet handler knows which player's client sent the packet.

Only check the emerald count when the button is clicked (or when drawing the screen if you want the button to look different when there's enough emeralds), don't check it in initGui. World#isRemote will always be true in a method called from a GUI, because GUIs only exist on the logical client. Use the Simple Network Implementation to send packets.

You should also override TileEntity#getUpdateTag to return data that should be sent to the client with the chunk (usually the same data as the update packet). Do you ever manually trigger the sending of the update packet with World#notifyBlockUpdate? Are the contents of the fluid tanks ever used for rendering the block, or are they only rendered in the GUI? If they're only rendered in the GUI, you can sync them in the Container rather than the TileEntity's update tag/packet (and avoid re-rendering the chunk whenever you receive the update packet).

ClientChatReceivedEvent#getMessage returns the message as an ITextComponent. This could be an instance of any class that implements ITextComponent, e.g. TextComponentString or TextComponentTranslation. What are you trying to achieve?

You should add the button once in an override of GuiScreen#initGui, after calling the super method. You're currently adding a new button every frame. Override GuiScreen#actionPerformed to perform an action when the button is pressed. When clicked, the button should send a packet to the server that hires the villager after checking that the player is allowed to do so, e.g. they're within range and there are enough emeralds in the inventory. GUIs only exist on the client, the game state needs to be controlled by the server.

You don't need to extend PotionEffect, it works with any Potion (like ItemStack works with any Item). Just create an instance. The system became a lot simpler with the move from metadata bit-shifting in 1.8.9 and earlier to PotionTypes in 1.9.

In 1.8.9, create an ItemStack of Items.potionitem and set the "CustomPotionEffects" key of the stack compound tag to a list tag that contains a compound tag for each PotionEffect applied by the potion. You can use PotionEffect#writeCustomPotionEffectToNBT to write a PotionEffect to a compound tag. Set the metadata to 0x4000 (or any number that returns a non-zero result when bitwise AND-ed with 0x4000) to make it a splash potion. In 1.11.2, create an ItemStack of Items.POTIONITEM, Items.SPLASH_POTION or Items.LINGERING_POTION and use PotionUtils.addPotionToItemStack to set the stack's PotionType. No, you can have as many ForgeGradle workspaces as you want. I have a separate TestMod3 workspace for each Minecraft version, each of which is its own branch of the TestMod3 Git repository.

One of your coremods is broken, possibly BetterFPS. Make sure you're using the latest version of every mod. If the issue persists, remove BetterFPS. If that fixes it, report this error to the author of BetterFPS.

It looks like you need to subscribe to PotionBrewEvent.Pre, check the input items with PotionBrewEvent#getItem, modify the output with PotionBrewEvent#setItem and then cancel the event. For the vanilla brewing stand, indexes 0-2 are the three input items (the potions to be converted) and index 3 is the ingredient item. It may be easier to use Forge's brewing recipe system. You can use BrewingRecipeRegistry#addRecipe to add a brewing recipe for an input, ingredient and output or add an instance of IBrewingRecipe. If you update to 1.10.2+, you can register PotionType conversions with the vanilla PotionHelper class.

The active hand isn't what you think it is. The active hand is the hand that's actively using an item (by holding down right click), e.g. blocking with a shield, eating food, drinking a potion, drawing a bow. EntityLivingBase#getActiveHand, EntityLivingBase#getActiveItemStack, EntityLivingBase#getItemInUseCount and EntityLivingBase#getItemInUseMaxCount only return valid results when the entity is actively using an item, i.e. EntityLivingBase#isHandActive returns true. When a player is placing a block, it's very unlikely that either hand will be active.

Your tanks should not be in static fields, each instance of the TileEntity should have its own tanks. I'm not entirely sure what's causing that behaviour in the GUI, but it may be related to the static fields. How are you syncing the tanks to the client? Post the code that does this.

I explain which models are loaded from where here. You need a blockstates file for the block models. The item models can either be their own model files or specified by the blockstates file.

Your getCapability method is wrong. Please read my instructions carefully, I've told you exactly what you need to do: I didn't tell you to change the if statement, I told you to change the cast of this.item_handler.

TileEntity#shouldRefresh is the method to look at. This controls whether the TileEntity is re-created when the IBlockState changes.

Capability#cast casts it for you without the unchecked warning.

Almost, but not quite. Instead of casting this.item_handler directly to T and suppressing the unchecked warnings resulting from it, call CapabilityItemHandler.ITEM_HANDLER_CAPABILITY.cast with this.item_handler as the argument. Capability objects are singletons, compare them with the equality operator (==) rather than the Object#equals method. CapabilityItemHandler.ITEM_HANDLER_CAPABILITY is a field of type Capability (more specifically Capability<IItemHandler>), there's no reason to cast it to Capability. In addition to that, there's no Capability#equals method with a Capability parameter; only Object#equals with an Object parameter. Only cast when it's required by the compiler. Import classes like Capability and EnumFacing instead of using fully-qualified names. Forge only uses fully-qualified names in vanilla patches to reduce the patch size (by removing the need for an import statement).

Post the EntityTestbroom class, the issue may be there. It's best to keep client-only code like model registration in dedicated client-only classes to help avoid issues like this, though PotterEntities.registerRenders probably isn't the cause of the issue. Side note: RenderingRegistry#registerEntityRenderingHandler(Class<? Entity>, Render<? extends Entity>) is deprecated, call RenderingRegistry#registerEntityRenderingHandler(Class<T>, IRenderFactory<? super T>) in preInit instead.

You need to initialise the IItemHandler field with an instance of an IItemHandler implementation. The default implementation of IItemHandler is ItemStackHandler, which will probably suit your needs. The field should also be private. Override EntityLivingBase#hasCapability (which implements ICapabilityProvider#hasCapability) to return true if the Capability argument is CapabilityItemHandler.ITEM_HANDLER_CAPABILITY or return the result of the super method if it's not Override EntityLivingBase#getCapability (which implements ICapabilityProvider#getCapability) to return the IItemHandler instance if the Capability argument is CapabilityItemHandler.ITEM_HANDLER_CAPABILITY or return the result of the super method if it's not. Due to limitations of Java's generics, you'll need to call Capability#cast on CapabilityItemHandler.ITEM_HANDLER_CAPABILITY with the IItemHandler as the argument to cast it to the return type. Calling the super method allows capabilities to be provided by super classes or attached with AttachCapabilityEvent.

I also noticed that, I believe it's due to the IItemHandler returned by EntityLivingBase#getCapability being a wrapper of EntityLivingBase#handInventory and EntityLivingBase#armorArray. EntityLivingBase#onUpdate replaces the contents of these each tick with the ItemStacks returned by EntityLivingBase#getItemStackFromSlot (which EntityLiving implements using its own lists: EntityLiving#inventoryHands and EntityLiving#inventoryArmor), so any changes made through the IItemHandler are overwritten the next tick. I'm going to see if I can reproduce this and create a Forge issue/PR for it. In the meantime, you should create your own IItemHandler field in IvVillager and expose it via hasCapability/getCapability. Currently you're using slot 0 of the combined armour/hands inventories, which is the feet slot.

Minecraft couldn't find your item model or blockstates file. Are they definitely in the right place (src/main/resources/assets/aptbts/...)?

I figured out the issue: In your Container constructors you were trying to use the villager field, but you never assigned it a value so it was always null. You were also assigning the IItemHandler to a handler local variable instead of the handler field. I fixed these issues in this commit. I also fixed several other issues and changed GuiHandler to use the entity ID instead of the entity's coordinates (which avoids the potential of clicking one villager and opening a GUI for another standing in the same space). You can view and/or merge my changes here.

I'll start debugging it now. I also recommend using a proper Git client (either the CLI or a GUI client like GitKraken or your IDE) rather than using GitHub's upload system. Edit: You should also include the Gradle wrapper (gradlew, gradlew.bat and the gradle directory) in your repository, though this isn't as essential as the buildscript. Edit 2: You should also include a .gitignore file to ensure only the required files are included in the repository. I linked an example in this post.

This is in the game directory of the launcher profile you're running (.minecraft if you haven't changed it).

As I said: This is in the OWNER_DEFINED_ID field initialiser. The name of the field doesn't matter, you could call it FOO_BAR_BAZ and the issue would still be present. Please include your buildscript (build.gradle and gradle.properties) in the repository.

I have no idea what would cause this, but the FML log may contain some useful information; please post it.