Compatibility with Forge and/or ModLoader(MP)

[ThexXTURBOXx]

Compatibility with ML(MP) can be easily achieved by editing the client (and) server jar. However, Forge requires some patching procedure and so I am not sure if RetroMCP-Java is directly compatible with it. Is there any way to use Forge (and ML(MP)) with RetroMCP-Java or does this need additional changes inside RetroMCP-Java?

[PhoenixVX]

The best way to use Forge in RMCP-J is to use the reobfuscated binaries provided on SourceForge and other archives and decompile it alongside MC. Fernflower usually decompiles it without errors, but what it misses, are simple.

[Lassebq]

There is no full support for Forge and ML yet due to the lack of patches for decompiled source, however you can still edit jars in jars/ after running setup task. Be it patching or simply adding class files to a jar. Then you can run decompile on the modified jars and fix all errors that weren't patched automatically.

[ThexXTURBOXx]

Okay, thank you very much for the information. I succeeded in doing it with @PhoenixVX's approach. You can decide whether to leave this issue open. For me, this is kind of solved now

[serpent-charmer]

@ThexXTURBOXx Could you provide exact steps to add Forge to this MCP distribution? I've tried doing it myself but failed. Here is what i did:

1. Added contents of the client-forge.zip for 1.2.5 from Forge official site to minecraft.jar
2. Decompiled

3. Got bunch of decompilation errors

   Error on line 780 in src\minecraft\forge\MinecraftForge.java
   method next() is already defined in class forge.MinecraftForge.OreQuery.OreQueryIterator
   
   Error on line 576 in src\minecraft\forge\ForgeHooksClient.java
   int cannot be dereferenced
   
   Error on line 577 in src\minecraft\forge\ForgeHooksClient.java
   int cannot be dereferenced

[ThexXTURBOXx]

@serpent-charmer I also faced similar issues. In that case, you need to fix the sources yourself and then update the md5 hashes. After that, you are good to go, even though the sources will not exactly match the expected real ones.

[PhoenixVX]

You don't need to worry about the sources not matching the compiled classes. Only thing you need to worry about are the reobfuscation hashes to tell if these classes are edited, which updatemd5 exists for.

[ThexXTURBOXx]

Exactly. I just wanted to emphasize this because some people might wonder why their sources don't match, e.g., my ones.

[serpent-charmer]

@ThexXTURBOXx You have to be more specific. I need to fix original Forge src(forge-1.2.5-3.4.9.171-src) files then reobfuscate them, right? Any tips on how to do that? What version did you try adding Forge to?

[ThexXTURBOXx]

I was able to add Forge (and MLMP for that matter) to all versions which they are (respectively) available for (including the Forge downloads from SourceForge). As already said, you run setup and install Forge as always: By isntalling the client and server files to the minecraft.jar and minecraft_server.jar, respectively. After that, run decompile and you will see that it will try recompiling the sources in the end, which fails (most likely). Then, you need to fix the decompiled sources according to the error messages. Then, run updatemd5 as already said and it should be fine. You can now use your setup as usual.

[serpent-charmer]

Ah, ok, i didn't knew that there are usable src files in src folder even if decompilation fails and you can actually edit them. I've had preconception that i need to fix them beforehand so that. Still it's gonna be a hassle to get any decompiled mod up and running due to structure difference with old MCP. Thanks for help.

[PhoenixVX]

Well.... I guess the other option is for somebody to port all the patches to Diffpatch, which is Forge's current library for patching source code, that RMCP also uses.

[serpent-charmer]

What is basic workflow required to add a patch? I would also like to know if it will be much different from adding a new target version, for example 1.4.7?

[PhoenixVX]

The basic workflow for adding a patch is to decompile the game, and fix the sources, then use the createpatches command to generate patches in the root of the MCP folder. It will patch from the decompiled source to the fixed source (temp/client/src -> src/minecraft). As for adding a version, that requires numerous parts. First of which is to create a versions.json in the same folder as RetroMCP which will replace the version JSON gotten from the MCPHackers website. The next is to create or port mappings for said version either through Enigma or Matcher (can be used to match mappings from nearby versions). Next is to create patches if necessary (they haven't been necessary for versions after alpha. Next is to create Exceptor patches which fix methods to have throws SomeException. Finally, you should be able to make a workspace that does all this instantly.

If you want to look at the format, https://mcphackers.github.io/versions/versions.json is what is used for RetroMCP.

[serpent-charmer]

Ok, i'm thinking it might be useful to port old .srg(+ .csv files) mappings to new .tiny ones. Because as i see it fixing forge sources after adding it to .jar file is one thing. But there is also mod sources with different mapped names. I could add their obfuscated version to .jar and fix them along with the forge ones but i think it'll be easier with old mappings because you can use previous mod sources unchanged.

Is there such converter already? If not i would like to get any info about .tiny and old .srg mapping structure to try to write a converter.

[PhoenixVX]

I've created multiple converters for SRG to Tiny, but all of them are mainly only useful for a certain version range. As for the above, Forge is supposed to be decompiled alongside MC, do not use the Forge sources. The mappings will automatically adjust the source properly.

As for the Tiny mapping and SRG mapping spec, that's not all you need. You first need to know if you are going to be using Tiny v1 (doesn't preserve parameters, very similar to SRG) or Tiny v2 (Not similar to SRG), but in either case, it will require knowing ASM (thus Minecraft on the classpath) as SRG doesn't use signatures, but Tiny does. After that, you finally realize that mappings are NOT set in the SRG. The SRG just apply intermediary names to fields and methods, while mapping class names. The CSVs in the conf folder perform the remapping of SRG to named mappings, so you need to read the CSVs also.

In other words, it's a huge pain. I can probably help you get setup with this if you are on Modification Station though, and if I have time, I may even be able to write one for you.

Tiny v2 spec: https://github.com/FabricMC/tiny-remapper/issues/9

[Lassebq]

You can re-export SRGs as Tiny v2 straight from Enigma. Not sure why @PhoenixVX is overcomplicating it. And also, you shouldn't have any trouble adding mod sources if they used original MCP mappings, because that's what RetroMCP is using for all versions which were already in MCP (except for a1.1.1-a1.1.2_01). Other versions were mapped either from scratch or matched from another version.

[PhoenixVX]

The SRGs don't contain the mappings. They contain the intermediary names, unless you like field_1234_j and func_13843_a for fields and methods respectively, that is not useful to anyone.

[Lassebq]

Ones in conf are useless. You need SRGs from temp which are produced upon decompiling.

[PhoenixVX]

Normal MCP replaces the field and function names by path walking and seeing if the name matches. The SRGs in temp should be exactly the same as what is in conf.