Choonster

Create a sound event in your sounds.json file, give it a sound with minecraft:entity.horse.saddle as the name and event as the type and then set its subtitle. This will play a sound from the existing event but use your subtitle. See this page for an explanation of the sounds.json format.

You're playing the saddle equip sound in EntityTerrakon#processInteract . Just play a different sound.

The RenderItem instance is created between preInit and init, so you can't access it in preInit. The solution is to use the ModelLoader methods instead of the ItemModelMesher methods.

ModelLoader.setCustomModelResourceLocation must be called in preInit, as I said in my previous post.

That looks correct, yes.

See here for an example of what I'm talking about. registerBlockItemModelForMeta (which you can see in the same class) is essentially just a wrapper around ModelLoader.setCustomModelResourceLocation . This uses a variant of the block's blockstates file (uses Forge's blockstates format) rather than an item model. To use an item model, use a ModelResourceLocation with the model's location and the "inventory" variant. Use the getRegistryName method to get the registry name of an Item or Block . Most of my mod's items use this method to set their registry and unlocalised names, but some (e.g. Records) have completely separate unlocalised and registry names that they set manually. I use a similar method for blocks.

By default, the only model loaded for an Item (including an ItemBlock ) is the one with its registry name ( Item#getRegistryName ). You're telling Minecraft to use different models for each metadata value of the Item form of ModBlocks.ore , but you never tell it to load any of these models. To tell Minecraft to load a model other than the default one, call ModelBakery.registerItemVariants in preInit. Each argument is either the location of an item model or the location and variant of a blockstates file to load the model from. Don't use ItemModelMesher#register , use ModelLoader.setCustomModelResourceLocation (for metadata-based models, will call ModelBakery.registerItemVariants for you) or ModelLoader.setCustomMeshDefinition (for arbitrary ItemStack to ModelResourceLocation mapping) in preInit. Never use getUnlocalizedName().substring(5) anywhere in your code. Unlocalised names can change at any time, registry names are IDs and must not change. As I said before, the default model loaded for an Item is the one with its registry name, unlocalised names have nothing to do with models. I suggest using the registry name system to register your Block s and Item s: Call setRegistryName to set the registry name, then call the single argument overload of GameRegistry.registerBlock / registerItem to register the Block / Item . Do not use unlocalised names as registry names, but you can use registry names as unlocalised names (this will include your mod ID in the unlocalised name, which will avoid conflicts with other mods). Using registry names now will make it much easier to update to the new registry system in 1.9.

Entity#getEntityData returns a compound tag for storing custom data on external entities. It does not store the entity's own data (e.g. Slime size) and should not be combined with Entity#readFromNBT and Entity#writeToNBT .

So I looked at the code, and it doesn't seem like there's any explicit method call to make entity collision instantiate the wither effect. Soul Sand doesn't apply the Wither effect, it slows down entities. There are only two methods in BlockSoulSand excluding the constructor: one defines the bounding box (so entities can collide with it), the other slows down entities when they collide with the block. When an entity collides with your block, check if it's an EntityLivingBase and then use EntityLivingBase#addPotionEffect to apply the Wither effect to it.

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.