Default package affects mod classes

[FyberOptic]

I've been working with loading Minecraft 1.2.5 mods after deobfuscating them with BON, and after having some class loading issues due to the package of some of the mod's classes, I eventually realized that it was the JARs themselves at fault. BON had placed the unpackaged classes in the JARs into "net.minecraft.src".

This isn't a problem for newer mods, where everyone defaults to using a package, and Forge scans the JAR for them. But for these old ones that use the ModLoader technique it's obviously an issue. I realize that it's adding a default package for handling Minecraft's obfuscated base classes, and I also realize that BON can probably be used to remap the Minecraft JAR itself, so not repackaging classes in the input JAR by default isn't necessary the answer.

So unless there's something I'm overlooking, I guess a viable solution would just be to add a config option on whether or not to repackage classes found in the input JAR, and have it still do so by default to retain compatibility.

[immibis]

This is how things worked back in 1.2.5 and earlier. People put their classes in net.minecraft.src, and the obfuscator moved them to the default package. So, logically, deobfuscation should move them back.

[FyberOptic]

The problem though is that classes which are already in packages in the JARs aren't moved, so the mods get confused because their main "mod_" and related classes are repackaged and the rest aren't. BuildCraft for example detects this and tries to behave as if it's running in a development environment by prefixing "net.minecraft.src" to all other class loads.

I realize this is more of a fringe issue, I simply removed the default package in BON's code and recompiled, and it's fine now for my case. But it caused enough head-scratching for me in figuring out what was going on that I thought I'd bring it up in case you feel a solution is warranted.