Choonster

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.

If you've set up your workspace correctly, the Minecraft and Forge source code should be available as the forgeSrc-<forgeVersion> referenced library. You can either browse to a class in the library or use Navigate > Class (Ctrl-N) in IDEA or Navigate > Go To > Type... in Eclipse. The Ender Dragon is implemented in the net.minecraft.entity.boss.EntityDragon class.

There should be an error in the log telling you why your recipes failed to load. You can't use "block" for ingredients/results (since Blocks don't exist in inventories), you need to use "item" with the registry name of the Block's Item form. Make sure you're using a recent version of Forge, recipe loading wasn't in the first few 1.12 versions. Your Git repository should contain everything necessary to build your mod, including the Gradle buildscript and wrapper. See my mod and its .gitignore file for an example of which files to include.

Those haven't changed in 1.12, add them in init as you would in earlier versions.

Just create JSON files for your recipes in the assets/<modid>/recipes directory and Forge will automatically load them. You don't need to tell it to do so. I have some examples of recipe files here and the recipe/ingredient classes used by them (apart from the Vanilla/Forge ones) here.

If you ever built your mod with the build Gradle task, you may have a source JAR in the build/libs directory of your mod's workspace. This will contain your source code obfuscated to SRG names. BON2 can deobfuscate a compiled JAR from SRG (obfuscated) to MCP (deobfuscated) names, but probably not a source JAR. You can then decompile it with a decompiler like Bytecode Viewer. The decompilation process isn't perfect and all comments are stripped during compilation, so the code you get out of it won't be exactly the same as the original code. If you use version control software like Git and host a copy of your repository on a site like GitHub, you can retrieve any version of your code. This will make it much less likely that you'll lose anything.

Set a breakpoint in the lambda with the condition p_194039_2_ == null. When the breakpoint is hit, look at the value of the element parameter to see which Item has a null registry name.

The PR has been merged, update to Forge 1.12-14.21.0.2342.

A Forge client should be able to connect to a vanilla server as long as none of the installed mods are required on the server side. You shouldn't need to do anything special to connect to a Realms server.

I've created a Pull Request to fix this crash here. If the PR is merged, this particular error will be logged like other syntax errors instead of crashing the game.

Any field whose type is a class that directly extends Object will become a config category, with its fields becoming properties or categories following the same rules as the top-level class. Map fields are also mapped to categories with properties as key-value pairs.

Registry events are fired before preInit, so you need to annotate the event handler class with @Mod.EventBusSubscriber to automatically register it at mod construction time (or register it manually). In addition to this, you're registering an instance of the event handler but your methods are static; which is incorrect. Static event handler methods require you to register the Class object rather than an instance, as explained in the documentation. You need to set the registry name of an IForgeRegistryEntry like Block or Item before you register it. Having a constructor modify static fields in a class where there there are no instance fields or methods and calling this constructor purely for the side-effects is very strange and probably a bad idea. If you need to do more stuff to the Items in preInit, create a regular static method instead of a constructor. ModelLoader is a client-only class and can't be referenced from common code. ModelRegistryEvent should be handled in a client-only class that's only registered with the event bus on the physical client (pass Side.CLIENT to the @Mod.EventBusSubscriber annotation or manually register it in a method only called on the physical client).

It's not absolutely required, but it's a good idea to avoid potential conflicts. All unlocalised names are used as keys in the same Map, so your unlocalised name's translation could overwrite or be overwritten by the same name from another mod. I recommend using the Item's registry name (IForgeRegistryEntry#getRegistryName) as the unlocalised name as it already includes the mod ID.

You need add the dependency repositories used by CoFH to your build.gradle file manually, JitPack doesn't seem to handle that automatically. Basically, copy the repositories from the repositories section of CoFHCore's build.gradle file into the repositories section of your build.gradle file. Use the repositories sections in the main body, not in the buildscript section. I also had to add the universal classifier to the CoFHCore dependency, e.g. deobfCompile 'com.github.CoFH:CoFHCore:f60b7b70fe:universal'.

One of your mods has added an invalid recipe via JSON. Unfortunately the crash report doesn't say which one, so you'll need to remove mods until it stops crashing to figure out which one it is.

Rename it to something other than .gradle (or move it to a different directory) so Gradle doesn't use the cached files stored in it. You can rename a folder to a name starting with a period from the command line with the rename command (in Command Prompt) or the Rename-Item cmdlet (in PowerShell).

Item#onArmorTick being called in the wrong place is a known issue. I'm not sure why the patches would fail to apply like that. It's possible that something in the Gradle cache is corrupted, you can try temporarily renaming the ~/.gradle directory (%USERPROFILE%\.gradle on Windows) and re-running the setupDecompWorkspace task.

You can also use CurseForge as a Maven repository, see the documentation. I explain this in more detail here.

This is a known issue. There's a Pull Request open to fix this, but it hasn't been merged yet.

Either use a wildcard in the parameter declaration or give the method a generic type argument and use that in the parameter declaration.

func_187246_z is loadPlayerBanList, which is the method responsible for loading the list of banned players from banned-players.json. This error was thrown because that file has a syntax error in it. Either fix the syntax error or delete the file and re-ban any banned players.

Are you subscribing to RenderLivingEvent.Specials.Pre<AbstractClientPlayer> directly, or are you subscribing to RenderLivingEvent.Specials.Pre and checking if the entity is an instance of AbstractClientPlayer? Only the latter will work in this case. Forge only performs generic filtering for events that implement IGenericEvent, which RenderLivingEvent.Specials.Pre doesn't. It's too expensive to do multiple times every frame, so it's generally only done for load-time events. Render#doRender (which is called by every class that overrides it) calls Render#renderName. RenderLivingBase overrides Render#renderName to fire RenderLivingEvent.Specials.Pre/Post and call Render#renderEntityName with the entity's display name. Render#renderEntityName calls Render#renderLivingLabel to render its argument. RenderPlayer overrides Render#renderEntityName to render the player's score with Render#renderLivingLabel and then call the super method.