Leaderboard

Are you running the vanilla launcher or something like MultiMC?

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.

EntityPlayer::isPlayerSleeping?

I'd assume you're using the IItemColor interface to color your items, correct? If so, there is a corresponding IBlockColor interface that works essentially exactly the same. The main differences are that the method you need to implement is colorMultiplier(IBlockState, IBlockAccess, BlockPos, Int) rather than getColor(ItemStack, Int) and instead of registering with Minecraft.getMinecraft.getItemColors.registerItemColorHandler you register with Minecraft.getMinecraft.getBlockColors.registerBlockColorHandler Hope that helps!

There are three main editions of Minecraft: Computer (which I previously referred to as Desktop), Pocket and Console. Computer Edition is the original and runs on most PC operating systems (including Windows, OS X and Linux). It can be modded with Forge and other types of mods. Pocket Edition is a rewritten implementation of Minecraft for mobile devices. Windows 10 Edition is a port of Pocket Edition to the Windows 10 platform. It can be modded on some mobile platforms (e.g. Android), but I don't know of any mods for the Windows 10 Edition. The Minecraft Marketplace will allow you to buy additional content for Pocket Edition/Windows 10 Edition. Console Edition is a rewritten implementation of Minecraft for consoles. It can't be legitimately modded. There's no way to run Forge or other Computer Edition mods on the Windows 10 Edition, but there's nothing stopping you from running the Computer Edition on Windows 10.