Bug introduced by a new lib
Dum4G opened this issue ยท 6 comments
@PimvanderLoos is there any reason bytebuddy would break compatibility with forge?
I am not at all familiar with Forge or Arclight (never heard of it before), so I wouldn't really know what's different here off the top of my head. I'll have to take a closer look first. I'll let you know when I find something.
I tried to run ProtocolLib on Mohist and CatServer (the biggest two Forge/Spigot hybrid servers) and it was able to load the plugin just fine on both 1.12 (Mohist/CatServer) and 1.16 (Mohist, did not try CatServer; it looks like it's even less stable than Mohist on 1.16). I was able to join the server and use a simple test plugin (changing falling sand packets to falling dirt packets) on 1.12, but not 1.16 (though it does not appear to be related to the issue described above). However, Mohist doesn't really work for the Spigot part of 1.16 yet (as also noted in their readme, and I was unable to load other plugins (e.g. Essentials) either), so that makes it a bit more difficult to compare two different 1.16.4 Forge hybrid platforms.
Nonetheless, considering it worked just fine on both Mohist and CatServer on 1.12 and did not cause the same issue on start for 1.16, I think that the issue is likely to be specific to Arclight and not Forge.
I'm pretty sure that the issue comes from the fact that Arclight hijacks calls to defineClass so it can remap stuff. It then fails when analyzing the class here while checking if any of the class's parents are in the NMS package using their PluginInheritanceProvider implementation of md_5's InheritanceProvider because it cannot find the ClassNode from the Class's name and returns null instead of an empty collection or a descriptive error or something. I don't know why it cannot obtain the ClassNode from the classRepo, but I don't have time to look into that right now.
Changing the ClassLoadingStrategy used here from Default.INJECTION to ForUnsafeInjection solves this issue (both launching the server + creating temporary players works fine). I haven't looked at the code, but I assume that this works because Arclight is unable to intercept the class defining process this way. However, this requires the usage of Unsafe, which might not be ideal, so fixing it on Arclight's end might be preferable.