Choonster

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.

If you want something to behave similar to vanilla, look at the vanilla implementation and either re-use or extend it as appropriate. In this case, use or extend RenderSnowball to render an entity as an item model.

1.7.10 is no longer supported on this forum, you won't get any help with it.

That shouldn't be possible. Are you definitely running the build task? Are you looking in the correct output directory (build/libs)? Run the build task again and post the output, there may be some information as to why it's failing to reobfuscate the JAR.

EntityPlayer#addPrefix is the preferred way to add prefixes to a player's name. If you can't do that, use ServerChatEvent#setComponent to replace the chat message instead of cancelling the event and re-sending the message yourself. I suspected that may have been the case. As Ugdhar said, 1.7.10 is no longer supported here.

Data parameter IDs are automatically assigned per class hierarchy. You're passing EntityTameable.class as the first argument of EntityDataManager.createKey, so the DataParameter is being assigned the next ID for the EntityTameable class instead of the next ID for the IvVillager class. When you try to register it for the IvVillager instance, there's already a DataParamter registered for that ID so the game crashes with an IllegalArgumentException. In future, please select the appropriate syntax highlighting when posting code on a site like Gist or Pastebin. To get syntax highlighting on Gist, give each file the appropriate extension (.java for Java code). To get syntax highlighting on Pastebin, select the language from the dropdown at the bottom of the page. The Adult_Age data parameter is Stringly Typed. I suggest replacing the strings with an enum. I can't see any obvious reason for this. If you haven't already, please create a Git repository for your mod, push it to a site like GitHub and link it here so I can debug it locally. See my mod and its .gitignore file for an example of the repository structure to use and the files to include. You can still create a BlockPos from the individual coordinates.

1.7.10 is no longer supported on this forum, you won't get any help with it.

"It crashes" doesn't really tell us anything. Post the latest code and the crash report. Is there a reason you're intercepting and manually re-sending the chat messages? Why not use EntityPlayer#addPrefix or at least ServerChatEvent#setComponent? What version of Minecraft are you using?

Forge can't be installed in an MCP workspace. Forge's documentation explains how to set up a ForgeGradle workspace here. If you set up the workspace correctly, you'll have read-only access to the vanilla code (with Forge's patches).

You should read Forge's documentation page on events, it explains that event handler methods must be annotated with @SubscribeEvent and when to use static or non-static event handler methods. The FML event bus has been merged with the Forge event bus, so FMLCommonHandler#bus returns the same EventBus that's stored in the MinecraftForge.EVENT_BUS field. It's also deprecated, with a comment containing this information.

EntityPlayer#addPrefix takes an ITextComponent, which will be added to the player's display name as a prefix. There are multiple implementations of ITextComponent, but the most commonly used ones are TextComponentTranslation (translates its first argument and then formats it by calling String.format with its other arguments) and TextComponentString (a single string). ITextComponent#getStyle returns the ITextComponent's Style, which can be used to modify the style of the text.

You can use EntityPlayer#addPrefix to add a prefix to a player's display name. You'll probably want to do this when EntityJoinWorldEvent is fired for an EntityPlayer.

Minecolonies is broken. Update to the latest version, this crash has been fixed.

The installer is just for creating the server, you don't need to keep it once you've run it. You need to run forge-1.11.2-13.20.0.2309-universal.jar to run the server. If it just closes after a few seconds, run it from the command line instead of double-clicking and look for any errors in the output. If you still don't know what the error is, post the FML log (logs/fml-server-latest.log) using Gist or Pastebin.

You need to build your mod with the build Gradle task, this reobfuscates it from MCP names like getMinecraft to SRG names like func_0220_b. SRG names are the names used by Minecraft outside of the development environment.

You're creating an AABB with the x and z coordinates of the BlockPos as both the minimum and maximum coordinates, so the entity will only be found if its bounding box overlaps the northwest corner of the block it's standing on (the area represented by the AABB). You should instead create the AABB with the x and z coordinates of the BlockPos as the minimum coordinates and the x and z coordinates plus 1 as the maximum coordinates. This way the AABB will cover the entire block instead of just the northwest corner. The AxisAlignedBB(BlockPos) constructor does this for you, you can then use AxisAlignedBB#expand to expand it by 1 in each direction of the y axis (i.e. up and down). I created this item to experiment with corner- and edge-based AABBs passed to World#getEntitiesWithinAABB. Side note: You don't need to cast the result of the List#get call to IvVillager; the result of World#getEntitiesWithinAABB is a List<IvVillager> (because of the first argument), so the List#get call returns an IvVillager. Are you registering the data parameter more than once? Post the IvVillager class using Gist or Pastebin.

Minecraft ran out of memory. You can find instructions on how to give it more using your search engine of choice. In future, please post the entire FML log using Gist or Pastebin (like you were told to in your previous thread).

If you're using the new @Config annotation-based system, a config GUI will automatically be created for you. If you're using the Configuration class and specifying the properties yourself, you need to create a class that implements IModGuiFactory and specify it in the guiFactory property of your @Mod annotation. In the IModGuiFactory#createConfigGui implementation, you need to create and return an instance of GuiConfig with the top-level IConfigElements. You can see an example of the new system here.