Changes

20 bytes added ,  04:15, 27 July 2021
Copy Toolchain to MC1.16 archive
Line 31: Line 31:     
'''SRG''' stands for '''S'''earge's '''R'''etro '''G'''uard; RetroGuard being an early attempt to reverse the ProGuard obfuscation, and Searge being co-author of the Mod Coder Pack or MCP<ref>This was previously called the ''Minecraft Coder Pack''</ref>, who created this process.
 
'''SRG''' stands for '''S'''earge's '''R'''etro '''G'''uard; RetroGuard being an early attempt to reverse the ProGuard obfuscation, and Searge being co-author of the Mod Coder Pack or MCP<ref>This was previously called the ''Minecraft Coder Pack''</ref>, who created this process.
Each obfuscated class, method, and field is assigned a unique number by the [[Toolchain:MCPConfig|backend/1.16]], via a sequential counter. This unique number is called the '''SRG ID''' of that class/method/field (henceforth called member).
+
Each obfuscated class, method, and field is assigned a unique number by the [[Toolchain:MCPConfig/1.16|backend]], via a sequential counter. This unique number is called the '''SRG ID''' of that class/method/field (henceforth called member).
    
The SRG name of the member is then derived from its SRG ID, its type (function {given the prefix <code>func_</code>}, field {given the prefix <code>field_</code>}, or parameter {given the prefix <code>p_</code>, or <code>p_i</code> if this is the parameter of a constructor}), and (optionally) the obfuscated name of the object at the time it was given its SRG name<ref>The SRG name for a given member is only created once, when it first appears in the code. Therefore, the SRG postfix may be different from the current obf name.</ref>. This inclusion of the SRG ID into the name guarantees that the SRG name for all members are unique, and is the reason the ID is generated.
 
The SRG name of the member is then derived from its SRG ID, its type (function {given the prefix <code>func_</code>}, field {given the prefix <code>field_</code>}, or parameter {given the prefix <code>p_</code>, or <code>p_i</code> if this is the parameter of a constructor}), and (optionally) the obfuscated name of the object at the time it was given its SRG name<ref>The SRG name for a given member is only created once, when it first appears in the code. Therefore, the SRG postfix may be different from the current obf name.</ref>. This inclusion of the SRG ID into the name guarantees that the SRG name for all members are unique, and is the reason the ID is generated.
   −
The actual conversion of obf names to SRG names is done by a tool called [[Toolchain:SpecialSource|SpecialSource/1.16]]. More information on how it works can be found on that page.
+
The actual conversion of obf names to SRG names is done by a tool called [[Toolchain:SpecialSource/1.16|SpecialSource]]. More information on how it works can be found on that page.
    
== The Setup ==
 
== The Setup ==
 
The process can be broken up into 3 steps; MCPConfig, patch and provide.
 
The process can be broken up into 3 steps; MCPConfig, patch and provide.
 
The MCPConfig step is, understandably, the biggest and most prone to failure.
 
The MCPConfig step is, understandably, the biggest and most prone to failure.
An explanation of MCPConfig itself, how it works, what it's for (but NOT how to use it) can be found [[Toolchain:MCPConfig|here/1.16]]. For the purpose of this guide, you need only know that its' goal is to get the game decompiled, and into a state where it can immediately be recompiled. Due to certain flaws in the rest of the toolchain, this means it needs to fix and patch the source code before passing it onto Forge.
+
An explanation of MCPConfig itself, how it works, what it's for (but NOT how to use it) can be found [[Toolchain:MCPConfig/1.16|here]]. For the purpose of this guide, you need only know that its' goal is to get the game decompiled, and into a state where it can immediately be recompiled. Due to certain flaws in the rest of the toolchain, this means it needs to fix and patch the source code before passing it onto Forge.
    
In this way, MCPConfig can be thought of the vanilla side of the setup. It does not modify the game.
 
In this way, MCPConfig can be thought of the vanilla side of the setup. It does not modify the game.
Line 63: Line 63:     
It defines the steps:
 
It defines the steps:
* [[Toolchain:MCinjector|mcinjector/1.16]]
+
* [[Toolchain:MCinjector/1.16|mcinjector]]
 
** version: de.oceanlabs.mcp:mcinjector:3.8.0:fatjar
 
** version: de.oceanlabs.mcp:mcinjector:3.8.0:fatjar
 
** args: --in {input} --out {output} --log {log} --level=INFO --lvt=LVT --exc {exceptions} --acc {access} --ctr {constructors}
 
** args: --in {input} --out {output} --log {log} --level=INFO --lvt=LVT --exc {exceptions} --acc {access} --ctr {constructors}
* [[Toolchain:ForgeFlower|fernflower/1.16]]
+
* [[Toolchain:ForgeFlower/1.16|fernflower]]
 
** version: net.minecraftforge:forgeflower:1.5.478.16
 
** version: net.minecraftforge:forgeflower:1.5.478.16
 
** args: -din=1 -rbr=1 -dgs=1 -asc=1 -rsy=1 -iec=1 -jvn=1 -isl=0 -iib=1 -log=TRACE -cfg {libraries} {input} {output}
 
** args: -din=1 -rbr=1 -dgs=1 -asc=1 -rsy=1 -iec=1 -jvn=1 -isl=0 -iib=1 -log=TRACE -cfg {libraries} {input} {output}
 
** jvmargs: -Xmx4G
 
** jvmargs: -Xmx4G
* [[Toolchain:Mergetool|merge/1.16]]
+
* [[Toolchain:Mergetool/1.16|merge]]
 
** version: net.minecraftforge:mergetool:1.1.1:fatjar
 
** version: net.minecraftforge:mergetool:1.1.1:fatjar
 
** args: --client {client} --server {server} --ann {version} --output {output} --inject false"
 
** args: --client {client} --server {server} --ann {version} --output {output} --inject false"
* [[Toolchain:MCInjector|rename/1.16]]
+
* [[Toolchain:MCInjector/1.16|rename]]
 
** version: net.md-5:SpecialSource:1.8.3:shaded
 
** version: net.md-5:SpecialSource:1.8.3:shaded
 
** args: --in-jar {input} --out-jar {output} --srg-in {mappings}
 
** args: --in-jar {input} --out-jar {output} --srg-in {mappings}
Line 164: Line 164:  
* removing imports from the package a class is in
 
* removing imports from the package a class is in
 
* removing comments that include the phrase <code>GL_[^*]+</code>
 
* removing comments that include the phrase <code>GL_[^*]+</code>
* replacing [[Toolchain:Magic Constants|magic constants/1.16]] with their code substitutions
+
* replacing [[Toolchain:Magic Constants/1.16|magic constants]] with their code substitutions
 
* replacing <code>Character.valueOf(&lt;character&gt;)</code> with <code>&lt;character&gt;</code>
 
* replacing <code>Character.valueOf(&lt;character&gt;)</code> with <code>&lt;character&gt;</code>
 
* replacing OpenGL integer constants with their code representation
 
* replacing OpenGL integer constants with their code representation
Line 184: Line 184:  
=== Applying Access Transformers ===
 
=== Applying Access Transformers ===
   −
[[Access Transformers/1.16]] are a way of changing the visibility and finality of classes and class members. A full explanation of how it works, what the specification is, and what exactly they're used for, can be found at that page.
+
[[Access Transformers/1.16|Access Transformers]] are a way of changing the visibility and finality of classes and class members. A full explanation of how it works, what the specification is, and what exactly they're used for, can be found at that page.
    
They are applied by passing the AT Config (nowadays called accesstransformer.cfg) into SpecialSource:
 
They are applied by passing the AT Config (nowadays called accesstransformer.cfg) into SpecialSource:
Line 205: Line 205:  
These renames can come from any source; as mentioned earlier, the MCP/Crowdsourced naming, the Yarn naming, or the Mojang Obf-map naming. ForgeGradle does not care, as long as there is a valid SRG->names map.
 
These renames can come from any source; as mentioned earlier, the MCP/Crowdsourced naming, the Yarn naming, or the Mojang Obf-map naming. ForgeGradle does not care, as long as there is a valid SRG->names map.
   −
How ForgeGradle retrieves these mappings is covered in the [[ForgeGradle/mappings|appropriate article/1.16]].
+
How ForgeGradle retrieves these mappings is covered in the [[ForgeGradle/mappings/1.16|appropriate article]].
    
The process of renaming itself is a simple regex substitution, performed by [https://github.com/MinecraftForge/ForgeGradle/blob/e2ed49546abced95650635f81be071441ec60995/src/common/java/net/minecraftforge/gradle/common/util/McpNames.java#L104 ForgeGradle itself]. This is made possible by the assured uniqueness of SRG names.
 
The process of renaming itself is a simple regex substitution, performed by [https://github.com/MinecraftForge/ForgeGradle/blob/e2ed49546abced95650635f81be071441ec60995/src/common/java/net/minecraftforge/gradle/common/util/McpNames.java#L104 ForgeGradle itself]. This is made possible by the assured uniqueness of SRG names.
Line 213: Line 213:  
At this point, the files are ready to go. We have processed the Minecraft jar such that it can be recompiled, we have applied appropriate access transformers and the Forge patches, and optionally renamed every applicable SRG name to whatever chosen distribution of mappings.
 
At this point, the files are ready to go. We have processed the Minecraft jar such that it can be recompiled, we have applied appropriate access transformers and the Forge patches, and optionally renamed every applicable SRG name to whatever chosen distribution of mappings.
   −
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/1.16]] 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/1.16|naming]] article.
    
== Some additional Infos ==
 
== Some additional Infos ==
372

edits