Choonster

Forge's documentation explains this here. For examples, look at some of my mod's init classes.

ItemSpear is (presumably) a subclass of Item, so it's entirely possible for a method with Item as the return type to return an instance of ItemSpear. Checking if an ItemSpear is an instance of Item is pointless, since it will always be true. That part of the OP's code is correct. Using unlocalised names for anything except translation/display purposes is a bad idea, since they're not unique and can change at any time.

There was a major overhaul of the registry system in Forge 1.12-14.21.0.2348, so any mod built for an earlier version of Forge is unlikely to work. Forge for 1.12 isn't yet stable, so breaking changes will be common until the first stable version. If you want help with the freeze, post the new FML log.

It's the thread stickied at the top of the Support & Bug Reports section.

In previous versions of Minecraft, it was possible to create a handler for ItemTooltipEvent in common code without crashing the dedicated server as long as you didn't reference any client-only classes. In 1.12, ItemTooltipEvent now references the client-only ITooltipFlag, which crashes the dedicated server with a ClassNotFoundException when you create a handler for the event in common code (unless you mark the handler method as client-only). I suggest moving the event to a client package or at least mentioning that it's client-only in the doc comment.

You don't need to do anything, Forge automatically loads every file in the recipes directory of each mod's assets.

I made my own Ingredient class for this, but it would make sense for minecraft:item_nbt to create an NBT-sensitive Ingredient.

Replace "modID" with your actual mod ID and include your mod ID in the unlocalised name (e.g. by making it the String form of the registry name ResourceLocation). The numeric ID can be any number unique to your mod, though it's probably easiest if you start from 0 and increment by 1 each time you register an entity. It's used in the entity spawn packet. You can see how I register my mod's entities here.

The ResourceLocation parameter is the registry name of your entity, which should have your mod ID as the domain and a name unique within your mod as the path. This is just like the registry name of a Block, Item or other IForgeRegistryEntry implementation. The String parameter is the unlocalised name of your entity, used for translation/display purposes. I recommend using the String form of the registry name as the unlocalised name.

Use EntityRegistry.registerModEntity in preInit to register an entity. Use RenderingRegistry.registerEntityRenderingHandler(Class<T>, IRenderFactory<? super T>) in preInit from a client-only class to register an entity renderer.

Similar questions have been asked (and answered) here and here. I implemented a solution the to the latter thread myself, you can see the API here and the implementation here. This uses a World capability to store the Map<ChunkPos, IChunkEnergy> at runtime, but loads the IChunkEnergy and saves it to the chunk's data using ChunkDataEvent.Load/Save.

I'm pretty sure the recipe system we have now is what those comments are talking about, they just haven't been updated yet. Now that IRecipe extends IForgeRegistryEntry, you can add a recipe in code by registering an IRecipe object with ForgeRegistries.RECIPES; just like any other IForgeRegistryEntry. I think using the JSON system where possible is preferred, though.

Override Block#getFlammability and Block#getFireSpreadSpeed.

Once you've done this, make sure you don't install 1.11.2 mods in the 1.8.9 profile and vice versa.

Set a different game directory for each launcher profile.

Not that know of. Look at the examples I linked and the IRecipeFactory implementations in CraftingHelper.init.

There have been a few other threads about this, including this one where I just explained how to add recipes to someone else.

Either use a JSON file for the recipe (recommended) or create the recipe in code and register it with ForgeRegistries.RECIPES. Those methods are deprecated and non-functional (and will probably be removed). I have some examples of recipe files here and the recipe/ingredient classes used by them (apart from the Vanilla/Forge ones) here. LexManos has some prototype examples here.

"Not working" doesn't tell us anything. If you want help with a problem, describe exactly what's not working and post the relevant code.

Bukkit is dead, so nobody's going to develop a Bukkit API for modern versions of Forge. Sponge is plugin API that was created after the death of Bukkit and supports both Vanilla and Forge.

Due to the nature of Minecraft and Forge, Forge mods only support the Minecraft version that they were built for. The exceptions to this rule occur when not much was changed between Minecraft versions. 1.8.9 can load 1.8.8 mods, 1.10.2 can load 1.9 - 1.10 mods and 1.11.2 can load 1.11 mods.

Post the FML log (logs/fml-client-latest.log in the game directory) using Gist.

You probably still have the 1.12 version of Optifine installed in the same mods directory used by your 1.8.9 profile. You should set each profile to have its own game directory in the launcher, allowing them to have their own set of mods installed.

How did you install Forge? You need to use the installer to install all the libraries required by Minecraft and Forge.

There shouldn't need to be any pause between spawning items. What's more likely is that you're spawning the items on both the logical client and server, when you should only be doing so on the server. See Forge's documentation for an explanation of sides. If this isn't the case, post your actual code.