You are running 32 bit Ubuntu but JNA (a framework that MumbleLink uses) is trying to load libraries that are 64-bit.
It could be that JNA thinks it is being run in a 64-bit environment. Thus it is trying to load the (wrong) 64-bit libs.
Currently in-use version of JNA is 4.0.0, maybe there is a fix for that in 4.1.0 but instead of going for 4.1.0 of JNA I am more likely to go for BridJ instead.
There are a few things you can try (I don't have an Ubuntu available right now).
give a more detailed crash log by setting the system property
jna.debug_load=true
and trying again
run the JVM in 32-bit mode explicitly (use the
-d32
command-line option)
try using an Oracle certified JRE or JDK (1.7_06) [i think this has the best chance of fixing your problem]
I set a shell script to start the official launcher with both of the command-line options:
In the official launcher's profile for Minecraft 1.7.10 with Minecraft Forge 10.13.2.1230, I enabled the "JVM Arguments" box and typed both options into it:
-d32 -Djna.debug_load=true
I installed Oracle's certified JRE for 32-bit Linux and made it the default JRE for the system. Java 1.7.0_72 was the newest of the Java 7 versions at the time of testing. I did not test with Java 1.7_06.
some_user@computer:~$ java -version
java version "1.7.0_72"
Java(TM) SE Runtime Environment (build 1.7.0_72-b14)
Java HotSpot(TM) Server VM (build 24.72-b04, mixed mode)
I rebooted for good measure. The settings were the same once I returned to the desktop environment. I removed all mods from the /mods/ folder, opened the official launcher, and started the profile of Minecraft 1.7.10 with Minecraft Forge 10.13.2.1230. It loaded without errors as it had previously.
I closed the game and launcher, copied MumbleLink-1.7.10-4.1.1-2b3035b.jar to the /mods/ folder, reopened the official launcher, started the profile of Minecraft 1.7.10 with Minecraft Forge 10.13.2.1230, and the game crashed in the same place it had previously (immediately after the "Mojang" splash screen) and with the same error:
Adding the "-Djna.debug_load=true" option to the shell script which starts the official launcher did not change the output of the launcher in the terminal in any of the test cases. In other words, the output from the launcher was the same as when the option was not present.
I was not able to figure out how to view or redirect the output from the launcher's internal command that starts the actual game and contains the "JVM Arguments" with the "-Djna.debug_load=true" option. Its java command line starts "net.minecraft.launchwrapper.Launch" and has an "--accessToken" argument, so I'm not sure I could start it anyway without deep knowledge of the official launcher's code.
Edit: Corrected "-Djna.debug_load=tru" in the final two paragraphs to "-Djna.debug_load=true". It was a typo in this post, not in the script or launcher.
In the official launcher's profile for Minecraft 1.7.10 with Minecraft Forge 10.13.2.1230, I enabled the "JVM Arguments" box and typed both options into it:
-d32 -Djna.debug_load=true
I installed Oracle's certified JRE for 32-bit Linux and made it the default JRE for the system. Java 1.7.0_72 was the newest of the Java 7 versions at the time of testing. I did not test with Java 1.7_06.
some_user@computer:~$ java -version
java version "1.7.0_72"
Java(TM) SE Runtime Environment (build 1.7.0_72-b14)
Java HotSpot(TM) Server VM (build 24.72-b04, mixed mode)
I rebooted for good measure. The settings were the same once I returned to the desktop environment. I removed all mods from the /mods/ folder, opened the official launcher, and started the profile of Minecraft 1.7.10 with Minecraft Forge 10.13.2.1230. It loaded without errors as it had previously.
I closed the game and launcher, copied MumbleLink-1.7.10-4.1.1-2b3035b.jar to the /mods/ folder, reopened the official launcher, started the profile of Minecraft 1.7.10 with Minecraft Forge 10.13.2.1230, and the game crashed in the same place it had previously (immediately after the "Mojang" splash screen) and with the same error:
Adding the "-Djna.debug_load=tru" option to the shell script which starts the official launcher did not change the output of the launcher in the terminal in any of the test cases. In other words, the output from the launcher was the same as when the option was not present.
I was not able to figure out how to view or redirect the output from the launcher's internal command that starts the actual game and contains the "JVM Arguments" with the "-Djna.debug_load=tru" option. Its java command line starts "net.minecraft.launchwrapper.Launch" and has an "--accessToken" argument, so I'm not sure I could start it anyway without deep knowledge of the official launcher's code.
After the crash, in the launcher you will see an additional tab "Game Output (<your username>)" can you please post that one?
It should contain a line "Looking for library 'LinkAPI'" or "Found library resource at". It will be lines without a timestamp. You might also want to set the "Launcher Visibility" in the the profile to "Keep the launcher open".
Edit:
If you don't see anything related to the library loading please also set "jna.debug_load.jna" to "true". Also try with export as -D might not suffice.
After the crash, in the launcher you will see an additional tab "Game Output ()" can you please post that one?
It should contain a line "Looking for library 'LinkAPI'" or "Found library resource at". It will be lines without a timestamp. You might also want to set the "Launcher Visibility" in the the profile to "Keep the launcher open".
Edit:
If you don't see anything related to the library loading please also set "jna.debug_load.jna" to "true". Also try with export as -D might not suffice.
I added export lines and set the jna.debug_load.jna property in the shell script that starts the launcher. I had to remove "-d32" from _JAVA_OPTIONS because java would not accept it in that variable.
[01:05:47] [Client thread/INFO] [STDOUT]: [com.sun.jna.NativeLibrary:loadLibrary:129]: Looking for library 'LinkAPI'
Line 60:
[01:05:47] [Client thread/INFO] [STDOUT]: [com.sun.jna.Native:extractFromResourcePath:843]: Found library resource at jar:file:/home/some_user/.minecraft/mods/MumbleLink-1.7.10-4.1.1-2b3035b.jar!/linux-x86/libLinkAPI.so
I am also on Ubuntu and seeing something slightly different. I've got latest 1.8.1 client vanilla, just installed FML and put this mod in my mod folder. It crashed on me pretty quickly. Tried to check that I wasn't screwing anything up. Here's the crash log output:
I'm on Ubuntu 14.04 and haven't modded Minecraft in 2 years. Apologies for any ignorance on my part for that, but I'm pretty good at troubleshooting and willing to try any suggestions you have or provide any data I can. We're trying to setup a server and would love to have positional audio for all the players. I've seen this work in the past and you've done awesome work. Thanks in advance!
I am also on Ubuntu and seeing something slightly different. I've got latest 1.8.1 client vanilla, just installed FML and put this mod in my mod folder. It crashed on me pretty quickly. Tried to check that I wasn't screwing anything up. Here's the crash log output:
I'm on Ubuntu 14.04 and haven't modded Minecraft in 2 years. Apologies for any ignorance on my part for that, but I'm pretty good at troubleshooting and willing to try any suggestions you have or provide any data I can. We're trying to setup a server and would love to have positional audio for all the players. I've seen this work in the past and you've done awesome work. Thanks in advance!
NujabkeicMoy, thanks again for the detailed infos and patience.
This is what the whole jna debug stuff was for and what I was looking for:
[01:05:47] [Client thread/INFO] [STDOUT]: [com.sun.jna.Native:loadNativeDispatchLibraryFromClasspath:764]: Found jnidispatch at /tmp/jna-1544803905/jna3577779177601106910.tmp
This looks good, there seems to be no problem with JNA so it must by the library I am shipping.
Please do
objdump -f linux-x86/libLinkAPI.so
This will probably reveal that its compiled for 64 bit. It's the only explanation I have for now. If so then you must be the first to try this mod on a 32-bit linux and reporting the problem for almost a year.
Please download this file https://github.com/zsawyer/MumbleLink/raw/master/natives/build_linux32/libmod_MumbleLink.so and rename it to libLinkAPI.so and put it in the linux-x86 folder in your jar file.
Correct me if I'm wrong but from the posts I've read here and the youtube videos it seems that mumble link acts as its own internal mumble server, correct? Is there anyway to use a pre-existing mumble server on a different ip from the server.
Correct me if I'm wrong but from the posts I've read here and the youtube videos it seems that mumble link acts as its own internal mumble server, correct? Is there anyway to use a pre-existing mumble server on a different ip from the server.
That is not correct. This mod merely is a bridge ("link") between Minecraft and a Mumble client on your computer. You will still need a separate Mumble Server (Murmur) that everybody connects to using their individual Mumble Clients.
That way this mod is completely independent of IPs. This means you can host Murmur on a completely different machine than your Minecraft server or both on the same, what ever you like.
If you are hosting servers always remember to forward/open the appropriate ports or else no one will be able to connect.
The behavior you have described ("embedded server"), however, is what I would like it to be in the future. That would make things a lot easier and allow better control over who can hear who and such.
Since this seems to be a recurring misunderstanding I have drawn a diagram illustrating the relationships between the different components.
A normal player will only have to worry about the "Client" group of components: Minecraft (including Forge), MumbleLink, and Mumble.
Server admins will have to take care of Murmur (the Mumble Server) and the Minecraft server but the mod does not require any special setup on the server side! Just make sure that the Mumble Server supports positional data (default for Murmur).
The arrows indicate data flows, as can be seen there is a one-way direction of data going from Minecraft to MumbleLink to MumbleClient. That means there is no feedback coming from the Mumble Client to MumbleLink (we are pretty much clueless as to what happens after we gave the data to Mumble)!
All this is completely independent of the Minecraft Server.
The next diagram shows a more technical view of the workings.
FML (Forge Mod Loader) will load the MumbleLink mod and Forge itself.
MumbleLink uses also some Features of the Forge API (mainly configuration files and logging).
But most importantly it sends the positional data it retrieved from Minecraft using the LinkAPI native libraries (shipped with the mod).
Which in return are basically a bridge to hand the data over to the "Link Plugin" which is shipped with Mumble.
The Mumble Client can access the date that came through the Link Plugin.
Here two things are happening:
The Mumble Client sends the data that came through the Link Plugin to the Mumble Server.
The Mumble Client also retrieves data of other Mumble Clients from the Mumble Server.
Internally the Mumble Client will use it's own data and the foreign data and calculate distances and headings to transform the audio signals so that they sound positionally and directionally attenuated. But it never sends the foreign data to MumbleLink!
This will probably reveal that its compiled for 64 bit. It's the only explanation I have for now. If so then you must be the first to try this mod on a 32-bit linux and reporting the problem for almost a year.
Please download this file https://github.com/zsawyer/MumbleLink/raw/master/natives/build_linux32/libmod_MumbleLink.so and rename it to libLinkAPI.so and put it in the linux-x86 folder in your jar file.
You were right. The library in the MumbleLink-1.7.10-4.1.1-2b3035b release was built for 64-bit. The rebuilt one you linked for me is built for 32-bit.
Minecraft opened properly without errors when the rebuilt library was copied into the jar.
There were some less serious problems upon testing, however. I tested it with a vanilla 1.7.10 server with one client on Windows and another on Ubuntu with the rebuilt library. Both computers were on a LAN (not across the internet). First, Mumble's overlay in the corner of the game window that lists the users who are currently speaking never showed up on Ubuntu's Minecraft client. (Edit: Solution at bottom.) Second, to test positional audio, the Ubuntu user stood still while the Windows user walked away from them while speaking. I was expecting the volume that the Ubuntu user heard would decrease gradually as the Windows user walked away, but it decreased abruptly as if there were only two volumes: loud when near and suddenly quiet when far away. The Windows computer's CPU was near 90%, but I don't know if that affected the volume's slope. The Ubuntu computer only had speakers, not a microphone, so I was not able to test positional audio in the other direction with the Ubuntu user speaking.
P.S. I understand it's easier for users to post bug reports on this forum, but following the conversations for a particular bug becomes less so. Have you considered using something more organized for the purpose such as an issue tracker or Github? It would keep each report's resolutions contained and able to be referenced from other issues and code edits. Users might have to register a username for the issue tracker, but issues could be easier to manage and follow.
Edit:
Linux overlay solution: start the game with mumble-overlay.
user@computer:~$ mumble-overlay <gamename>
This binary is usually installed with the mumble package, but Fedora Linux may need you to install a separate "mumble-overlay" package. The overlay can be configured in Mumble's top menu bar -> Settings -> Overlay. http://wiki.mumble.info/wiki/Overlay#Overlay_on_GNU.2FLinux
MumbleLink-1.8-4.1.2 (the most recent version as of this post) also contains a libLinkAPI.so built for 64-bit in the folder for Linux 32-bit that causes MumbleLink to crash on Linux 32-bit:
Edit: The MumbleLink-1.8-4.1.2 jar can be repaired by pasting the rebuilt libLinkAPI.so into the /linux-x86/ folder in the jar. It's the same one that SnipingCoward linked for my issue with Minecraft 1.7.10. (The library file for Linux 32-bit is identical in MumbleLink 4.1.1 and 4.1.2 (and possibly older versions).)
I do use an issue tracker but forgot to reference it in the OP. But this project's sources are all mainly hosted on GitHub and that has an issue tracker which I use.
As can be seen in the issue the problem with linux 32 bit systems should be fixed in the next release.
As to the second issue:
The Overlay is entirely handled by the Mumble Client I have nothing to do with that. Maybe you can try updating your Mumble or file an issue with them: https://github.com/mumble-voip/mumble/issues
For the choppy transition:
That is quite hard to figure out. You are right, it could be the windows client not being able send out the data in a proper interval.
To check if it is the windows client you can use MumblePAHelper on windows that will give you a gui and tell you which data MumbleLink sent (actually put into a shared memory). Simply open it alongside Mumble and Minecraft. If it updates properly then the Plugin (on Windows) does the best it can and the rest is up to Windows' Mumble Client or thereafter.
The described effect would also occur, if the Ubuntu's Mumble Client doesn't properly receive positional data from MumbleLink. However that update loop is run in a thread in Java so it should be platform independent. The only difference is the native library (.so). But it only differs in one way and that is the initialization of the shared memory. Updating is done the same way as on Windows where it is confirmed to work properly.
So there could also be an issue with the Mumble Client not fetching the data off of the pipe in a fast enough interval. Or it is simply bad Audio Processing on Mumble's Linux build - maybe cutting off floating point precision or something. Or the audio driver is flawed.
As you can see this is going to be a pain to figure out. Sadly there is no tool like MumblePAHelper for Unix afaik, but peeking into the shared memory would tell us if the mod MumbleLink is responsible for the sound transition problem.
Would it be possible to catch that data and use it on Teamspeak too?
Yes, that is already done and working to some extend from what I tested last, but with a little bug that was fixed which I couldn't test yet. CrossTalk by Thorsten Weinz is using the data of the Mumble's Link-plugin (which this mod uses too) and can therefore fake as if it is Mumble. The data will be sent to Teamspeak and should work similar to what Mumble does.
(code block because quotes are bugged)
i know for sure that TS is capable of using directional voice (in ArmA II and III known as "ACRE"-mod).
so back to the point:
what does it take to get that working on TS too? PS.: if that would derange too far from the OP topic, then tell me and i will gladly make it a separate Thread on the forum.
Well CrossTalk already does a good job at taking the Data meant for the Link-Plugin however the features ACRE provide is a whole different story. If you search this thread for ACRE you can see that I have already stated some thoughts about it.
The conclusion is that Mumble in it's current state is maxed out. ACRE features like distortion or terrain based amplitude manipulation is not possible.
That being said. A TeamSpeak-only mod plugin combination would be possible and actually I would love to see the ACRE-TS-plugin code. I am actually thinking that it would be possible to write (a new) Minecraft mod that would behave like the ACRE-Arma-Mod. So basically you could have ACRE installed on TS and both Minecraft and Arma mod's could use the same plugin.
For that we would need an interface definition of how and what data the ACRE plugin expects. With the way we can write mods, Minecraft can do all the things Arma can (in regards to ACRE stuff ofcourse).
Note that I have also stumbled upon a project where someone was creating a native voip mod so there would be no dependencies to any 3rd party tools like mumble or teamspeak. That might be a good alternative, it would be like the normal Arma voip. But I forgot the name and it wasn't bukkit or forge based, I think. I can't even remember if it supported directional.
Any feature on top of the basic directional voice and whisper key would be pure luxury in MC.
Still it would be cool to have those features too.
So to use this, i only need to start MC with your mod and TS with CrossTalk?
i'm going to introduce a few friends to this new feature now
Edit: tested with CrossTalk and when using the beta release, it works - with a few flaws - but it works.
So when they change those issues in future releases, it's fine.
Final conclusion (at the moment) : If you have a Mumble-Server, use Mumble instead of TeamSpeak.
Any feature on top of the basic directional voice and whisper key would be pure luxury in MC.
Still it would be cool to have those features too.
So to use this, i only need to start MC with your mod and TS with CrossTalk?
i'm going to introduce a few friends to this new feature now
Edit: tested with CrossTalk and when using the beta release, it works - with a few flaws - but it works.
So when they change those issues in future releases, it's fine.
Final conclusion (at the moment) : If you have a Mumble-Server, use Mumble instead of TeamSpeak.
Thanks for the feedback. This mod was meant for Mumble after all so yeah - Mumble will probably work a better (for now).
However it is good to hear that is works with CrossTalk somewhat. Please do make sure to submit an issue, to let the dev know. I am also curious as to what the flaws are you have had. Maybe you can link me the issue then and to let Thorwe know if the issue I linked is fixed. Thanks
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYou don't need to read all the previous posts, only the opening post and thereof the first 3 words...
Want Positional VOIP? Get the Mod for Mumble Support
I set a shell script to start the official launcher with both of the command-line options:
In the official launcher's profile for Minecraft 1.7.10 with Minecraft Forge 10.13.2.1230, I enabled the "JVM Arguments" box and typed both options into it:
I installed Oracle's certified JRE for 32-bit Linux and made it the default JRE for the system. Java 1.7.0_72 was the newest of the Java 7 versions at the time of testing. I did not test with Java 1.7_06.
I rebooted for good measure. The settings were the same once I returned to the desktop environment. I removed all mods from the /mods/ folder, opened the official launcher, and started the profile of Minecraft 1.7.10 with Minecraft Forge 10.13.2.1230. It loaded without errors as it had previously.
I closed the game and launcher, copied MumbleLink-1.7.10-4.1.1-2b3035b.jar to the /mods/ folder, reopened the official launcher, started the profile of Minecraft 1.7.10 with Minecraft Forge 10.13.2.1230, and the game crashed in the same place it had previously (immediately after the "Mojang" splash screen) and with the same error:
- Crash Report
Adding the "-Djna.debug_load=true" option to the shell script which starts the official launcher did not change the output of the launcher in the terminal in any of the test cases. In other words, the output from the launcher was the same as when the option was not present.I was not able to figure out how to view or redirect the output from the launcher's internal command that starts the actual game and contains the "JVM Arguments" with the "-Djna.debug_load=true" option. Its java command line starts "net.minecraft.launchwrapper.Launch" and has an "--accessToken" argument, so I'm not sure I could start it anyway without deep knowledge of the official launcher's code.
Edit: Corrected "-Djna.debug_load=tru" in the final two paragraphs to "-Djna.debug_load=true". It was a typo in this post, not in the script or launcher.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAfter the crash, in the launcher you will see an additional tab "Game Output (<your username>)" can you please post that one?
It should contain a line "Looking for library 'LinkAPI'" or "Found library resource at". It will be lines without a timestamp. You might also want to set the "Launcher Visibility" in the the profile to "Keep the launcher open".
Edit:
If you don't see anything related to the library loading please also set "jna.debug_load.jna" to "true". Also try with export as -D might not suffice.
Want Positional VOIP? Get the Mod for Mumble Support
I added export lines and set the jna.debug_load.jna property in the shell script that starts the launcher. I had to remove "-d32" from _JAVA_OPTIONS because java would not accept it in that variable.In the launcher's profile to start 1.7.10 with Forge, I set the following:
- Launcher Visibility: Keep Launcher Open
- JVM Arguments:
Here are the crash logs:http://pastebin.com/g2BKB5Sm
I'm on Ubuntu 14.04 and haven't modded Minecraft in 2 years. Apologies for any ignorance on my part for that, but I'm pretty good at troubleshooting and willing to try any suggestions you have or provide any data I can. We're trying to setup a server and would love to have positional audio for all the players. I've seen this work in the past and you've done awesome work. Thanks in advance!
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThat one is fairly easy, for some reason "Forge" itself was never loaded see here: http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/1272675-1-8-mumblelink-forge-smp-lan-mumble-realism?comment=374
Want Positional VOIP? Get the Mod for Mumble Support
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThis is what the whole jna debug stuff was for and what I was looking for:
This looks good, there seems to be no problem with JNA so it must by the library I am shipping.
Please do This will probably reveal that its compiled for 64 bit. It's the only explanation I have for now. If so then you must be the first to try this mod on a 32-bit linux and reporting the problem for almost a year.
Please download this file https://github.com/zsawyer/MumbleLink/raw/master/natives/build_linux32/libmod_MumbleLink.so and rename it to libLinkAPI.so and put it in the linux-x86 folder in your jar file.
If this does not work you can try to rebuild it yourself by checking this directory out https://github.com/zsawyer/MumbleLink/tree/master/natives (here is the complete repo) then running "make.sh". Refer to the ReadMe for the prerequisites.
Want Positional VOIP? Get the Mod for Mumble Support
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThat is not correct. This mod merely is a bridge ("link") between Minecraft and a Mumble client on your computer. You will still need a separate Mumble Server (Murmur) that everybody connects to using their individual Mumble Clients.
That way this mod is completely independent of IPs. This means you can host Murmur on a completely different machine than your Minecraft server or both on the same, what ever you like.
If you are hosting servers always remember to forward/open the appropriate ports or else no one will be able to connect.
The behavior you have described ("embedded server"), however, is what I would like it to be in the future. That would make things a lot easier and allow better control over who can hear who and such.
Want Positional VOIP? Get the Mod for Mumble Support
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumA normal player will only have to worry about the "Client" group of components: Minecraft (including Forge), MumbleLink, and Mumble.
Server admins will have to take care of Murmur (the Mumble Server) and the Minecraft server but the mod does not require any special setup on the server side! Just make sure that the Mumble Server supports positional data (default for Murmur).
The arrows indicate data flows, as can be seen there is a one-way direction of data going from Minecraft to MumbleLink to MumbleClient. That means there is no feedback coming from the Mumble Client to MumbleLink (we are pretty much clueless as to what happens after we gave the data to Mumble)!
All this is completely independent of the Minecraft Server.
The next diagram shows a more technical view of the workings.
FML (Forge Mod Loader) will load the MumbleLink mod and Forge itself.
MumbleLink uses also some Features of the Forge API (mainly configuration files and logging).
But most importantly it sends the positional data it retrieved from Minecraft using the LinkAPI native libraries (shipped with the mod).
Which in return are basically a bridge to hand the data over to the "Link Plugin" which is shipped with Mumble.
The Mumble Client can access the date that came through the Link Plugin.
Here two things are happening:
Internally the Mumble Client will use it's own data and the foreign data and calculate distances and headings to transform the audio signals so that they sound positionally and directionally attenuated. But it never sends the foreign data to MumbleLink!
Want Positional VOIP? Get the Mod for Mumble Support
I checked the release's library and the rebuilt library from your link with objdump:You were right. The library in the MumbleLink-1.7.10-4.1.1-2b3035b release was built for 64-bit. The rebuilt one you linked for me is built for 32-bit.
Minecraft opened properly without errors when the rebuilt library was copied into the jar.
There were some less serious problems upon testing, however. I tested it with a vanilla 1.7.10 server with one client on Windows and another on Ubuntu with the rebuilt library. Both computers were on a LAN (not across the internet).
First, Mumble's overlay in the corner of the game window that lists the users who are currently speaking never showed up on Ubuntu's Minecraft client.(Edit: Solution at bottom.) Second, to test positional audio, the Ubuntu user stood still while the Windows user walked away from them while speaking. I was expecting the volume that the Ubuntu user heard would decrease gradually as the Windows user walked away, but it decreased abruptly as if there were only two volumes: loud when near and suddenly quiet when far away. The Windows computer's CPU was near 90%, but I don't know if that affected the volume's slope. The Ubuntu computer only had speakers, not a microphone, so I was not able to test positional audio in the other direction with the Ubuntu user speaking.P.S. I understand it's easier for users to post bug reports on this forum, but following the conversations for a particular bug becomes less so. Have you considered using something more organized for the purpose such as an issue tracker or Github? It would keep each report's resolutions contained and able to be referenced from other issues and code edits. Users might have to register a username for the issue tracker, but issues could be easier to manage and follow.
Edit:
Linux overlay solution: start the game with mumble-overlay.This binary is usually installed with the mumble package, but Fedora Linux may need you to install a separate "mumble-overlay" package. The overlay can be configured in Mumble's top menu bar -> Settings -> Overlay.
http://wiki.mumble.info/wiki/Overlay#Overlay_on_GNU.2FLinux
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI do use an issue tracker but forgot to reference it in the OP. But this project's sources are all mainly hosted on GitHub and that has an issue tracker which I use.
https://github.com/zsawyer/MumbleLink/issues/7
As can be seen in the issue the problem with linux 32 bit systems should be fixed in the next release.
As to the second issue:
The Overlay is entirely handled by the Mumble Client I have nothing to do with that. Maybe you can try updating your Mumble or file an issue with them: https://github.com/mumble-voip/mumble/issues
For the choppy transition:
That is quite hard to figure out. You are right, it could be the windows client not being able send out the data in a proper interval.
To check if it is the windows client you can use MumblePAHelper on windows that will give you a gui and tell you which data MumbleLink sent (actually put into a shared memory). Simply open it alongside Mumble and Minecraft. If it updates properly then the Plugin (on Windows) does the best it can and the rest is up to Windows' Mumble Client or thereafter.
The described effect would also occur, if the Ubuntu's Mumble Client doesn't properly receive positional data from MumbleLink. However that update loop is run in a thread in Java so it should be platform independent. The only difference is the native library (.so). But it only differs in one way and that is the initialization of the shared memory. Updating is done the same way as on Windows where it is confirmed to work properly.
So there could also be an issue with the Mumble Client not fetching the data off of the pipe in a fast enough interval. Or it is simply bad Audio Processing on Mumble's Linux build - maybe cutting off floating point precision or something. Or the audio driver is flawed.
As you can see this is going to be a pain to figure out. Sadly there is no tool like MumblePAHelper for Unix afaik, but peeking into the shared memory would tell us if the mod MumbleLink is responsible for the sound transition problem.
Want Positional VOIP? Get the Mod for Mumble Support
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYou can either update your Java to 1.7 or newer, or try with Minecraft 1.8 instead.
Want Positional VOIP? Get the Mod for Mumble Support
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumEDIT: Nope, nevermind, it is fine.
The reason for my question is that we as a community meet in TS and only a handfull of us play MC and we don't have a Mumble server.
i know for sure that TS is capable of using directional voice (in ArmA II and III known as "ACRE"-mod).
so back to the point:
what does it take to get that working on TS too?
PS.: if that would derange too far from the OP topic, then tell me and i will gladly make it a separate Thread on the forum.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe github is my main repository now, the sourceforge one is out-dated.
Want Positional VOIP? Get the Mod for Mumble Support
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYes, that is already done and working to some extend from what I tested last, but with a little bug that was fixed which I couldn't test yet.
CrossTalk by Thorsten Weinz is using the data of the Mumble's Link-plugin (which this mod uses too) and can therefore fake as if it is Mumble. The data will be sent to Teamspeak and should work similar to what Mumble does.
(code block because quotes are bugged)
Well CrossTalk already does a good job at taking the Data meant for the Link-Plugin however the features ACRE provide is a whole different story. If you search this thread for ACRE you can see that I have already stated some thoughts about it.
The conclusion is that Mumble in it's current state is maxed out. ACRE features like distortion or terrain based amplitude manipulation is not possible.
That being said. A TeamSpeak-only mod plugin combination would be possible and actually I would love to see the ACRE-TS-plugin code. I am actually thinking that it would be possible to write (a new) Minecraft mod that would behave like the ACRE-Arma-Mod. So basically you could have ACRE installed on TS and both Minecraft and Arma mod's could use the same plugin.
For that we would need an interface definition of how and what data the ACRE plugin expects. With the way we can write mods, Minecraft can do all the things Arma can (in regards to ACRE stuff ofcourse).
Note that I have also stumbled upon a project where someone was creating a native voip mod so there would be no dependencies to any 3rd party tools like mumble or teamspeak. That might be a good alternative, it would be like the normal Arma voip. But I forgot the name and it wasn't bukkit or forge based, I think. I can't even remember if it supported directional.
Want Positional VOIP? Get the Mod for Mumble Support
i will download it right away.
Any feature on top of the basic directional voice and whisper key would be pure luxury in MC.
Still it would be cool to have those features too.
So to use this, i only need to start MC with your mod and TS with CrossTalk?
i'm going to introduce a few friends to this new feature now
Edit: tested with CrossTalk and when using the beta release, it works - with a few flaws - but it works.
So when they change those issues in future releases, it's fine.
Final conclusion (at the moment) : If you have a Mumble-Server, use Mumble instead of TeamSpeak.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThanks for the feedback. This mod was meant for Mumble after all so yeah - Mumble will probably work a better (for now).
However it is good to hear that is works with CrossTalk somewhat. Please do make sure to submit an issue, to let the dev know. I am also curious as to what the flaws are you have had. Maybe you can link me the issue then and to let Thorwe know if the issue I linked is fixed. Thanks
Want Positional VOIP? Get the Mod for Mumble Support