Choonster

Implement the methods like EntityHorse does and Minecraft should automatically call them when the player is riding your entity.

I've never tried to make a mountable entity myself, but I'd recommend implementing IJumpingMount like EntityHorse does and let Minecraft handle the keybindings and networking for you.

It hasn't changed much since older versions, though numeric armour slots were replaced with the EntityEquipmentSlot enum. Create an ArmorMaterial using EnumHelper.addArmorMaterial . The first argument is the name of the enum value, which should include your mod ID to avoid conflicts with other mods. The second argument is the texture name, which should be in the format "modid:texture" . Look at LayerArmorBase#getArmorResource(Entity, ItemStack, EntityEquipmentSlot, String) to see how this is used to determine the armour texture. The rest of the arguments are fairly self-explanatory. Create an instance of ItemArmor (or a class that extends it) for each item. The renderIndexIn argument of the ItemArmor constructor is never actually used for anything, so it should be safe to pass -1 for this argument. You can see the base class for my mod's armour here and implementations here and here. These implementations have specialised functionality (replacing your other armour or deleting itself when unequipped); for regular armour with no special functionality, ItemArmor or ItemArmourTestMod3 would suffice. The ArmorMaterial is created here and the armour items are registered here.

The same way you do for any other block, i.e. use ModelLoader.setCustomModelResourceLocation / ModelLoader.setCustomMeshDefinition with a ModelResourceLocation pointing to an item model or a variant of a blockstates file.

Create an ItemStackHandler field and initialise it with a new instance. Read it from and write it to NBT like any other field of your TileEntity using the INBTSerializable methods. If you don't want hopper and pipes to interact with it, don't expose it as a capability. Instead, create a regular getter method so your GUI code can access it. I'm not that familiar with the GUI system myself, so I can only provide basic advice. You'll probably need to implement each page as a separate GUI and have buttons/tabs to switch between them. When the player clicks one of these, send a packet to the server to open the new page's GUI. Tinkers' Construct's tinker table GUIs have similar functionality to this (though each tab is for a separate block), consider looking at how that's implemented. You'll want to create your own capability to store the materials and attach it to players using AttachCapabilitiesEvent.Entity . I'm not sure exactly how you plan for these materials to be dropped, but you should have access to the player that most recently attacked the entity.

Block#damageDropped is called from Block#getDrops , so the TileEntity won't be intact when it's called unless you delay its removal. This method doesn't have World or position arguments, so you can't use the TileEntity anyway.

Blocks and items should be registered in preInit, not init. Use the dependencies attribute of your @Mod annotation (as Ernio said) to ensure your mod loads after BoP. Edit: It was Ernio who originally mentioned the dependencies attribute, not diesieben07 as I said previously.

This is not needed if you use setCustomModelResourceLocation . Ah, I forgot about that. I rarely use setCustomModelResourceLocation myself, since I don't have many metadata-based item models.

Download the Forge installer (Latest, not Recommended) from http://files.minecraftforge.net/ and run it. This will add that version of Forge to the Minecraft Launcher, you can then select that version in your profile. Don't put installers in your mods folder. Don't download mods or mod installers from random unofficial websites. Only download mods from their official download page (usually linked in the mod's Minecraft Forum thread). Yes. Make sure you downloaded it from this site, though.

Items have models, not textures. Models can have one or more textures. How to achieve this depends on exactly what you want. In preInit, call ModelBakery.registerItemVariants with the model location to tell Minecraft to load your models and then call ModelLoader.setCustomModelResourceLocation (for metadata-based models) or ModeLoader.setCustomMeshDefinition (for any ItemStack to model mapping) to tell Minecraft which models to use for your item. If your models and textures already exist as files in your mod's JAR, this is all you need. If you need to generate models at runtime, you'll probably need to look at ICustomModelLoader , IModel and ISmartItemModel . I can't help you much with them myself, but they've been discussed here and on other sites before and Forge has some examples itself. Generating textures at runtime may be trickier, I don't know how you'd achieve that.

You're still using the same version of Forge.

Do you ever call CommonProxy#preInit ? Set a breakpoint in TileEntities.init and run Minecraft in debug mode, is the breakpoint hit? In future, please select the appropriate syntax highlighting when posting code using sites like Pastebin/Gist.

I know, but you're using an outdated version. If it still doesn't work with the latest version, post a new crash report.

Something very strange is going on with your Forge installation, since it's saying it can't find a field that definitely exists. I suggest you install the latest version of Forge for 1.8.9 and use it in your profile.

ForgeRegistries.POTIONS only stores the registered Potion s, e.g. Speed, Nausea, Haste. ForgeRegistries.POTION_TYPES stores the standard effects that can appear on potion items (e.g. Poison, Strong Poison, Long Poison), but potion items can also have any number of custom PotionEffect s on them. I suggest you look at JEI to see how it finds every possible vanilla and modded brewing recipe.

I believe the OP is trying to add a new language to the game, not add translations for an existing one. It looks like you can add new languages by including a pack.mcmeta file in your mod. Minecraft's pack.mcmeta file isn't included in the ForgeGradle workspace, but you can find it in the regular client's assets.

Do not use @SideOnly on methods unless the super method is a vanilla method already marked as @SideOnly . This post explains why in more detail. World#isRemote is true on the client and false on the server. You're currently trying to display the GUI on the server, which won't work. Side note: If your GUI has an inventory, it must be opened on the server through EntityPlayer#openGUI / IGuiHandler .

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.