77
edits
Changes
From Forge Community Wiki
Inital Import dokuwiki
This page will explain <code>decompile</code>-><code>deobfuscate</code>-><code>reobfuscate</code> process that forge uses when you install the <code>MDK</code>.
== Why we need to do this ==
Minecraft is a commercial game, which means the source code is locked away, and not only is the source code unavailable to us, but they obfuscate the game code.
If you look into the client/server JAR, you'll see that all the class names have short, nonsense names like <code>aa</code>, <code>ab</code>, <code>xy</code>, etc. This is called Obfuscating.
The problem is, we don't((Mojang recently released this information in what we call <code>mojmappings</code>, but the licensing is a bit iffy<ref name="license">[https://cpw.github.io/MinecraftMappingData For more info]</ref> have the information to convert those nonsensical names to readable, understandable names.
So we need a toolchain to make it possible for us to read the source code so we can mod the game.
For more information about [https://en.wikipedia.org/wiki/Obfuscation_(software) Obfiscating].
== Deobfuscation ==
First the obfuscated names need unique names. Since there could be some methods with the same name, the resulting code then would not compile.
For this all of these obfuscated classes/methods/fields are assigned a number. This number increments sequentially and is called the <code>SRG ID</code>((SRG stands for Searge, which was one of the co-founders of the original set of scripts and programs which did this in the beginning)) of that class/method/field, this ensures all these classes/methods/fields (henceforth called members) have a unique name.\\
These IDs are converted to <code>SRG</code> names, also called <code>Notch names</code>, simply by combining their ID and the type of member\\
<code>class</code> -> <code>c_XXX_</code> (you won't ever see this because of reasons, explained later)\\
<code>function</code> -> <code>func_XXX_</code>\\
<code>field</code> -> <code>field_XXX_</code>\\
<code>parameter</code> -> <code>p_XXX_X_</code> (there are two types of parameter names, also explained later)\\
These Ids will be gernerated automatically.
== Decompilation ==
More general [https://en.wikipedia.org/wiki/Decompiler info]
=== FernFlower/ForgeFlower ===
Forge uses [https://github.com/MinecraftForge/ForgeFlower ForgeFlower], which is a Fork of [https://github.com/MinecraftForge/FernFlower FernFlower].
FernFlower is a decompiler that takes the compiled Minecraft Jar and turn it in to semi readable source code.
Why semi readable?<br >
Because the decompiler has no sense of formatting or indentation.
== Mappings ==
We don't need this step but coding with the <code>SRG</code> names is hard and not really fun.
So we need to take the <code>SRG</code> names and make them more user friendly, the user friendly names are community sourced names.
Since <code>SRG</code> names are uniquely identifiable, due to the unique ID, it literally does a search-and-replace on all the source code text to do that <code>SRG</code>-><code>MCP</code>(( <code>MCP</code> stands for ModCoderPack (or previously, Minecraft Coder Pack) which was the toolchain that did all of this before the advent of ForgeGradle)) application.
== Some additional Infos ==
# You will never see c_XXX_ for classes, because the class names are picked beforehand
#* this is still crowdsourced, but before a new version is ready for Forge, all classes are given an <code>MCP</code> name
#* this <code>MCP</code> name stays constant throughout the game version it was picked for; it can change between versions, but it usually wont for already-named classes (except for misspells, typos, and misnames)
# 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
# parameters have special names
#* there are two types of parameter names: <code>p_XXX_X_</code> and <code>p_iXXX_X_</code>
#* the one with the i means that it's a parameter for a constructor
#* the first set of numbers are the SRG ID of their parent method, and the second number denotes the index of the parameter
#* the index of the parameter is a bit more involved, but this will not be explained here
# If you look into the source, you'll see that parameters for lambdas don't have mapped names
#* This is because of a complication in how the lambdas are compiled/decompiled; it's a more advanced topic which involves how the compiler compiles lambdas which we will not explain here.
== Reobfuscation ==
TBD
<references/>
== Why we need to do this ==
Minecraft is a commercial game, which means the source code is locked away, and not only is the source code unavailable to us, but they obfuscate the game code.
If you look into the client/server JAR, you'll see that all the class names have short, nonsense names like <code>aa</code>, <code>ab</code>, <code>xy</code>, etc. This is called Obfuscating.
The problem is, we don't((Mojang recently released this information in what we call <code>mojmappings</code>, but the licensing is a bit iffy<ref name="license">[https://cpw.github.io/MinecraftMappingData For more info]</ref> have the information to convert those nonsensical names to readable, understandable names.
So we need a toolchain to make it possible for us to read the source code so we can mod the game.
For more information about [https://en.wikipedia.org/wiki/Obfuscation_(software) Obfiscating].
== Deobfuscation ==
First the obfuscated names need unique names. Since there could be some methods with the same name, the resulting code then would not compile.
For this all of these obfuscated classes/methods/fields are assigned a number. This number increments sequentially and is called the <code>SRG ID</code>((SRG stands for Searge, which was one of the co-founders of the original set of scripts and programs which did this in the beginning)) of that class/method/field, this ensures all these classes/methods/fields (henceforth called members) have a unique name.\\
These IDs are converted to <code>SRG</code> names, also called <code>Notch names</code>, simply by combining their ID and the type of member\\
<code>class</code> -> <code>c_XXX_</code> (you won't ever see this because of reasons, explained later)\\
<code>function</code> -> <code>func_XXX_</code>\\
<code>field</code> -> <code>field_XXX_</code>\\
<code>parameter</code> -> <code>p_XXX_X_</code> (there are two types of parameter names, also explained later)\\
These Ids will be gernerated automatically.
== Decompilation ==
More general [https://en.wikipedia.org/wiki/Decompiler info]
=== FernFlower/ForgeFlower ===
Forge uses [https://github.com/MinecraftForge/ForgeFlower ForgeFlower], which is a Fork of [https://github.com/MinecraftForge/FernFlower FernFlower].
FernFlower is a decompiler that takes the compiled Minecraft Jar and turn it in to semi readable source code.
Why semi readable?<br >
Because the decompiler has no sense of formatting or indentation.
== Mappings ==
We don't need this step but coding with the <code>SRG</code> names is hard and not really fun.
So we need to take the <code>SRG</code> names and make them more user friendly, the user friendly names are community sourced names.
Since <code>SRG</code> names are uniquely identifiable, due to the unique ID, it literally does a search-and-replace on all the source code text to do that <code>SRG</code>-><code>MCP</code>(( <code>MCP</code> stands for ModCoderPack (or previously, Minecraft Coder Pack) which was the toolchain that did all of this before the advent of ForgeGradle)) application.
== Some additional Infos ==
# You will never see c_XXX_ for classes, because the class names are picked beforehand
#* this is still crowdsourced, but before a new version is ready for Forge, all classes are given an <code>MCP</code> name
#* this <code>MCP</code> name stays constant throughout the game version it was picked for; it can change between versions, but it usually wont for already-named classes (except for misspells, typos, and misnames)
# 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
# parameters have special names
#* there are two types of parameter names: <code>p_XXX_X_</code> and <code>p_iXXX_X_</code>
#* the one with the i means that it's a parameter for a constructor
#* the first set of numbers are the SRG ID of their parent method, and the second number denotes the index of the parameter
#* the index of the parameter is a bit more involved, but this will not be explained here
# If you look into the source, you'll see that parameters for lambdas don't have mapped names
#* This is because of a complication in how the lambdas are compiled/decompiled; it's a more advanced topic which involves how the compiler compiles lambdas which we will not explain here.
== Reobfuscation ==
TBD
<references/>