Zeldinator

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.

Oh gosh... i guess this is some new level of cringyness... 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. 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?

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? Seems Legit Thanks for the Answer anyways.

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.

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.