Choonster

Normally you'd set a breakpoint in a method related to your issue so you could step through it and see what's going on. In this case, set an exception breakpoint rather than a line breakpoint so execution is paused when an OutOfMemoryError is thrown.

In 1.9, PlayerInteractEvent has a separate nested subclass for each type of player interaction. Subscribe to one of these rather than PlayerInteractEvent itself. I suggest you use Log4J like the rest of Minecraft/Forge rather than printing directly to stdout. FMLPreInitializationEvent#getModLog will return a Logger that will log messages with your mod ID, store this somewhere and use it to write to the log.

It definitely looks like a memory leak now, there's no way Minecraft should be running out of memory with 8 GB available. IDE stands for Integrated Development Environment, you could have looked this up yourself. Eclipse and IntelliJ IDEA are the two IDEs supported by Forge/ForgeGradle.

Post the new FML log. Search the Internet for "how to set breakpoints <your IDE here>", there should be plenty of results.

Breakpoints are part of your IDE's debugger, I suggest you read up on how to use it.

Start by looking at the vanilla code, i.e. BlockSlab and the classes that inherit from it. I have some slightly more complicated examples in my mod: base class, coloured slab, registration, blockstates files (look for stainedClaySlab*.json). This code is for 1.8.9. I'd recommend updating to 1.8.9 or 1.9, 1.8 is quite outdated at this point.

That's checking whether the Wolf is tamed, not whether it's a baby.

Are they supposed to? Does that happen for vanilla entities?

Try set an exception breakpoint for OutOfMemoryError in your IDE's debugger and step through the stack frames. Does anything stand out? Upload your FML log (logs/fml-client-latest.log) to Gist/Pastebin and link it here, it may also contain some useful information.

The default amount of memory (1.75 GB on my machine) should be fine, but something's limiting the memory to 1 GB with a JVM argument. This is most likely the run configuration in your IDE or an environment variable. If it's the former, delete the JVM arguments. If it's the latter, delete the environment variable. I'm not sure exactly why only your GUI is crashing, perhaps it just uses more memory than the vanilla GUI. I've just noticed that the crash report you linked in the OP doesn't mention your GUI (or any GUI) at all. Could you post the most recent crash report? Edit: Added a missing word.

If it's running out of memory, I suspect you still have 1 GB assigned; probably from the _JAVA_OPTIONS environment variable.

Give your TileEntity an IItemHandler field for its own inventory. If you want things like hoppers and pipes to interact with it, override the ICapabilityProvider methods inherited by TileEntity . Make sure you call the super methods if the Capability isn't CapabilityItemHandler.ITEM_HANDLER_CAPABILITY so capabilities attached from AttachCapabilitiesEvent.TileEntity still work. To get the item's inventory, use the ICapabilityProvider methods inherited by ItemStack . The model will probably require an IModel , an ICustomModelLoader and an ItemOverrideList . I don't know much about the model system myself, I suggest you look at Forge's ModelDynBucket or Tinkers' Construct's tool models.

From the EAQ (which you're supposed to read before posting):

That code looks correct, yes. I'd personally make the stackHandler field private final IItemHandler rather than public ItemStackHandler just to ensure that external code can't replace it, but it's not strictly necessary. You can optionally add a public getter method for it. There's no reason to cast null to any type except in very specific circumstances, you only see that in Minecraft's code because the compiler automatically inserts it. Use Item#initCapabilities instead of AttachCapabilitiesEvent.Item for your own items, yes.

1.9 moved block/item colouration to separate interfaces: IBlockColor and IItemColor . You need to create implementations of these and register them with the BlockColors / ItemColors instances (which you can obtain from Minecraft in the init phase). For examples, look at BlockColors / ItemColors or my mod ( ModColourManager.registerColourHandlers is called from the client proxy in init).

Do not register a Capability for IItemHandler , Forge already does that. Do not use AttachCapabilitiesEvent for your own objects, it's only for external objects. Do not store the IItemHandler in a static field, each instance of the provider must have its own instance of IItemHandler . The CapabilitiesGunParts.GUN_PART_CAPABILITY will be populated with the IItemHandler Capability , but there's no real reason to have the field since you can just use CapabilityItemHandler.ITEM_HANDLER_CAPABILITY . Always use the @Override annotation on override methods.

Slot#getStack can only throw a NullPointerException if its IInventory is null .

The TileEntity isn't usually intact when Block#getDrops is called, look at Forge's patch to BlockFlowerPot to see how it delays the removal of the TileEntity until after Block#getDrops has been called.

Pixelmon is broken, update it to the latest 1.7.10 version.

Universal Electricity is broken. You're also using a dev build of it. You're using a version of BuildCraft Compat built for 1.8+ on 1.7.10.

Have you registered the event handler? I suggest reading a tutorial on event handlers, like this one.

Weeping Angels requires Origin. You're using a dev (deobfuscated) build of CoFH Core. This won't work in the normal (obfuscated) client.

That is the right method, yes. This tells Minecraft to load the models, you can then tell Minecraft to use these models for your items using ModelLoader.setCustomModelResourceLocation / ModelLoader.setCustomMeshDefinition in preInit (use these instead of ItemModelMesher#register in init). You can use ResourceLocation s or ModelResourceLocation s here (since ModelResourceLocation extends ResourceLocation ), ResourceLocation s will be converted to ModelResourceLocation s with the "inventory" variant. Item.itemRegistry was renamed to Item.REGISTRY in more recent MCP mappings, use the appropriate name for your current mappings. You can also use ForgeRegistries.ITEMS instead. I suspect the doc comment is a leftover from older versions of Minecraft where blocks and items were stored in arrays indexed by their IDs. Pretty much every singleton class (e.g. Block , Item , BiomeGenBase ) is now stored in a registry. Things like block, item, recipe and IGuiHandler registration must be done on both physical sides (client and dedicated server), so do it in your @Mod class (or a class called from it). Your client proxy should only be doing client-only things like model registration. ItemBlock s are no longer automatically created and registered, you need to do this yourself (as described in the thread you linked). You can use Item.getItemFromBlock to get the ItemBlock form of a Block . You can see how I register my mod's blocks here and my item models (including ItemBlock s) here.

Yes. This provides your IItemHandler instance from ItemStack#getCapability and reads from/writes to NBT. Yes, either of ItemStackHandler or your own IItemHandler implementation. You need to create a new instance of this for every instance of your provider ( ICapabilitySerializable ) class. Return a new instance of your provider class every time the Item#initCapabilities method is called.

The IRenderFactory must be a separate class to the Render (it can also be a lambda, method reference or anonymous class). The whole point of IRenderFactory being introduced was to delay the creation of the Render instances until the RenderManager is ready. If you're extending Render directly, you need to override Render#doRender to actually render the player. Extend from RenderPlayer if you want the default player model to be rendered. Player renderers receive special treatment, so RenderingRegistry#registerEntityRenderingHandler probably won't work in this case. You'll need to create your Render instances in the init phase and use reflection to assign them to the RenderManager#playerRenderer field and the "default" and "slim" keys of the RenderManager#skinMap field. Note that your changes will be completely overwritten if another mod does the same thing. If you want to replace the skin for a specific player, consider doing something similar to what I did for capes here.