Choonster

Never use unlocalised names for anything other than translation/display, they're not unique and can change at any time. The default model loaded for every Item is the one with its registry name ( IForgeRegistryEntry#getRegistryName , inherited by Item and Block ), so use that as the default location for your models. Unlocalised names have nothing to do with models. Don't use ItemModelMesher#register , use ModelLoader.setCustomModelResourceLocation / setCustomMeshDefinition in preInit. If your item model is located at assets/<modid>/models/item/<name>.obj, use new ModelResourceLocation("<modid>:<name>.obj", "inventory") as the model location. Forge allows item models to be loaded from variants of blockstates files, so you could use new ModelResourceLocation("<modid>:<name>", "<variant>") to use the model from the "<variant>" variant of assets/<modid>/blockstates/<name>.json. I have a more detailed description of the model loading process and how model locations are mapped to model files here. Forge's blockstates format may also be useful here.

AdvancedModelLoader no longer exists, OBJ and B3D models are now part of the baked model system. This means that you can use them anywhere you'd use a JSON model and you don't need a TileEntitySpecialRenderer . To use an OBJ/B3D model, tell the appropriate loader that it can load models from your resource domain (mod ID) by calling ObjLoader#addDomain or B3DLoader#addDomain in preInit from your client proxy (or a class called from it). You can then specify your model just like you would a JSON model, but include the .obj/.b3d file extension. Forge itself has a test mod with some examples: code, assets

The hopper uses the same baked model system as regular blocks, you can change your block's model and textures from its blockstates file.

To clarify: IBlockAccess is an interface implemented by World that provides access to blocks, TileEntities , biomes, etc. IBlockState is a collection of properties and values representing the current state of a Block

I don't know of any programs that do that, but Forge's blockstates format eliminates the need for a dedicated block/item model file. Just specify the base model (e.g. minecraft:cube_all ) and textures in the "defaults" block and provide a "normal" and "inventory" variant (assuming your block doesn't have any properties). Minecraft will already use the "normal" variant to render the block in the world and Forge allows item models to be loaded from variants of blockstates files (e.g. the "inventory" variant). You can see a basic example of this here. You can see a more complex example here, the model and texture are controlled by separate properties and each metadata value of the item uses the corresponding variant of the blockstates file (registered here).

Models created for 1.8 will still work in 1.9+ (the format itself hasn't changed that much), you'll probably just need to fix the display transformations (i.e. the "display" block). MrCrayfish's Model Creator does a decent job, although it's a bit limited (it will only let you specify a single decimal point of precision for most dimensions/coordinates). You can also use a mainstream 3D modelling program (e.g. 3ds Max or Blender) and export the model in OBJ/B3D format, these can be used anywhere you'd use a JSON model.

Ah, I was not familiar with that notation, so I simply thought it was a weird way of typing ModelManager.getModel(). Thus my question becomes, how would I obtain an instance of ModelManager? My intuition says to not simply create a new instance of ModelManager but use an existing one, but I have no idea where to look... Use your IDE to find where ModelManager is instantiated and where the instance is stored.

Is your mcmod.info a valid JSON file? Are there any errors in the log telling you why it failed to load? Upload your mcmod.info and FML log (logs/fml-client-latest.log) to Gist and link them here.

There is no Block#blockID field in 1.7.10 since IDs are automatically managed. Use World#getBlock and compare the Block instances directly with == . There is no initCreature method in any subclass of Entity . Were you looking for EntityLiving#onSpawnWithEgg ? Always annotate override methods with @Override so you get a compilation error if the method doesn't actually override a super method.

The Modder Support section is for mod developers, but this thread would fit the General Discussion or Minecraft General sections (and I've requested it be moved to one of them). If you want help with the crashes, post in the Support and Bug Reports section. Make sure you read the EAQ before posting.

Most Forge mods are universal, which means the same mod runs on (and is required on) both the client and server. The exceptions are things like HUDs/minimaps (usually client-only) or admin tools like permission management/backup (usually server-only). Single player still has a server running in the background, so most server-only mods will still work with it. Refer to the mod's description/installation instructions to see which sides it runs on.

Override TileEntity#shouldRefresh to return oldState.getBlock() != newSate.getBlock() . This way the TileEntity will only be recreated when the Block changes. The commented out methods aren't outdated, they're for 1.9.4. If the client needs some data from the TileEntity to render your block, send it in the update (a.k.a description) packet. In 1.9, override TileEntity#getDescriptionPacket to write the data that needs syncing to a compound tag and then create and return an SPacketUpdateTileEntity with the position and NBT. Override TileEntity#onDataPacket to read from the packet's NBT. In 1.9.4, override TileEntity#getUpdateTag to write the data that needs syncing to a compound tag and return it. Override TileEntity#getUpdatePacket to create and return an SPacketUpdateTileEntity with the position and update tag. Override TileEntity#onDataPacket to read from the packet's NBT.

The confirmation GUI is less detailed than the log message, it just tells you the total number of missing blocks and/or items and which ones are missing without telling you what each missing thing is. In this case, it's just one item ( minecraft:lit_furnace ) and no blocks missing. Forge saves a list of every block/item name and the corresponding numeric ID with the world. It will detect when a block/item no longer exists, even when it's not used anywhere. If you don't have any Lit Furnaces in item form, nothing will happen to your world. The Lit Furnace block still exists, so furnaces in the world won't be affected.

Yes, you can add it as a dependency through Gradle or put it in the mods folder (but not both). Since you're using 1.7.10, it must be a dev/deobfuscated build of the mod; unless you're running the dev version of CodeChickenCore, which will deobfuscate mods at runtime. In 1.8+, ForgeGradle can deobfuscate dependencies on disk. In 1.8.9+, FML can deobfuscate mods at runtime; completely removing the need for dev builds.

tiningot is an ItemStack and there's no ItemStack(ItemStack) constructor. Use tiningot directly instead of trying to create a new ItemStack from it. Creating a ShapedOreRecipe without a pattern or input will crash the game.

GameRegistry.addRecipe(new ShapedOreRecipe(new ItemStack(Items.bucket), "I I", " I ", 'I', "ingotIron"))

You need to create the ShapedOreRecipe with the result, pattern and inputs and then call GameRegistry.addRecipe(IRecipe) to add it.

Use JEI instead.

1.9 removed the item form of the lit furnace because it's not meant to be used by players, only the furnace itself should switch to that block. This is just telling you that the item no longer exists, blocks in the world won't be affected.

If it's any consolation, the method doesn't exist in 1.9+.

If you look at the implementation of EntityPlayer#getInventory , you'll see that it actually returns the player's armour inventory rather than their main inventory. Use EntityPlayer#inventory or PlayerMainInvWrapper . In 1.9.4+, call ICapabilityProvider#getCapability on an EntityPlayer with CapabilityItemHandler.ITEM_HANDLER_CAPABILITY and a vertical EnumFacing to get an IItemHandler wrapper of their main inventory or a null EnumFacing to get an IItemHandler wrapper of their whole inventory (main, armour and off hand).

I would recommend posting your code, you may have made a mistake somewhere without realising it.

I installed the mods again with the universal builds but my minecraft crashes with a report Post the crash report.

You downloaded the source code of the mods, hence the src classifier. Download the universal builds instead.

EnumHelper.addArmorMaterial was briefly broken in 1.9.4, but it was fixed a while ago.