LexManos

cpw is still working on the replacement for LaunchWrapper. But ya, possibly, we'll see. It depends on if java breaks backwards compatibility again. They usually don't so we should be good.

1) THats not a Forge log 2) That just says that it couldn't find the file. So either you dont have access to read that file, or it doesn't exist. 3) That's 1.7.10... stop.

Optifine 'works' by doing dirty hacks into the jar file. Forge uses our https://github.com/Mojang/LegacyLauncher LaunchWrapper system. Which allows us and the rest of the MC community to edit the loaded classes on the fly, and thus skirt around some legal issues. Amungst other things. J9 screwed up the classpath which means our system for editing classes doesn't work. Cpw is working on a replacement and will be functional for 1.13+

1) You have Java9 Installed, Minecraft/Forge will not work on Java9, please use Java8 2) You are trying to run the universal.jar Which is NOT the installer. The installer is called... installer... The universal jar is one of the things the installer installs. The other things are all the required libraries. So.. go download the installer, and run it. It should popup a window asking if you want to install the server or the client and where you want to install it to. Typically for the client, just leave the target directory default if you're just running the Mojang launcher normally.

Overrides.

Well since that field has no @Holder annotation then you're always gunna have null as nothing ever sets it. As for when things can be null with the holder annotation, that can happen when the capability is never registered. Which is one of the main points of the capability system to allow you to have soft links to other dependancies. You should always be checking the Capability<> instances for NULL before using them. You also shouldn't be holding the cap instance in a strongly typed field unless you've already guarded the call it's in with a null check.

1) Those are the correct hashes, if you get something else then you're getting an incorrect file. That's the POINT of the hashes... 2) Stop modding for 1.6.4, you won't get support here. Seriously dude... Its been years, update.

You need to talk to Thermal Expansion it would appear to be them crashing based on what you said. Or you could use a NBT editor to kill the itemstack in your inventory. Neither of this is cause by Forge.

Humm.... I'm just going to assume you're actually misinformed but no, Java is NOT compiled at runtime. Java is all precompiled. So there is no files in the jar you can just 'edit'. Anyways. The Observer issue is a bug that was fixed several months ago. Again if you would just update you wouldn't run into these issues. As for 1.12 vs 1.12.2. Diesiben is correct, modders should update. Its only a minor change, if any, that they need to do. Please stop arguing with our moderators when they are answering your questions.

Try gradlew cleanCache That should nuke your cache folder and let it rebuild. However this shouldn't happen at all. YOu may want to try updating your referenced Forge to 1.12.2 not 1.12.

We're going to writeup something soon, but for now nothing is collected. We have shut down the servers. They were costing WAY to much for NO benefit. So until things get actually written to a nice aggregated front end, we've stoped gathering anything. But beyond that, you can see everything it did gather here: https://github.com/MinecraftForge/Mercurius/tree/master/src/main/java/net/minecraftforge/mercurius/dataModels

No its not you need to use some form of proxy between the different servers so the client thinks its connected to a single server.

You'll be fine as long as you don't have special mods installed. To solve your issue, just install a 1.12.2 version of Forge....

The official answer, and the only one I will encourage or endorse people to do. Is to actively develop your mod for the current stable version of Minecraft. Backporting only bug fixes and other NECESSARY things. As for 1.12.1 vs 1.12.2... Just go with the .2, As stated, sub releases exist for a reason. Bugs get fixed. Users should update.

If you can take a screenshot of the advert including the address bar I can go directly to our advertisers and have it removed. This stuff should not be making it through and we take it seriously.

For performance reasons you need to be weary of when you do this as there are thousands, perhaps hundreds of thousands of recipes. So searching it takes some time. So do it as rarely as you can, and cache the results.

User was banned for using a cracked launcher.

I'm looking into ways to deal with upgrading worlds for 1.13. But honestly, it's not looking good. Vanilla's flattening code is... bad... at least for modded entries. We'll see if we can figure things out. But most likely, due to modders not providing data, and the way Vanilla code is written 1.12 worlds won't be 1.13 compatible. HOWEVER, as for your specific request. You'd want to do data fixers.

'ForgeMultiPart' as never a part of Forge. It was always ChickenBones.

Quit spamming our forums with this crap. Yes it is possible. No we will not write it for you. Talk to the people who made the software you're showing in your images. If they have half brain they can make it work in Minecraft. BUT beyond that, don't do it as it's against Mojang's EULA.

That tutorial is dumb. It's close, but dumb. Extract the MDK to whatever folder you want your project in. Run gradlew setupDecompWorkspace eclipse In eclipse File -> Import -> Existing Project -> Your folder. There is no special 'Forge' folder or anything. Your project is your project.

Extract this to your .minecraft folder: http://files.minecraftforge.net/libraries.zip

You can tell it which java to use by specifying the full path to java.exe instead of just 'java'

We do write cofh mods. Speak to the COFH team not us. We are Forge.

Long story short, this forum will not help you build or distribute modifications to the base class files. Be it 'jar-mod' style, or coremod style. This is nothing but detrimental to the community because it is used to make nothing but incompatible by nature mods. So we won't help you. Now, if you want to learn the concepts of the process. That's fine as it's an interesting tech that we have spent several years trying to perfect. Minecraft is Released. Myself, or others on the MCP team update the MCP mapping files. Which is the translation list of 'a' -> Block 'b' -> World, This is a hard, long, tedious process. You're welcome. Rebuild the joined jar file by merging the client and server jars Mojang ships as they both strip different parts of the code. This is done with basic ASM/set merging. Rename the joined jar to the MCP names made in step 2. There are many tools that allow you to do this. ASM even comes with a slightly broken default implementation for this. Run that renamed jar through a decompiler, we use a heavily modified version of FernFlower to fix a few hundred of the issues that it currently has. Then modify that resulting source code to have your changes. Recompile that source Rename that binary using the opposite MCP mappings. Strip out the parts that arnt for the 'side' that you want to target. There you go, you have class files that can replace the classes in the jars shipped by Mojang. There, you now have a basic outline of how the development side of 'jar-mods' is done. Again, don't do this in the real world. It's BAD. It will do nothing but bring us bak to the dark ages of painful installs, incompatible mods, and PITA support we have to do.