search

Mojang / LegacyLauncher

Hacky code to launch our old versions from the new launcher!
253 stars 109 forks source link

More hooks in LaunchClassLoader #5

Closed TheWeatherPony closed 10 years ago

TheWeatherPony commented 10 years ago

I was working on adding hooks like these by extending LaunchClassLoader, but found that replacing the active loader without conflicting with other mods/mod loaders wasn't worth the frustration. Mojang, please do whatever you want with these changes, rewriting them if need-be. I can explain my reasoning behind each change, if you want me to.

cpw commented 10 years ago

Ok, please explain why the listener, and why the exception killer?

cpw commented 10 years ago

Closing this. Your other PRs demonstrate a fundamental lack of understanding of how this stuff works..

TheWeatherPony commented 10 years ago

Almost all mod makers using an IClassTransformer are replacing the bytecode for classes outright, rather than merging their edits with ASM. The listener would allow someone that knows what he's doing to merge the edits from other [conflicting] mods together so the final product contains all of the changes, rather than just the edits from one mod. Does it need to be a list of these listeners? No, not at all; just one would be sufficient. This code is just a quick recreation of what I was trying to do in an extending class, and even there, my main focus was trying to stay compatible with your mod loader, rather than require it be used as a library, since there's no libraries in the vanilla server environment. With the current system, it is overly-simple for a mod maker to add his entire mod (or even worse, an empty string) to the transformation exclusion list, which would stop mod makers with pure intentions from editing his code, even for fixing compatibility issues that are caused unintentionally. The "exception killer," as you coined it, would provide a way to counter such idiotic modding. I don't know of any modder that does this yet, but it's a problem that could potentially form in the future. Yes, this could make problems if used improperly, but it could also remove problems if used well.

I might be new to ASM and class loading, but I see a problem of whom to trust, and wish to identify it as such. This deals with philosophy, rather than skill, and I already said Mojang could do anything that they want with this - even if they use it as a mere thought exercise. Should the loader trust everyone blindly with his own code, leading to mod conflicts like we've had since the beginning of Minecraft modding? Or should it trust everyone blindly with everyone's code, which would let mod makers essentially police each other? Whom should be trusted- the idiot that might add everything to the exclusion list, or the idiot that might remove everything from it? The genius that can make anything happen with source-code manipulation, or the genius that can make anything happen with bytecode manipulation?

cpw commented 10 years ago

Pony: almost no one is doing what your saying, because they're creating conflicts if they do. Knowing won't help, and trust me, trying to do a smart diff- yeah that's really possible (or not!). Adding these listeners won't help mojang, and it'll be of small utility at best for the modder scene, so I don't see the value in it at all.. If you have a complaint about coremod behaviour by the way I suggest you file it at FML not here..