Choonster

You need to specify the IRecipeFactory class in the _factories.json file and then create the individual recipe JSON files for any recipes that use the recipe class.

If you look at EntityHorse, you'll see that it registers its DataParameters with their default values in its override of Entity#entityInit (called when the entity is constructed, before its position has been set) and then sets their actual values in its override of EntityLiving#onInitialSpawn (called when the entity is first spawned, after its position has been set). You need to do the same thing.

Just for future reference, you linked to the 1.12.1 branch; which is currently 11 commits behind 1.12.2 (the branch with the latest changes on it). I also recommend linking to a file/folder in a specific commit rather than a branch so that the link will remain pointing to the same code in the future rather than pointing to code that's been changed/removed.

If you look at the implementation of NBTTagCompound#setUniqueId, you'll see that it doesn't use the key you give it directly; it uses two different keys based on it. This means that NBTTagCompound#hasKey will never return true for the key you passed to NBTTagCompound#setUniqueId, you need to use NBTTagCompound#hasUniqueId instead. ItemStack NBT is automatically synced to the client. If you're setting on the server but can't access it from Item#addInformation, you're doing something wrong. Post your code. To create your own API or implement an existing one like IItemHandler/IFluidHandler; or to store data without having to serialise it to/deserialise it from NBT every time you want to access/modify it.

You need to register an IItemColor implementation for your Item with Minecraft's ItemColors instance in init. You can get the instance from a getter in the Minecraft class.

It's one JSON file per recipe, yes. Ah, I missed the version in the thread title. JSON recipes and the recipe registry were added in 1.12, 1.11 still uses the old recipe list system. In 1.11 and earlier, recipes should be registered in init.

Recipes are now managed by a Forge registry, so IRecipe extends IForgeRegistryEntry and instances of it should be registered in RegistryEvent.Register. As Kokkie said, you should use JSON files wherever possible. You can register your own recipe, ingredient and condition factories to extend the JSON system.

NEI is broken.

Minecraft itself has several models that use overrides, e.g. the compass, bow, elytra and clock; though overrides only apply to item models, not to block models. I don't know of any mods that use the TextureAtlasSprite technique.

See the answers in this thread:

No. You'll need to look at the Forge source code, examples in other mods and forum threads where people have asked similar questions. I explain how to do this here:

Get the Item registry from the ForgeRegistries class, then use IForgeRegistry#getValue to get the Item with the specified registry name. You can then register this Item with the Ore Dictionary.

Create an implementation of IBlockColor that returns the appropriate grass colour based on the biome/season and then register it for Blocks.GRASS (and any other blocks you want to colour) by calling BlockColors#registerBlockColorHandler in init. You can get the BlockColors instance from Minecraft#getBlockColors.

The ItemStack(Item, int, int, NBTTagCompound) constructor doesn't do what you think it does. The NBTTagCompound argument is for the serialised capability data, not the ItemStack's compound tag. Use one of the constructors without an NBTTagCompound argument and then use ItemStack#setTagCompound to set the ItemStack's compound tag. You shouldn't be manually creating the potion NBT anyway. If the effects you want already have a PotionType, use PotionUtils.addPotionToItemStack to add that to the potion ItemStack. If the effects don't have a PotionType (and you don't want to create one for them), use PotionUtils.appendEffects to add them to the potion ItemStack instead. If you want a splash potion, use Items.SPLASH_POTION instead of Items.POTIONITEM.

How does the user log in? Do you launch the official launcher?

You should have the Minecraft and Forge source code available in the forgeSrc-<version> referenced library, so you can either browse to the Chunk class inside of it or use your IDE's Navigate To Class (IDEA, Ctrl+N)/Open Type (Eclipse, Ctrl+Shift+T) feature to open the Chunk class directly.

Use BlockStateContainer.Builder to create the BlockStateContainer, you can call BlockStateContainer.Builder#add once for each array of properties

ModelLoader methods must be called before init, they won't do anything if called in init or later. Since you're still registering your items/blocks in preInit, register the models in preInit as well. I recommend moving your registration to the registry events and registering the models in ModelRegistryEvent, this will make it easier to update to 1.12+.

While using a lang file and the TextFormatting enum is the proper way to do this, it should still be possible to use formatting codes inline. Your issue was probably happening because your code wasn't saved or compiled as UTF-8.

Vanilla special-cases the rendering of Items for Blocks that are rendered by TESRs in TileEntityItemStackRenderer. You can register your own item TESR with ForgeHooksClient.registerTESRItemStack, but this is deprecated and marked for removal as soon as possible. Instead, you should just create a regular baked model and use that for the item form. I created a JSON version of the chest model here. Ideally you should also use a baked model for the block and use Forge's animation system to animate the lid, but unfortunately there's not much documentation on it.

Item#isValidArmor receives the EntityEquipmentSlot that's being checked as an argument, only return true if it's EntityEquipmentSlot.HEAD.

Not every axe (or axe-like tool) will extend ItemAxe. For example, the base class for Tinkers' Construct's tools extends Item and the harvest tools override Forge's harvest level/tool class methods (like Item#getToolClasses) to determine the tool classes based on the tool type and the harvest levels based on the tool's materials.

You need to supply the actual tool ItemStack that the player has placed in the machine so that mods like Tinkers' Construct can read the NBT and determine the harvest level based on it. If you supply an empty ItemStack or one without any NBT, Tinkers' Construct won't know what the harvest level is.

The MCP to SRG obfuscation performed by the build Gradle task only changes field and method names, class names are always the same between MCP and SRG. This means that NoClassDefFoundError can't be caused by lack of reobfuscation. Usually it's caused by accessing a client-only class from code that runs on the dedicated server.

@SideOnly restricts classes, methods and fields to a specific physical side. The integrated server runs on the physical client, so it has access to things annotated with @SideOnly(Side.CLIENT) (though it should never actually use these). The dedicated server runs on the physical server, which doesn't have access to things annotated with @SideOnly(Side.CLIENT). Use InventoryPlayer#hasItemStack to check if an ItemStack is anywhere in a player's inventory, matching the Item and metadata but not the NBT or capabilities.