Choonster

If you remove the extracted mods, yes.

You've now uploaded the log correctly. As I said previously, the issue is that you have extracted mods in your mods directory:

Just drag the file anywhere on the page except the large textbox in the middle.

You're meant to upload the log to Gist (which I explained in detail how to do) and link it here. You're not meant to copy the log directly into your post. Anyway, this is the issue: Don't extract mods, just put the JARs in the mods directory.

Open the launcher profile, then click the green arrow next to the "Game directory" option to open the game directory. Open the logs directory located in the game directory and find the fml-client-latest.log file. Open Gist in your web browser. Drag the fml-client-latest.log file from the logs directory onto the Gist web page. The page will become darker and say "Drop one or more files here to prefill your gist!". When you see this, drop the file onto the page (release the mouse button) and the textbox in the middle will be filled with the log's contents. Click "Create secret gist" or "Create public gist" and wait for the file to be uploaded. Copy the URL from the web browser's address bar. Paste the URL into a reply here.

The profile in the Minecraft Launcher determines where the game directory is. If you haven't changed it for the profile, it will be the same directory that the launcher is installed in.

I'm not entirely sure what you mean. The FML log is in the logs directory, which is in the game directory. The FML log isn't in the game directory itself.

Open the Gist website and then drag the file from the logs directory you have open in File Explorer (or your OS's equivalent) onto the web browser, you should see the page become darker and say "Drop one or more files here to prefill your gist!". When you see this, drop the file onto the page (release the mouse button) and the textbox in the middle should be filled with the log's contents.

You need to shade the MySQL connector into your JAR using the Gradle Shadow plugin. You can see how I shade a dependency in my mod here. Make sure you relocate the MySQL connector's packages when shading to avoid conflicts with other mods. This will automatically use the new package names in your code, but not in strings (e.g. the string you pass to Class.forName).

I tried to explain it as simply as I could. Was there a particular part you didn't understand?

Open the Minecraft game directory (.minecraft or whatever you've set it to in the launcher profile) then open the logs directory and look for the fml-client-latest.log file in it. Open the Gist website in your web browser and then drag the file onto it. Click "Create secret gist" or "Create public gist", wait for the file to upload and then copy the URL from your web browser's address bar into a reply here.

Post the FML log (logs/fml-client-latest.log in the game directory) using Gist or Pastebin. It should say what the problem is.

You've marked the thread as solved, but you haven't posted the solution. In future, please do this so other people can find it in future. Loader.isModLoaded requires the mod ID, not the mod name (despite the parameter's name).

YouTubeCommand#processCommand checks if World#isRemote is false, i.e. if the code is being called on the logical server. Since you register it with the client command handler, it will only ever be called from the logical client and the method won't do anything. Is it meant to be a client command or a server command? If it's the former, check for the logical client rather than the logical server (or don't check at all, it will only ever be called on the side you register it for). If it's the latter, you need to register it in FMLServerStartingEvent using FMLServerStartingEvent#registerServerCommand. If your command has sub-commands, you can extend CommandTreeBase and register each sub-command with CommandTreeBase#addSubcommand.

Which version of Forge are you using? The logging of missing models was broken in Forge 1.12-14.21.0.2363 (commit dc043ac) and fixed in Forge 1.12-14.21.1.2390 (commit ede05a2). Please create a Git repository of your mod on a site like GitHub and link it here. See my mod and its .gitignore file for an example of which files to include.

This has nothing to do with the texture pack, this is caused by using an outdated version of OptiFine. This particular issue was fixed in OptiFine 1.11.2_HD_U_B7 (field_78286_d is the obfuscated name of FontRender.charWidth) Because OptiFine is a coremod that messes with a lot of Minecraft's internals, it only supports specific versions of Forge. The changelog for each version of OptiFine says which Forge version it's compatible with. Side note: There's no Java involved in texture packs. You may be thinking of JSON, the format used by blockstates files, models, etc.

It was added in Forge 1.11.2-13.20.0.2289, so you're probably using an older version.

Why not?

When the server-to-client packet is received by the client, you can access the current GUI from the Minecraft#currentScreen field. If it's an instance of your GUI class, you can update it with the data from the packet.

Forge's documentation explains that here.

It looks like ModItems.goldshotbow was null when ModelRegistryEvent was fired, which likely means that no Item was registered for the name unnamedmod:goldshotbow at that time (either because it's the wrong name or the Item was registered later). Where are you registering these Items?

Forge's documentation has an explanation of registry events here.

You need to tell the method which registry contains the registry entry you're trying to read. In this case, it's the SoundEvent registry (ForgeRegistries.SOUND_EVENTS). That said, Minecraft already has methods to play a sound from the logical server. Forge's documentation lists the methods and explains what each one does here.

Blocks are singletons, there's only one instance per block type. This means that a Block can't have a single IBlockState, BlockPos or World field, since a Block can have any number of valid states at any number of positions in any number of dimensions. Instead, any method that needs access to the these receives them as parameters.

Just send another packet. The return value of IMessageHandler#onMessage is largely useless now that packets are handled on a network thread and all the logic needs to be run on the main thread.