Variadicism-zz
commented
10 years ago After much thought (and not much discussion, as you can see), I have concluded that Corundum A.P.I. objects should be wrappers for Minecraft objects. All getters and setters and data management and all that should be delegated to the Minecraft code. Corundum A.P.I. objects that represent Minecraft objects (like Entity, Block, etc.) should not contain ANY data themselves other than the Minecraft object they represent; they are just bridges between the Corundum A.P.I. and the Minecraft code.
If any of this doesn't make sense, feel free to re-open this issue and leave a comment.
So, I've been thinking about this problem for a while and I haven't found any solution to it yet other than the hard solution.
The problem is capturing Minecraft objects and putting them into a format workable in the A.P.I. I think our system for "types" -- like ItemType and BlockType -- is fine because those things are unchanging; once the server starts up, it initializes stats for all those things and they never change and there are never any added or removed. However, for more "dynamic" systems like Biomes and Blocks themselves that can be changed and added and removed freely, I don't think this system of Constructor(MCObject) will work well. It would mean, for example, that there's no persistent list of Biomes in the format of the Corundum A.P.I., plus it means that we have to do things like "package insertions" like what I did with the BiomeOE class in our net.minecraft.world.biome package to retrieve protected fields from the Minecraft BiomeGen classes.
A solution that would probably be more stable would be to make classes that extend the original Minecraft objects and override Minecraft methods to force the use of those. However, this method would require that we force Minecraft to use our Corundum objects instead of its regular objects, which would mean overriding all methods that create "new" instances of a Minecraft object that we want to override, which could mean a whole lot of work. Also, this still wouldn't work in some places like where Minecraft uses instantiated final fields.
We might actually be better off with the package insertion method where we make classes and put them in packages with the same name as Minecraft packages that we want to retrieve protected fields from. Again, this is what I did with the BiomeOE class in net.minecraft.world.biome. However, this gives us less power since we can't override methods this way. Also, it means we have to have packages in Corundum named like Minecraft packages and I'm not sure of the legality of that.... Finally, if we use this method, we need to figure out what an actual "Biome" object MEANS. With this method, we have to use a Biome object as a kind of wrapper for a Minecraft Biome object (called BiomeGen[...] by MCP). In that case, when do we make new Biome objects? Can we successfully use Java visibility to keep players from doing weird things that might disrupt the actions of the server? We would need to figure out how this stuff works.