User:ChampionAsh5357/1.17.1/Toolchain - Revision history

ChampionAsh5357: Remove userdev related information for now

2021-08-19T22:33:58Z

Remove userdev related information for now

ChampionAsh5357: Update updates we love updates

2021-08-19T18:17:03Z

Update updates we love updates

ChampionAsh5357: Fix bad formatting.

2021-08-19T18:13:09Z

Fix bad formatting.

ChampionAsh5357: Fix my stupidity part 3

2021-08-19T18:12:14Z

Fix my stupidity part 3

ChampionAsh5357: Part two of making the example config json more confusing

2021-08-19T18:07:30Z

Part two of making the example config json more confusing

ChampionAsh5357: Dealing with all of Curle's comments

2021-08-19T18:03:26Z

Dealing with all of Curle's comments

ChampionAsh5357: Fix a link

2021-08-19T17:22:54Z

Fix a link

ChampionAsh5357: Attempt number 2 at updating, still have only a rough idea here about the toolchain

2021-08-19T17:21:22Z

Attempt number 2 at updating, still have only a rough idea here about the toolchain

ChampionAsh5357: Maybe an updated toolchain?

2021-08-07T05:54:14Z

Maybe an updated toolchain?

Show changes

ChampionAsh5357: Update start info

2021-08-05T22:24:50Z

Update start info

@@ Line 12: / Line 12: @@
 # Finally, it patches and finalizes the code, ready for modder consumption.
-This can either be triggered whenever an environment is first being set up, or when ForgeGradle determines the existing environment is out of date whether from changed access transformers, mapping sets, or the current forge version.
+This is triggered whenever the <code>setup</code> task is ran.
 == Needed knowledge ==
@@ Line 142: / Line 142: @@
 == The Forge Side ==
-When Forge is first synced, it prepares the files for setting up the workspace.
+When Forge is first loaded by gradle, it prepares the files for setting up the workspace.
 The initial setup is done through the <code>gradlew setup</code> task. It will run the SetupMCP tasks and then start applying the Forge system to the processed vanilla code. After the MCPConfig/SetupMCP tasks are finished, ForgeGradle will print '''MCP Environment Setup is complete''' and continue. The text '''pausing after requested step''' is also printed twice during this task such that some necessary data can be extracted.

@@ Line 142: / Line 142: @@
 == The Forge Side ==
-When the Forge is first synced, it prepares the files for setting up the workspace.
+When Forge is first synced, it prepares the files for setting up the workspace.
-The initial setup is done through the <code>gradlew setup</code> task. It will run the SetupMCP tasks and then start applying the Forge system to the processed vanilla code. After the MCPConfig/SetupMCP tasks are finished, ForgeGradle will print '''MCP Environment Setup is complete''' and wait for the user input.
+The initial setup is done through the <code>gradlew setup</code> task. It will run the SetupMCP tasks and then start applying the Forge system to the processed vanilla code. After the MCPConfig/SetupMCP tasks are finished, ForgeGradle will print '''MCP Environment Setup is complete''' and continue. The text '''pausing after requested step''' is also printed twice during this task such that some necessary data can be extracted.
 First, it applies ATs. After that, patches. Finally, the official mappings, or some other mappings from a provider like Parchment, are applied.

@@ Line 62: / Line 62: @@
 ** java -jar &lt;version&gt; &lt;args&gt; &lt;jvmArgs&gt;
-{{Tip|A config.json can be found [https://github.com/MinecraftForge/MCPConfig/blob/master/versions/release/1.17.1/config.json here] which defines the following steps:
+{{Tip|content=A config.json can be found [https://github.com/MinecraftForge/MCPConfig/blob/master/versions/release/1.17.1/config.json here] which defines the following steps:
 * [[Toolchain:ForgeFlower|fernflower]]
 ** version: net.minecraftforge:forgeflower:1.5.498.12

@@ Line 62: / Line 62: @@
 ** java -jar &lt;version&gt; &lt;args&gt; &lt;jvmArgs&gt;
-A config.json can be found [https://github.com/MinecraftForge/MCPConfig/blob/master/versions/release/1.17.1/config.json here] which defines the following steps:
+{{Tip|A config.json can be found [https://github.com/MinecraftForge/MCPConfig/blob/master/versions/release/1.17.1/config.json here] which defines the following steps:
 * [[Toolchain:ForgeFlower|fernflower]]
 ** version: net.minecraftforge:forgeflower:1.5.498.12
@@ Line 74: / Line 74: @@
 ** args: --jar-in {input} --jar-out {output} --mapping-format tsrg2 --mappings {mappings} --fernflower-meta --cfg {libraries} --create-inits --fix-param-annotations
-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 ===
@@ Line 142: / Line 142: @@
 == The Forge Side ==
-After the MCPConfig/SetupMCP tasks are finished, ForgeGradle will print '''MCP Environment Setup is complete''' and wait for the user input.
+When the Forge is first synced, it prepares the files for setting up the workspace.
-When running the <code>gradlew setup</code> task, it will rerun the SetupMCP tasks and then start applying the Forge system to the processed vanilla code.
+The initial setup is done through the <code>gradlew setup</code> task. It will run the SetupMCP tasks and then start applying the Forge system to the processed vanilla code. After the MCPConfig/SetupMCP tasks are finished, ForgeGradle will print '''MCP Environment Setup is complete''' and wait for the user input.
 First, it applies ATs. After that, patches. Finally, the official mappings, or some other mappings from a provider like Parchment, are applied.

@@ Line 62: / Line 62: @@
 ** java -jar &lt;version&gt; &lt;args&gt; &lt;jvmArgs&gt;
-It defines the steps:
+A config.json can be found [https://github.com/MinecraftForge/MCPConfig/blob/master/versions/release/1.17.1/config.json here] which defines the following steps:
 * [[Toolchain:ForgeFlower|fernflower]]
 ** version: net.minecraftforge:forgeflower:1.5.498.12
@@ Line 73: / Line 73: @@
 ** version: net.minecraftforge.lex:vignette:0.2.0.10
 ** args: --jar-in {input} --jar-out {output} --mapping-format tsrg2 --mappings {mappings} --fernflower-meta --cfg {libraries} --create-inits --fix-param-annotations
 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.

@@ Line 7: / Line 7: @@
 == Overall process ==
-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:
+Whenever a gradle refresh is triggered, a few things occur:
 # ForgeGradle downloads the jar and MCPConfig zip and triggers the extractSrg/createSrgToMcp task.
 # 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.
 == Needed knowledge ==
 === Obfuscation ===
-'''Obfuscation''' is the process of renaming all of the fields, methods, and classes of the compiled code into unreadable, machine-generated names (such as <code>aaa</code>, <code>bC</code>), and removing package structures (this makes everything package-local and makes the obfuscated code smaller somewhat. This is commonly used by companies to prevent external entities from easily decompiling their released binaries/executables and retrieving their source code/intellectual property, though it does have size advantages.
+'''Obfuscation''' is the process of renaming all of the fields, methods, and classes of the compiled code into unreadable, machine-generated names (such as <code>aaa</code>, <code>bC</code>), and removing package structures (this makes everything package-local and makes the obfuscated code smaller somewhat. This is commonly used by companies to prevent external entities from easily decompiling their released binaries/executables and retrieving their source code/intellectual property.
 Additionally, due to the way the Local Variable Table (LVT) of Java bytecode is stored, every function-local variable name is turned to <code>☃</code> (that's right, a snowman) in the compiled files. This makes immediate recompilation of the game literally and physically impossible, as every Java compiler currently available requires that local variables have unique names.
@@ Line 40: / Line 42: @@
 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.
-An explanation of MCPConfig itself, how it works, what it's for (but NOT how to use it) can be found [[Toolchain:MCPConfig|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.
+An explanation of MCPConfig itself, how it works, what it's for (but NOT how to use it) can be found [[Toolchain:MCPConfig|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. 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.
@@ Line 59: / Line 61: @@
 * Once the step is all parsed in, it is executed:
 ** java -jar &lt;version&gt; &lt;args&gt; &lt;jvmArgs&gt;
 It defines the steps:
@@ Line 73: / Line 73: @@
 ** version: net.minecraftforge.lex:vignette:0.2.0.10
 ** args: --jar-in {input} --jar-out {output} --mapping-format tsrg2 --mappings {mappings} --fernflower-meta --cfg {libraries} --create-inits --fix-param-annotations
 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 ===
-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] which searches the jar for files, cleans up the bytecode, and then converts it into a reasonable best-guess interpretation.
-It simply searches the jar for files, cleans up the bytecode, and then converts it into a reasonable best-guess interpretation.
+It also produces the following side effects:
 * Removes synthetic parameters from constructors
 ** In bytecode, inner classes have the outer class as their first constructor parameter, but Java source code does not.
@@ Line 101: / Line 101: @@
 === Mergetool ===
-The game is split into two distributions; server and client.
+The game is split into two distributions; server and client. 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. It also can also annotate those files as necessary.
@@ Line 112: / Line 110: @@
 Vignette is where SRG starts to come into play. It serves the role of our deobfuscator, performing deobfuscation.
-This process is done with the help of a '''deobfusation map''', a file generated by the original obfuscator (in this case, ProGuard) that contains a map of the obfuscated names to original, non-obfuscated names. This is commonly used on debofuscating stack traces outputted by an obfuscated program, for debugging purposes.<ref name="retrace"/>
+This process is done with the help of a '''deobfusation map''', a file generated by the original obfuscator (in this case, ProGuard) that contains a map of the obfuscated names to original, non-obfuscated names. This is commonly used on deobfuscating stack traces outputted by an obfuscated program, for debugging purposes.<ref name="retrace"/>
 We have three sets of deobfuscation maps available to us; the obf->SRG mappings distributed with the MCPConfig system, the Yarn intermediary system, or the official mappings.<ref name="mojmappings"/>.
@@ Line 142: / Line 140: @@
 === 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  [https://github.com/MinecraftForge/DiffPatch DiffPatch].
+These are done trivially using [https://github.com/MinecraftForge/DiffPatch DiffPatch].
 == The Forge Side ==
@@ Line 148: / Line 146: @@
 After the MCPConfig/SetupMCP tasks are finished, ForgeGradle will print '''MCP Environment Setup is complete''' and wait for the user input.
-The next step is to run the <code>gradlew setup</code> task, which does what it implies: Applying the Forge system to the processed vanilla code.
+When running the <code>gradlew setup</code> task, it will rerun the SetupMCP tasks and then start applying the Forge system to the processed vanilla code.
-First, it applies ATs. After that, patches. Finally, the official mappings are applied.
+First, it applies ATs. After that, patches. Finally, the official mappings, or some other mappings from a provider like Parchment, are applied.
 All in all, compared to the MCPConfig setup, this is a string of extremely basic tasks - mostly just one-line commands.
@@ Line 161: / Line 159: @@
 * <code>AccessTransformers.jar --inJar {input} --outJar {output} --logFile accesstransform.log --atFile {at.cfg}</code>
-[https://github.com/MinecraftForge/MinecraftForge/blob/1.17.x/src/main/resources/META-INF/accesstransformer.cfg The current AT cfg can be found here.]
+[https://github.com/MinecraftForge/MinecraftForge/blob/1.17.x/src/main/resources/META-INF/accesstransformer.cfg The AT cfg for Forge can be found here.]
 === Applying Patches ===
-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.
+The patches used for Forge itself 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 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 used at install time/during a CI build or [https://github.com/MinecraftForge/DiffPatch DiffPatch] in all other situations.

@@ Line 35: / Line 35: @@
 The SRG name of the member is then derived from its SRG ID and its type (method {given the prefix <code>m_</code>}, field {given the prefix <code>f_</code>}, or parameter {given the prefix <code>p_</code>}). <ref>The SRG name for a given member is only created once, when it first appears in the code.</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:Vignette|Vignette]]. 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#Vignette|Vignette]]. More information on how it works can be found on that page.
 == The Setup ==

@@ Line 7: / Line 7: @@
 == 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.
@@ Line 25: / Line 25: @@
 # 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.
-# 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 ===
@@ Line 75: / Line 75: @@
 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 ===
 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].
@@ Line 107: / Line 103: @@
 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.
@@ Line 135: / Line 131: @@
 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 fields -> <code>f_&lt;ID&gt;_</code>
@@ Line 146: / Line 142: @@
 === 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 ==
@@ Line 169: / Line 165: @@
 === 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.
@@ Line 191: / Line 187: @@
 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

@@ Line 9: / Line 9: @@
 When setting up the environment for the first time, a gradle refresh triggers three things:
 # ForgeGradle downloads the MCPConfig zip for the file you're using, and triggers the SetupMCP task.
-# After that, it processes the jar - applies access transformers, MCPCleanup and others
+# After that, it processes the jar - applies access transformers, side stripper and others
-# Finally, it patches and finalises the code, ready for modder consumption.
+# Finally, it patches and finalizes the code, ready for modder consumption.
 == Needed knowledge ==
@@ Line 33: / Line 33: @@
 Each obfuscated class, method, and field is assigned a unique number by the [[Toolchain:MCPConfig|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 and its type (method {given the prefix <code>m_</code>}, field {given the prefix <code>f_</code>}, or parameter {given the prefix <code>p_</code>}). <ref>The SRG name for a given member is only created once, when it first appears in the code.</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]]. 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:Vignette|Vignette]]. More information on how it works can be found on that page.
 == The Setup ==
@@ Line 47: / Line 47: @@
 === Download and parsing MCPConfig ===
-The first thing that ForgeGradle does upon initialising a first-time setup, is starting the [https://github.com/MinecraftForge/ForgeGradle/blob/e2ed49546abced95650635f81be071441ec60995/src/mcp/java/net/minecraftforge/gradle/mcp/task/SetupMCPTask.java#L91 SetupMCP] task.
+The first thing that ForgeGradle does upon initializing a first-time setup, is starting the [https://github.com/MinecraftForge/ForgeGradle/blob/a0d2d1f488b3285ef7c75367feeebbe1a38aa19b/src/mcp/java/net/minecraftforge/gradle/mcp/tasks/SetupMCP.java#L74 SetupMCP] task.
-This task then seeks to [https://github.com/MinecraftForge/ForgeGradle/blob/e2ed49546abced95650635f81be071441ec60995/src/mcp/java/net/minecraftforge/gradle/mcp/task/DownloadMCPConfigTask.java#L78 download the MCPConfig.zip jar] for the version you're setting up.
+This task then seeks to [https://github.com/MinecraftForge/ForgeGradle/blob/a0d2d1f488b3285ef7c75367feeebbe1a38aa19b/src/mcp/java/net/minecraftforge/gradle/mcp/tasks/DownloadMCPConfig.java#L68 download the MCPConfig.zip jar] for the version you're setting up.
 Once it is acquired, it
-[https://github.com/MinecraftForge/ForgeGradle/blob/e2ed49546abced95650635f81be071441ec60995/src/mcp/java/net/minecraftforge/gradle/mcp/util/MCPRuntime.java#L74 parses the steps contained within the config.json]. It does this by interpreting the file with the following rules:
+[https://github.com/MinecraftForge/ForgeGradle/blob/a0d2d1f488b3285ef7c75367feeebbe1a38aa19b/src/mcp/java/net/minecraftforge/gradle/mcp/util/MCPRuntime.java#L75 parses the steps contained within the config.json]. It does this by interpreting the file with the following rules:
 * Every key, except for libraries, is interpreted as the name of a step.
 * Steps are executed in order.
@@ Line 60: / Line 60: @@
 ** java -jar &lt;version&gt; &lt;args&gt; &lt;jvmArgs&gt;
-An example config.json can be found [https://github.com/MinecraftForge/MCPConfig/blob/master/versions/release/1.16.4/config.json here].
+An example config.json can be found [https://github.com/MinecraftForge/MCPConfig/blob/master/versions/release/1.17.1/config.json here].
 It defines the steps:
 * [[Toolchain:ForgeFlower|fernflower]]
-** version: net.minecraftforge:forgeflower:1.5.478.16
+** version: net.minecraftforge:forgeflower:1.5.498.12
 ** 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
 * [[Toolchain:Mergetool|merge]]
-** version: net.minecraftforge:mergetool:1.1.1:fatjar
+** version: net.minecraftforge:mergetool:1.1.3: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]]
-** version: net.md-5:SpecialSource:1.8.3:shaded
+** version: net.minecraftforge.lex:vignette:0.2.0.10
-** args: --in-jar {input} --out-jar {output} --srg-in {mappings}
+** args: --jar-in {input} --jar-out {output} --mapping-format tsrg2 --mappings {mappings} --fernflower-meta --cfg {libraries} --create-inits --fix-param-annotations
 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.
 === MCInjector ===