Choonster

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.

Minecraft is only configured to use 1 GB. Do you have the _JAVA_OPTIONS environment variable set?

Is the blockstates file named with your item's registry name? Post the full error, it should say exactly which files it tried to find and what went wrong with them.

The class you specified in your @SidedProxy annotation doesn't exist, make sure you have the right package and class name. I suspect you wanted com.bensonchen.firsttestmod.ClientProxy , not com.bensonchen.firsttestmon.ClientProxy .

Create an implementation of ICapabilitySerializable that provides an IItemHandler instance (probably an ItemStackHandler ). Override Item#initCapabilities to return a new instance of the provider. This gives your item an IItemHandler inventory that's stored in memory with the ItemStack and not written to NBT until it needs to be (unlike the old way of giving items inventories, which was using an IInventory read from and written to NBT every time it was accessed). To get this inventory from an ItemStack of your Item , use the ICapabilityProvider#getCapability method inherited by ItemStack . I don't have any examples of this exact use case, but I do have several of my own capabilities in my mod. You can see their APIs here and implementations here. ItemSlingshot and ItemLastUseTimeModel attach the ILastUseTime capability to themselves to track their last use time. The IMaxHealth capability is attached to all living entities in CapabilityMaxHealth.EventHandler to provide bonus max health and used by ItemMaxHealth{Getter/Setter} , BlockMaxHealth{Getter/Setter} and CommandMaxHealth{Add/Base/Get/Set} . The IPigSpawner capability is attached to ItemPigSpawner by itself and to Items.CLAY_BALL in CapabilityPigSpawner.EventHandler to allow them to spawn pigs and used by BlockPigSpawnerRefiller .

Update LunatrisCore to 1.8-1.1.2.30. I would also recommend updating to Minecraft 1.8.9 and updating Forge, LunatrisCore and Schematica to match.

Stuffed Animals is trying to load a client-only class on the server, it won't work on the dedicated server due to this.

From the Dynamic Lights thread and download page: