Creating JAR-Mods for MC-Versions without MCP

[Zeldinator]

I am well aware this question was already asked about a hundred times, but I still was unable to find the answer I am looking for. Due to the given circumstances there is no way around the issue (like using the awesomely easy to use and compatible Forge-Framework), I HAVE TO write a JAR-Mod, namely for the Version 1.8.9. No Class Transformers, no advanced ASM, plain old vanilla Minecraft with edited base classes. I already have quite some experience using MCP, but the fact that there is no "official" version of MCP 9.19 (for 1.8.8) leads me to my question: What is the "most efficient" way to work with the base classes without going crazy having to dig trough countless lines of obfuscation mappings?

Thanks for any ideas.

[Draco18s]

By not doing it.

Seriously, you asked on the Forge forums how to mod without using Forge?

[Zeldinator]

2 minutes ago, Draco18s said:

By not doing it.

Seriously, you asked on the Forge forums how to mod without using Forge?

Well, thats a point ;P

Actually Im asking in a forum full of very experienced Minecraft mod developers for Support with a technology Forge ITSELF is built on.

[Draco18s]

Forge itself is built on Magic.

Installation is a package that contains patch files (these are essentially text documents that tell the program how to identify parts of the original code and then what to change). This is done after deobfuscating the original source into something more functional (also called SRG names). How this is done, I don't actually know, but this is how Forge can distribute the changes it makes to vanilla code without requiring the user to do anything other than "download and run this program" and without distributing any of Mojang's code.

SRG -> MCP is done at runtime.

Runtime stuff is largely based around Class Loaders which are a kind of class that tells the JVM how to load other classes.

 

If you are not familiar with any of these concepts, stop now.

Mostly because folks here aren't going to teach you these things, one because its not our job, and two, because these kinds of things are dangerous.

[Zeldinator]

36 minutes ago, Draco18s said:

If you are not familiar with any of these concepts, stop now.

Mostly because folks here aren't going to teach you these things, one because its not our job, and two, because these kinds of things are dangerous.

Sadly I think you are seeing some kind of "8 year old 12h-a-day-playing salty PvP-player and scriptkiddie without any background knowledge", but I hope I can change your opinion on me: I started programming about five years ago and will celebrate my 3 "anniversary" in Java soon. I spend most of my spare time learning new techniques and do a lot of (private) proof of concepts on a wide range of topics. I am indeed familiar with the concepts you are stating due to various projects (the latest one being a bytecode injection of the client at runtime, obviously using all the amazing things like custom class loaders and bytecode manipulation using asm) and am also aware that forge uses all these things.

I think you misunderstood me considering the point "...with a technology Forge ITSELF is built on.", because i did not mean the "user-end" of the MDK, where the Minecraft code is fetched from the official sources, but how the FORGE MDK itself was initially created and the vanilla code was altered BEFORE the modified code was written into patch files and such - which, obviously, IS the Mod Development Kit by Searge (as stated in the 1.8.9 Forge Main Menu: "MCP 9.19")... which brings me back to my question:

Since I want to write a JAR-Mod for 1.8.9, and there is no official MCP for this version, is there a somewhat efficient/automated way to jar-mod or do I have to accept my fate and dig trough endless lines of A ---> SomeClass, AA ---> SomeOtherClass, AAA ---> EvenAnotherClass...

BTW.: Is there some similar tool to Immibis' "Bearded Octo Nemesis" to deobfuscate the 1.8.9.jar itself?

 

Quote

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

Seems Legit

Thanks for the Answer anyways.

[Draco18s]

14 minutes ago, Zeldinator said:

Sadly I think you are seeing some kind of "8 year old 12h-a-day-playing salty PvP-player and scriptkiddie without any background knowledge"

That describes about 70% of the people who post here for the first time. You can see this thread if you really want to cringe over how bad it is sometimes.

 

15 minutes ago, Zeldinator said:

but how the FORGE MDK itself was initially created and the vanilla code was altered BEFORE the modified code was written into patch files and such

It isn't done that way any more due to the restrictions of the Minecraft EULA which states that no Vanilla code may be distributed. By modifying a vanilla class to insert a patch, then distributing the altered class file, falls under this restriction. Because of this, no one here will help you (learn how to) do that.

[Zeldinator]

13 minutes ago, Draco18s said:

That describes about 70% of the people who post here for the first time. You can see this thread if you really want to cringe over how bad it is sometimes.

Oh gosh... i guess this is some new level of cringyness...

13 minutes ago, Draco18s said:

It isn't done that way any more due to the restrictions of the Minecraft EULA which states that no Vanilla code may be distributed.

Well, It seems that I'm a catastrophic failure considering explaining what I mean... I actually meant the bytecode transformation that is done WHILE the MDK setup is running, editing the files LOCALLY on the computer, so you don't have to distribute the ALTERED class files, because it is done by the user.

25 minutes ago, Draco18s said:

By modifying a vanilla class to insert a patch, then distributing the altered class file, falls under this restriction. Because of this, no one here will help you (learn how to) do that.

Well, this is of course a point worth talking about... If we are talking about MCP, only the distribution of "altered vanilla classes" is in fact illegal, not transforming vanilla classes locally or even at runtime. Because if it would be - things like Optifine, which are based in this technique... and even Forge itself would be illegal as well.

So, with this in mind, if i just use MCP for testing and rewrite the altered stuff as bytecode transformation before releasing, what could be illegal using MCP or even (trying to) create my own version of it?

 

[Draco18s]

Forge is on Github.

https://github.com/MinecraftForge/MinecraftForge

I believe the patching is done by ForgeGradle, though:

https://github.com/MinecraftForge/ForgeGradle

[LexManos]

Long story short, this forum will not help you build or distribute modifications to the base class files. Be it 'jar-mod' style, or coremod style. This is nothing but detrimental to the community because it is used to make nothing but incompatible by nature mods. So we won't help you.

 

Now, if you want to learn the concepts of the process. That's fine as it's an interesting tech that we have spent several years trying to perfect.

Minecraft is Released.

Myself, or others on the MCP team update the MCP mapping files. Which is the translation list of 'a' -> Block 'b' -> World, This is a hard, long, tedious process. You're welcome.

Rebuild the joined jar file by merging the client and server jars Mojang ships as they both strip different parts of the code. This is done with basic ASM/set merging.

Rename the joined jar to the MCP names made in step 2. There are many tools that allow you to do this. ASM even comes with a slightly broken default implementation for this.

Run that renamed jar through a decompiler, we use a heavily modified version of FernFlower to fix a few hundred of the issues that it currently has.

Then modify that resulting source code to have your changes.

Recompile that source

Rename that binary using the opposite MCP mappings. 

Strip out the parts that arnt for the 'side' that you want to target. 

There you go, you have class files that can replace the classes in the jars shipped by Mojang. 

 

There, you now have a basic outline of how the development side of 'jar-mods' is done. 

Again, don't do this in the real world. It's BAD. It will do nothing but bring us bak to the dark ages of painful installs, incompatible mods, and PITA support we have to do.

[Zeldinator]

17 hours ago, LexManos said:

Myself, or others on the MCP team update the MCP mapping files. Which is the translation list of 'a' -> Block 'b' -> World, This is a hard, long, tedious process. You're welcome.

Jesus, you have to do the Mapping Updates BY HAND?! Wow, you got my deepest respect for this. Im curious, how many hours does the team spend altogether just for the Mapping part?

Well, i guess I underestimated the amount of work that goes into porting MCP, so... I'll need a different approach on the topic.

 

Thank you anyways for the information, I appreciate it.