Choonster

Try searching for net.minecraftforge.items.IItemHandler on GitHub. Refined Relocation 2 and Chisels and Bits are two I noticed.

The RenderManager instance is created between the preInit and init phases, so Minecraft#getRenderManager returns null in preInit. In 1.8, call RenderingRegistry#registerEntityRenderingHandler in init. In 1.8.9 and up, call RenderingRegistry#registerEntityRenderingHandler(Class<T>, IRenderFactory<? super T>) in preInit instead. In future, post the FML log (logs/fml-client-latest.log) or crash report; preferably using a site like Gist or Pastebin.

Either extend SlotCrafting and replicate the functionality of SlotItemHandler yourself or vice versa.

Did it hit the breakpoint? Now that I think about it, regular debugging may not help much for a memory leak. You may need to read up on techniques for debugging memory leaks in Java and figure this out yourself.

All the vanilla GUIs still use IInventory , but the inventories themselves have been patched to support the IItemHandler capability.

In vanilla and older versions of Forge, TileEntities with inventories implement IInventory . This interface allows the inventory contents to be manipulated by GUIs and other blocks like Hoppers/Pipes. In 1.8.9 and up, you should never be implementing IInventory yourself and you should avoid using it. The Capability system allows you to store one or more IItemHandler inventories in your TileEntity and access them through the ICapabilityProvider interface (implemented by TileEntity ). SlotItemHandler allows you to create a Slot for an IItemHandler inventory. Hoppers and vanilla inventories have been patched to support this system and item transport systems from properly updated mods (e.g. Extra Utilities 2) now use it.

GuiScreen#onGuiClosed is called when the GuiScreen is closed.

I already told you: OutOfMemoryError Despite the name, exception breakpoints work with any Throwable , not just Exception s.

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 .