Choonster

Looking at the decompiled source, it seems RWTema has created his own model system on top of the existing system. Unless you know exactly what you're doing, it's probably a lot easier to just use the existing system rather than trying to implement your own.

Could you post your Block class?

It looks like you didn't call OBJLoader#addDomain for your mod's resource domain, so the OBJ loader wasn't loading models in that domain.

I don't think Minecraft stores this information. You'll need to store it yourself.

Which mod are you talking about? If it's DenseOres, the models and textures are generated at runtime.

Short answer: No. Long Answer: You can use Forge's Blockstates Format to reduce the number of models you need to create. You can use OBJ and B3D models instead of JSON models. You can create your own model loader and generate models at runtime.

No. I suggest you look up any terms you don't understand and look at examples in Forge's code.

Yes. Your code has several issues: You're trying to create and register your IItemColor from common code, which will crash the dedicated server. You need to do this from a client-only class. You're storing your own Map of IItemColor instances and never using it anywhere. Delete this Map and register your IItemColor using ItemColors#registerItemColorHandler. Get the ItemColors instance from Minecraft#getItemColors. You're calling ItemEternalCrystal#registerItemColorHandler with an empty Item array. You need to call ItemColors#registerItemColorHandler with your Item instance.

So you create your own.

Simply change the value of the version property in the minecraft block of your build.gradle, re-run the setupDecompWorkspace Gradle task and refresh your IDE project (click the "Refresh all Gradle projects" button in IDEA's Gradle window or re-run the eclipse task and refresh the project in Eclipse). You can also update the MCP mappings used for your project by changing the value of the mappings property in the minecraft block of your build.gradle. The same process applies for refreshing the project. Note that you can change the Forge version and the MCP mappings version at the same time, you'll only need to refresh your project once.

Start by reading the documentation.

You can suggest name changes on the MCPBot Issue Tracker. You can use MCPBot itself to find the SRG name of a field/method/parameter.

Either create your own packet using the Simple Network Wrapper or send SPacketWindowProperty if you want to keep using Container#updateProgressBar.

Use SlotItemHandler instead of Slot. IItemHandler doesn't have the same "fields" concept as IInventory, so you'll need to re-implement the syncing yourself.

The acceptedMinecraftVersions property of your @Mod annotation controls which versions of Minecraft your mod will be allowed to load on. If you don't reference any classes, methods or fields that have changed between the versions you want to support, it's entirely possible for the mod to work in multiple versions. That said, very few mods are able to do this.

Use log4j, the logging library used by Minecraft. To get a log4j Logger instance, you can either use the methods from LogManager or use FMLPreInitializationEvent#getModLog, which returns a Logger with your mod ID as its name. Call ICommandSender#sendMessage on an EntityPlayer (or any other ICommandSender) to send them a message. The most commonly used ITextComponent implementations are TextComponentTranslation (a translation key and format arguments translated and formatted on the client) and TextComponentString (a simple string). You can use any folder structure you want inside src/main/java as long as your packages match it.

Use IBakedModel#getQuads to get the model's BakedQuads and use BakedQuad#getSprite to get the texture of a BakedQuad. You can also use IBakedModel#getParticleTexture to get a model's particle texture.

The registry name is the object's unique identifier, it's not directly related to rendering (though it's used as the default location for blockstates files [for Blocks] and item models [for Items]). Blocks don't have textures, they have models. Models do have textures, though. What exactly are you trying to do? You can use BlockRendererDispatcher#getModelForState to get the IBakedModel for an IBlockState. If you need the model's location rather than the model itself, use BlockStateMapper#getVariants to get a Map<IBlockState, ModelResourceLocation> for a Block and use it to look up the ModelResourceLocation for an IBlockState.

You can like posts by clicking the "Like this" button in the bottom right of the post. I think that's the only thanking mechanism available now.

Your question is a bit vague, it's equivalent to asking about getting the int from a Block. Which ResourceLocation do you want? The registry name? The model location? Something else?

Call Item#setNoRepair to stop an Item from being repaired.

I'm not really following you. Please do what I told you to in this post (if you haven't already) and post the code and FML log (using Gist) for that version. Posting one version of the code and a crash report for a different version doesn't help much.

It was renamed to LivingEntityUseItemEvent because the corresponding Item methods now use EntityLivingBase instead of EntityPlayer.

You call ModelBakery.registerItemVariants with the registry name of ModItems.stonetongs (which is presumably <modid>:stonetongs) and <modid>:stonetongs, but your ItemMeshDefinition returns the registry name with the _default suffix (<modid>:stonetongs_default which you haven't registered).