wasn't so much a decision on their part. 1.10 has the same obfuscation as 1.10.2 (at least as far as the classes my mods are interested in). It's a matter of whether or not additional classes or methods are added. If not, the obfuscation isn't changing. Stuff in 1.8 and 1.9 apparently changed enough that the obfuscation followed
i will give you 50 bucks if you update it to work with 1.8.9
Thank you for your offer but it is not a matter of money but a matter of time. If you are serious maybe you might get someone in the Requests section to do it. I would be more than willing to assists and provide information where required.
I am quite ambitious and usually don't do things quick and dirty - it is just not the way I work. It would take me at least 2 days to get this to where I want it. It is not Minecraft's changes that are the problem but Forge's and ForgeGradle's.
I am considering a less time consuming quick and dirty approach but even then it is still going to take a few hours of concentration and catching up with FG.
Someone with some Forge experience might be able to whip it up as a new project, recompile it (which is possibly all it needs), and dirty-test it in ~3hrs I am guessing.
It seems like the reobfuscation didn't work properly or the Minecraft.getMinecraft() method has been deprecated (but then it would have probably not worked in your NetBeans).
Caused by: java.lang.NoSuchMethodError: net.minecraft.client.Minecraft.getMinecraft()Lnet/minecraft/client/Minecraft;
This ErrorHandlerImpl.java is using a plain Minecraft method. You could try to switch to one that Forge provides. But really this seems to indicate that the project setup is not quite right. Reobfuscation should have probably replaced that plain text method "getMinecraft()".
I tracked down the UnsatisfiedLinkError to be an incompatibility with Minecraft itself now.
At some point Mojang started using JNA too. But they are using an old-ass version: 3.4.0. (see %appdata%\.minecraft\libraries\net\java\dev\jna\jna\3.4.0 ).
Back at MumbleLink-4.0.3 I explicitly changed to JNA-4.0.0 to stabilize library loading.
Right now, when starting Minecraft Advapi32 will be loaded using JNA-3.4.0 - since the mod is loaded last but uses the same class loader the class loader will try to load LinkAPI with JNA-3.4.0 instead of JNA-4.0.0.
The heuristics of JNA-3.4.0 are not able to locate the native library LinkAPI (e.g. LinkAPI.dll). So the mod crashes because the required library could not be loaded.
What I see are 5 options:
1. Try using a custom class loader that uses JNA-4.0.0 while the root class loaded can stick with JNA-3.4.0 (very tricky - I have no experience with custom class loaders and am not sure if this also applies to native libraries)
2. Somehow inject JNA-4.0.0 before the JVM even tries to load the JNA-3.4.0 - hoping that it will not break the game and load the Advapi32 using JNA-4.0.0. (this might be what is happening when you are running successfully in NetBean, but for shipping it is not very promising and seems very hacky)
3. Downgrade MumbleLink to work with JNA-3.4.0 (maybe looking at MumbleLink-4.0.2 can give an indication on how it might work, QnD-style this might be the way to go)
4. Upgrade MumbleLink to work with both JNA-3.4.0 and JNA-4.0.0. (not really feasible)
5. Switch to BridJ like I was planning to do all along.
I do not believe that shading really is an option since JNA will require it's own native libraries unless they have not changed (which I do not believe) there will be conflicts of java classes expecting different native data structures then what has been loaded - JNA is really complex.
Thank you for your help and feedback. I have been able to test MumbleLink-1.8.9-5.0.0-a1.jar with 2 Windows clients and Mumble, attenuation worked as expected.
I was able to compile the Linux libraries but the 64-bit one that I tested was not working properly with the bridj Java-Class when trying to access "description" so for now there will not be any linux support. I am unsure how to fix this runtime issue.
Major Change Log:
* downgraded to JNA 3.4.0 (b5) which is now being shipped with MC itself and conflicted with JNA shipped by MumbleLink
+ added unpacking of embedded native library LinkAPI to temp folder (since old-*** JNA 3.4.0 cannot load custom libraries from jars directly)
Downloads for Addon-Developers
these are quick-and-dirty releases, there are no separate downloads clone the GitHub-Project or use the jars above
Generally you are free to distribute it with your private (or public, or commercial) mod-packs as specified by LGPLv3.
That being said, it virtually means no restrictions apply except that you should inform users that your mod-pack contains this mod and that it is licensed under LGPLv3.
Feel free to drop a note and a link in this thread. It might give you some more users and I simply am curious to see where it is used (totally optional!).