How about a deobfuscator that automatically generates deobfuscated names, and therefore eliminates the need to download a separate mapping file. Each time it runs into a collision between a class name and a package name or function name or field name, or any combination of these that can cause a collision, it resolves the issues by generating a unique name such as class_1234 or something like that. It then scans all the other files for references to that class, package, function, or field, and fixes the references as required. It then increments the number portion of the name, each time it discovers a new class, package, function or field that needs renaming. The output of this deobfuscator is a jar file containing all of the renamed code, and also a separate mapping file that can be used to re-obfuscate later.
To make a mod, simply decompile the deobfuscated jar with whatever decompiler you prefer (such as JD GUI). Then after editing the source code, use whatever Java IDE you prefer (such as Netbeans) to recompile (or if you only need to recompile a few class files to make your mod, you can use javac.exe directly from the command line). The last step is to use the deobfuscator with the command line switch -reobfuscate, in conjunction with the map file auto-generated in the first step, to reobfuscate the class files in the output jar. This jar file would contain the modified and reobfuscated class files, which could then be directly copied into the original game jar file to replace the corresponding class files to install the mod.
Because no original mapping file would be needed, this would work on very old versions, for which the makers of MCP have not created mapping files, such as Classic and Indev versions of Minecraft. While such deobfuscated class names, method names, package names, and field names would not convey their purpose like level.class or something, any names involved in a collision would be changed to be absolutely unique with classes that got renamed so they would always start with "class_" and methods (functions) that got renamed would always start with "method_" etc. This GUARANTIES that they could be recompiled, as there would be no collisions between the names. And this means that simple edits to the source code could be performed, by simply looking at the source code and guessing the functionality of a given variable or function, based on the context in which it was being used (such as a String variable getting set to the name of a level file, indicates that the variable in question is being used in the level saving or loading process).
Because the deobfuscation process generates a mapping file, if that mapping file were in plain text (such as CSV), then when one did find the functionality of a class or function, they could manually rename it in the mapping file, and then use the edited mapping file to again deobfuscate the game's jar file but this time including the filename of the mapping file (instead of no file name). Now instead of generating a mapping file, it would load the existing (and edited) mapping file, and generate class file names, method names, field names, and package names, which much more accurately describe their functionality.
No. You don't need more then actually two files ever. One is for mdk the other is for obfsucated. It tells forge wheat to turn the stuff into srg for obfsucated and readable names for deobfuscated.
For this you only ever need one file it deobfuscates them depending upon the code will determine the file you use.
Well, I decided to update this. Hopefully, this fixes any issues anyone was having with it. Feel pretty good that I made it with C# instead of java. I also completed it way faster than I thought I would. Took me around than 12 hours in total, I think. Feels good man.