(not an API as suggested above, it's out of my skill range but some sort of remove obfuscated code by replacing it with community provided code using a pattern that would adapt itself to updates )
I don't think it's above your skill level at all if you can manage to decompile and understand obfuscated code.
Quote from SpongeBob »
Yes, an API would be nice. The trick is finding the best places for extension points. I recommend a simple IPC system instead of making people implement a bunch of Java interfaces though.
I wasn't thinking of making the modder implement the interfaces, that would suck. Instead:
1. Develop a series of interfaces or abstract classes with no defined functionality.
2. Create a new assembly that inherits from those abstract classes or implements those interfaces
3. Modders code against the interfaces or abstract classes, in whatever fashion they like. It's an API.
4. When implementing the code, the modder throws their custom classes into the .JAR, the classes containing the interfaces, AND picks out the correct implementation for the version of minecraft.jar.
This diagram should help articulate what I'm talking about.
I use jd-gui to decompile, and netbeans to recompile. You can't try to decompile the whole jar, and you can't try to de-obfuscate things, because you're not modding the whole thing, just individual classes. I know little about the client, as the server is my realm of expertise. A few tips:
1) ez.class (currently) is a list of all item classes mapped to their data value (minus 256).
2) ff.class (currently) is a list of all block classes likewise mapped to their data value (actual value, not minus 256).
3) dy.class (currently) is the world, and you use dy.a(x,y,z) to get a block, and dy.d(x,y,z,v) to set one.
4) any entities use "L,M,N" instead of "X,Y,Z" for their coordinates.
Maybe I'm being too optimistic, but couldn't we start writing our own mod API? A library of interfaces that modders code against, and another assembly that maps the decompiled obfuscated objects to those interfaces that could be swapped according to the version being used. Then mods would be backwards and forwards compatible once someone writes the mapping for that specific version.
Don't think it would be hard to convince people to use the API once it's written - kicks the crap outta trying to remember that "dy.d(int, int, int, v)" is actually "world.setBlock(int, int, int, IBlockObject)" or whatever.
0
I don't think it's above your skill level at all if you can manage to decompile and understand obfuscated code.
I wasn't thinking of making the modder implement the interfaces, that would suck. Instead:
1. Develop a series of interfaces or abstract classes with no defined functionality.
2. Create a new assembly that inherits from those abstract classes or implements those interfaces
3. Modders code against the interfaces or abstract classes, in whatever fashion they like. It's an API.
4. When implementing the code, the modder throws their custom classes into the .JAR, the classes containing the interfaces, AND picks out the correct implementation for the version of minecraft.jar.
This diagram should help articulate what I'm talking about.
0
Maybe I'm being too optimistic, but couldn't we start writing our own mod API? A library of interfaces that modders code against, and another assembly that maps the decompiled obfuscated objects to those interfaces that could be swapped according to the version being used. Then mods would be backwards and forwards compatible once someone writes the mapping for that specific version.
Don't think it would be hard to convince people to use the API once it's written - kicks the crap outta trying to remember that "dy.d(int, int, int, v)" is actually "world.setBlock(int, int, int, IBlockObject)" or whatever.