package insertion will not work

[Variadicism-zz]

So, remember that BiomeOE class I made in the net.minecraft.world.biome package so that we could access Biome-related "protected" fields and methods? Well, unfortunately, I just realized that if we tried to actually use this, it would fail due to visibility issues.

I forgot to take into account the fact that Minecraft uses the default package. That means that even though it will compile, I think when BiomeOE tried to access protected fields and methods, it will fail because it is attempting to access protected fields and methods from the net.minecraft.world.biome package in classes that are now in the default package.

This requires testing to confirm, but I don't think this will work. There's still the option of extending the classes we want protected information from, but to make that work, we have to make sure that our classes are instantiated instead of theirs, which means changing a lot of Minecraft's code with overextension.

Maybe we could use ClassLoaders to redirect references to Minecraft's regular Biome class to our own Biome class or something, but...I'm not sure. We'll see. I need to do some experimentation with ClassLoader redirects. I'm not sure if they're even possible.

[ElementsModder]

I'll go and check it.

[Niadevv]

This kind of depends on the (re)obfuscator's "intelligence" from what I know. If it changes a class's package to make sure there's still access allowed for a package (it probably does but I don't know for certain), then we should be fine. However, otherwise, then there's going to be an issue (pardon the pun).

[Variadicism-zz]

I actually discussed it with some other members of SoDA -- the Software Developers' Association at ASU -- and I think we came up with a better way.

With the new CorundumThread system we've been implementing, we can check securities for virtually any thread at any time. All we have to do, then, is tell people to make PluginThreads rather than regular Threads. I've already set up the security so that if a secure method is accessed by a non-CorundumThread thread (besides the main thread that starts the Corundum Hub), it will throw a CorundumSecurityException.

The only real disadvantage to this is that people might be annoyed if they don't listen to the tutorials and try to make a regular old Thread and get shut out, but we can put messages in the CorundumSecurityException to describe what to do if that happens.

CorundumThread constructors even have all the same arguments as the standard Thread constructors and inherit information from the thread that called the constructor, so the only thing plugin authors would have to do is put "PluginThread" instead of "Thread"; that's it.

[Variadicism-zz]

Uh... I think I posted that above comment in the wrong place. Sorry. That's a whole different discussion not related to this issue.

My bad. Ha ha.

[Niadevv]

Oh, it's ok, one time I almost commented in a Forge issue about Corundum stuff XD

[Variadicism-zz]

Unfortunately, I tested it. The reobfuscator does not relocate classes in Minecraft packages unless they're standard Minecraft classes; the BiomeOE.class is still in the net.minecraft.world.biome package after reobfuscation.

[Niadevv]

Oh... That's going to be problematic to say the least. Perhaps I may need to look into how to get the reobfuscator working for this. Fortunately, I know Python (what MCP is written in).

[Variadicism-zz]

We might be able to try just adding that class to the obfuscation table for classes in the conf/joined.srg file.

I might try that later; right now I've come across an error from Log4J that's preventing our current build from starting. I really hate Log4J; it's ridiculously fragile.

[Variadicism-zz]

I had a thought, actually. If we could make MCP move the class to the default package, we could in theory use one single class to access any protected or default-visible field or method in all of Minecraft since everything is in the same package!