Changes

== Overall process ==

== Overall process ==

When setting up the environment for the first time, a gradle refresh triggers three things:

When setting up the environment for the first time or ForgeGradle determines the environment is out of data (changed access transformers, mappings, or forge version), a gradle refresh triggers three things:

# ForgeGradle downloads the MCPConfig zip for the file you're using, and triggers the extractSrg/createSrgToMcp task.

# ForgeGradle downloads the jar and MCPConfig zip and triggers the extractSrg/createSrgToMcp task.

# After that, it processes the jar - applies access transformers, side stripper and others

# After that, it processes the jar - applies access transformers from forge/userdev, SAS from forge, and decompiles.

# Finally, it patches and finalizes the code, ready for modder consumption.

# Finally, it patches and finalizes the code, ready for modder consumption.

# It is incredibly difficult to create mods using these obfuscated names. It requires immense patience to reverse-engineer the meanings behind each and every name, and to keep relating those names to what was already reverse-engineered. Although, tools do exist to make this process easier, such as IntelliJ IDEA plugins that provide naming hints automatically.

# It is incredibly difficult to create mods using these obfuscated names. It requires immense patience to reverse-engineer the meanings behind each and every name, and to keep relating those names to what was already reverse-engineered. Although, tools do exist to make this process easier, such as IntelliJ IDEA plugins that provide naming hints automatically.

# Because the obfuscation process takes place after compilation (the obfuscator operates on the compiled classes), the obfuscated names are not handled by the compiler. Thus, obfuscated classes may contain member<ref>'''member''' refers to class fields and methods.</ref> names that are invalid in the Java source language, but valid in compiled bytecode (like ☃ discussed earlier); this means that the decompiled source of the game is not immediately recompilable.

# Because the obfuscation process takes place after compilation (the obfuscator operates on the compiled classes), the obfuscated names are not handled by the compiler. Thus, obfuscated classes may contain member<ref>'''member''' refers to class fields and methods.</ref> names that are invalid in the Java source language, but valid in compiled bytecode (like ☃ discussed earlier); this means that the decompiled source of the game is not immediately recompilable.

# These obfuscated names are automatically generated by the obfuscator for each independent release. This means that the obfuscated names may change signficantly between any two versions, making it harder for mod developers to update mods between releases.

# These obfuscated names are automatically generated by the obfuscator for each independent release. This means that the obfuscated names may change significantly between any two versions, making it harder for mod developers to update mods between releases.

=== SRGification ===

=== SRGification ===

More information about each of these tools can be found at the link provided, as well as what each of these arguments do. A brief description is provided.

More information about each of these tools can be found at the link provided, as well as what each of these arguments do. A brief description is provided.

=== ForgeFlower ===  

=== ForgeFlower ===  

The decompiler used by ForgeGradle is a custom fork of [https://github.com/JetBrains/intellij-community/tree/master/plugins/java-decompiler/engine Jetbrains' FernFlower], called [https://github.com/MinecraftForge/ForgeFlower ForgeFlower].

The decompiler used by ForgeGradle is a custom fork of [https://github.com/JetBrains/intellij-community/tree/master/plugins/java-decompiler/engine Jetbrains' FernFlower], called [https://github.com/MinecraftForge/ForgeFlower ForgeFlower].

The game is split into two distributions; server and client.

The game is split into two distributions; server and client.

Because the server contains no rendering code, and the client contains none of the server-specific code (like the UI), this means there are differences between what can run on one side or the other.

Because the server contains no rendering code, and the client contains none of the server-specific code (like the UI), this means there are differences between what can run on one side or the other. Since the server is just a subset of the client, the client contains the server-only classes as well.

To get around this, we have a tool called Mergetool, which can search for the differences between two files (down to the function level) and merge them into one large (referred to as joined) jar file.

To get around this, we have a tool called Mergetool, which can search for the differences between two files (down to the function level) and merge them into one large (referred to as joined) jar file. It also can also annotate those files as necessary.

It is a simple program, but it works.

It is a simple program, but it works.

A recap from earlier:

A recap from earlier:

* For classes -> <code>c_###_</code> (but it is immediately changed without the c_ being written to disk)

* For classes -> <code>C_###_</code> (but it is transparently remapped without the C_ being written to disk)

* For functions/methods -> <code>m_&lt;ID&gt;_</code>

* For functions/methods -> <code>m_&lt;ID&gt;_</code>

* For fields -> <code>f_&lt;ID&gt;_</code>

* For fields -> <code>f_&lt;ID&gt;_</code>

=== Patches ===

=== Patches ===

Once we have the source code ready to go, the final step in the setup is to apply patches.

Once we have the source code ready to go, the final step in the setup is to apply patches.

These are done trivially, using diffs and [https://github.com/MinecraftForge/BinaryPatcher BinaryPatcher].

These are done trivially using [https://github.com/MinecraftForge/DiffPatch DiffPatch].

== The Forge Side ==

== The Forge Side ==

=== Applying Patches ===

=== Applying Patches ===

The patches used for Forge itself are different from those used by MCPConfig, which means there are two separate patching stages performed.

The patches used for Forge itself at install time are different from those used by MCPConfig, which means there are two separate patching stages performed.

As opposed to the minimal MCPConfig patching, with the goal to make the code recompilable, the Forge patching is done to apply the API and modloader to the code.

As opposed to the minimal MCPConfig patching, with the goal to make the code recompilable, the Forge patching is done to apply the API and mod loader to the code.

It does this in a very similar way, with the [https://github.com/MinecraftForge/BinaryPatcher BinaryPatcher] utility.

It does this in a very similar way, with the [https://github.com/MinecraftForge/BinaryPatcher BinaryPatcher] utility.

There is not much left to do but package the code into a jar file, and place it into the gradle cache (so that this process does not occur every single time the project is opened). It calculates this name based on many factors, and this is covered in the [[ForgeGradle#naming|naming]] article.

There is not much left to do but package the code into a jar file, and place it into the gradle cache (so that this process does not occur every single time the project is opened). It calculates this name based on many factors, and this is covered in the [[ForgeGradle#naming|naming]] article.

== Some additional Infos ==

== Some Additional Info ==

# You will never see c_XXX_ for classes, because the class names are picked beforehand using the official mapping classnames

# You will never see C_XXX_ for classes, because the class names are picked beforehand using the official mapping class names

# If you look into the JAR, you won't see any packages for the obfuscated classes, but the deobfuscated classes do have the packages, this is because the same process that names the classes, also decides what package they belong to

# If you look into the JAR, you won't see any packages for the obfuscated classes, but the deobfuscated classes do have the packages, this is because the same process that names the classes, also decides what package they belong to