Back in the Version 1.6.1 days Mojang did not obfuscate their code anew for each maintenance patch.
Because of this and since neither the API that I was using nor my code was changed, MumbleLink Version 4.0.4 was compatible with 1.6.1 and following maintenance patches.
Did compatibility unexpectedly break with 1.6.4? I probably was not aware of that at that time.
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.
Succesfully compiled and run in MC 1.8.9
It seems to link to Mumble (It at least says it's linked...) and TeamSpeak Crosstalk seems to work as well!
I will paste a download link in approximately 24 hours. (Sleep, Work, Eat, repeat)
Edit: So much for 24 hours. LINK
Was unable to have it work in Forge 1.8.9, here's the crash report.
Still, thank you for all your efforts, having a version of MumbleLink that works in 1.8.9 would be absolutely wonderful.
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;
at zsawyer.mods.mumblelink.error.ErrorHandlerImpl.<init>(ErrorHandlerImpl.java:41)
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()".
You cannot use the deobfuscated jar that NetBeans is using.
But the result of gradle build is giving a good indication that you are on the right track.
The error message with UnsatisfiedLinkError says that it is complaining that it cannot find the native library to load.
It seems like all you have to do is merge the natives.jar into the one that gradle built. So you would end up with a jar similar to the ones I shipped.
You can easily merge the jars using some ZIP-Tool like 7zip (be careful WinRAR seems to be a bit dodgy).
You should end up with something like this (note the .dll, .dylib, .so files):
I have created a Quick-and-Dirty branch and created these alpha binaries as POC. Please give me feedback if they are working as I cannot test it myself atm.
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:
v4.1.3
* 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
Mod-Packs:
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!).
Since BridJ is having problems with wchar_t's length on Linux 64 bit and it seems dead; I have dropped the idea of going with BridJ instead of JNA.
Alas, I resorted to going the step back and downgrading to MC's old-ass JNA 3.4.0. That forced me to implement loading from jars myself (a feature that JNA 4.0.0 had).
On the bright side this makes the delivery artifact way smaller, since JNA is already included in MC, so I don't have to ship it.
I have done all this in the Branch QnD-MC_JNA - so try going with that if there is a new MC out and I am not available.
Back in the Version 1.6.1 days Mojang did not obfuscate their code anew for each maintenance patch.
Because of this and since neither the API that I was using nor my code was changed, MumbleLink Version 4.0.4 was compatible with 1.6.1 and following maintenance patches.
Did compatibility unexpectedly break with 1.6.4? I probably was not aware of that at that time.
Have you tried 4.0.4?
Want Positional VOIP? Get the Mod for Mumble Support
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
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.
Want Positional VOIP? Get the Mod for Mumble Support
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.
Want Positional VOIP? Get the Mod for Mumble Support
It is missing the natives.jar. It goes into the classpath - which can be the execution directory.
Want Positional VOIP? Get the Mod for Mumble Support
Was unable to have it work in Forge 1.8.9, here's the crash report.
Still, thank you for all your efforts, having a version of MumbleLink that works in 1.8.9 would be absolutely wonderful.
Tried .1902 as well, but it must be some other issue on my end, thanks anyways for your help. ^-^
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).
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()".
Have you been using clean before build task?
Want Positional VOIP? Get the Mod for Mumble Support
That clean before build was a shot in the dark
You cannot use the deobfuscated jar that NetBeans is using.
But the result of gradle build is giving a good indication that you are on the right track.
The error message with UnsatisfiedLinkError says that it is complaining that it cannot find the native library to load.
It seems like all you have to do is merge the natives.jar into the one that gradle built. So you would end up with a jar similar to the ones I shipped.
You can easily merge the jars using some ZIP-Tool like 7zip (be careful WinRAR seems to be a bit dodgy).
You should end up with something like this (note the .dll, .dylib, .so files):
Want Positional VOIP? Get the Mod for Mumble Support
I have created a Quick-and-Dirty branch and created these alpha binaries as POC. Please give me feedback if they are working as I cannot test it myself atm.
Alpha for MC 1.8.8:
MumbleLink-1.8.8-4.1.3-a1.jar
Alpha for MC 1.8.9:
MumbleLink-1.8.9-4.1.4-a1.jar
Want Positional VOIP? Get the Mod for Mumble Support
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.
Want Positional VOIP? Get the Mod for Mumble Support
Seems like you might have found a fix for https://github.com/zsawyer/MumbleLink/issues/10 xD I guess I tracked that one down already back in January but completely forgot
Want Positional VOIP? Get the Mod for Mumble Support
Well I ended up going with BridJ but that meant dropping Linux and MacOS support for the time being.
Alpha for MC 1.8.9:
MumbleLink-1.8.9-5.0.0-a1.jar
Want Positional VOIP? Get the Mod for Mumble Support
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.
Want Positional VOIP? Get the Mod for Mumble Support
The 1.8.9 alpha seems to work very well, thank you for your hard work. ^^
New Versions released: 4.1.3, 4.1.4, 4.2.0, 4.2.1, 4.2.2, 4.2.3
compatibility updates for
- MC 1.8.8
- MC 1.8.9
- MC 1.9
- MC 1.9.4
- MC 1.10
- MC 1.10.2
Download for MC 1.8.8
MumbleLink-1.8.8-4.1.3.jar
Download for MC 1.8.9
MumbleLink-1.8.9-4.1.4.jar
Download for MC 1.9
MumbleLink-1.9-4.2.0.jar
Download for MC 1.9.4
MumbleLink-1.9.4-4.2.1.jar
Download for MC 1.10
MumbleLink-1.10-4.2.2.jar
Download for MC 1.10.2
MumbleLink-1.10.2-4.2.3.jar
Major Change Log:
v4.1.3
* 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
Mod-Packs:
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!).
Current and Alpha Releases:
other releases can be found on github: https://github.com/zsawyer/MumbleLink/releases
Want Positional VOIP? Get the Mod for Mumble Support
Since BridJ is having problems with wchar_t's length on Linux 64 bit and it seems dead; I have dropped the idea of going with BridJ instead of JNA.
Alas, I resorted to going the step back and downgrading to MC's old-ass JNA 3.4.0. That forced me to implement loading from jars myself (a feature that JNA 4.0.0 had).
On the bright side this makes the delivery artifact way smaller, since JNA is already included in MC, so I don't have to ship it.
I have done all this in the Branch QnD-MC_JNA - so try going with that if there is a new MC out and I am not available.
Want Positional VOIP? Get the Mod for Mumble Support
see this post please : http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/1272675-1-10-2-mumblelink-forge-smp-lan-mumble-realism?comment=459
Want Positional VOIP? Get the Mod for Mumble Support
Is this being updated to 1.11?
-Herdle
Thanks for the report. I will have a look.
Want Positional VOIP? Get the Mod for Mumble Support