acre2
acre2 copied to clipboard
IDI-Systems
Plugin - Add Mumble support
When merged this pull request will:
- Add Mumble Plugin - close #577
-
Requires ~a custom Mumble/Murmur version (coming soon)~ Mumble
1.4.*
-
Requires ~a custom Mumble/Murmur version (coming soon)~ Mumble
- Reorganize built plugins into sub-folders (
ts3andmumble) - Rename in-game "TeamSpeak" settings - All will reset!
- Improve auto-copy plugin
Some merge commit references are wrong due to different repository.
Has anyone tested if this works on Linux?
ACRE will not work under Linux unless something changed drastically. The blocker is not in the TS/Mumble plugins but on how the terrain is loaded.
It was brought to my attention that the "ACRE auto-installer" that tries to install the Mumble plugin on Arma start is trying to install the plugin into the Program files directory (where system-space plugins (aka pre-installed plugins) live). In order for this to work, Arma has to be started with administrator privileges which is not ideal. Instead ACRE should install itself into the Plugins directory in AppData\Roaming\Mumble where user-space plugins live.
We should probably fix that before this PR gets merged :point_up:
Another thing that should be updated is the log file location as was changed here: https://github.com/IDI-Systems/acre2/pull/1110 Maybe this is already fixed by bringing this branch up to date with the current master branch
Another issue: ACRE installs the 32-version of the Mumble plugin alongside the 64-bit one. This will cause Mumble to complain because that will cause an unloadable plugin to be present in the plugin directory. We should investigate whether we can figure out whether the host system is 32bit or 64bit and then only install the appropriate plugin on its own.
We should investigate whether we can figure out whether the host system is 32bit or 64bit and then only install the appropriate plugin on its own.
Should we? Why is incompatible plugin a problem? It won't be able to load it, isn't that it? TeamSpeak handles that gracefully.
That is something we tried to do in the past, but we had to look at the registry to search for a plugin. Sadly the registry was non-conclusive and it was error-prone.
Why is incompatible plugin a problem?
Because it indicates a problem (from Mumble's point of view). All plugins that are in the plugin install directory are meant to be just that: installed plugins. And if one of these is not loadable then that essentially means that there is an installed plugin that is broken. That's why Mumble complains.
Note also that Mumble would never install such a plugin into this directory in the first place and the manually placing the libs in there is not the intended way to get plugins installed. That's why Mumble reports this kind of stuff to the user.
That is something we tried to do in the past, but we had to look at the registry to search for a plugin. Sadly the registry was non-conclusive and it was error-prone.
Why did you have to search for a plugin? To me it seems that the solution suggested here on SO should do the trick just fine. No need to search for a Mumble plugin. And I think it is a somewhat safe assumption that users on a 64-bit system will also use 64-bit Mumble.
Note also that Mumble would never install such a plugin into this directory in the first place and the manually placing the libs in there is not the intended way to get plugins installed. That's why Mumble reports this kind of stuff to the user.
Maybe it could be an intended way? Installing plugins manually is something users in this year will see and just skip over, wouldn't integration with various games be way easier if Mumble would "support" automated installations?
And I think it is a somewhat safe assumption that users on a 64-bit system will also use 64-bit Mumble.
We can't just assume that. Ideally, we know the architecture of Mumble and can install the correct plugin.
wouldn't integration with various games be way easier if Mumble would "support" automated installations?
You already can do that by creating a plugin bundle that contains the 32bit and the 64bit version and then call Mumble with the path to the bundle as the argument. That will trigger Mumble's installer and Mumble will then choose the correct plugin to use.
We can't just assume that. Ideally, we know the architecture of Mumble and can install the correct plugin.
Why not? Do you think there is a significant amount of users that install 32bit software on an 64bit OS when there is a dedicated 64bit version of the software?
I agree that ideally we'd check Mumble's architecture and choose the appropriate plugin but I don't know how that is to be done. But I don't really have Windows experience for stuff like this so that doesn't have to mean much :thinking:
Why did you have to search for a plugin? To me it seems that the solution suggested here on SO should do the trick just fine. No need to search for a Mumble plugin.
You can have multiple instances of mumble installed. You have to search them
You can have multiple instances of mumble installed. You have to search them
First of all this is not really supported by Mumble. There currently is no such thing as a "portable Mumble installation" that could live somewhere self-sufficiently. If you indeed have multiple Mumble instances installed, they will use the same directories for plugins (at least for the user-space ones) plus the same registry keys for their settings and so on. Therefore: Having multiple versions of Mumble installed at the same time is something that ACRE probably doesn't have to worry about since that is not supported on Mumble's side to begin with.
I do believe that was possible. Was there even a user-space plugin directory before the plugin system rework?
Therefore: Having multiple versions of Mumble installed at the same time is something that ACRE probably doesn't have to worry about since that is not supported on Mumble's side to begin with.
You say "not really supported", but can the user still do it then in an "unsupported" fashion? I don't think it's a problem if user-space plugin directory is the same for all of them, but I would like to know beforehand what kind of potential issue reports we can get because of it.
Was there even a user-space plugin directory before the plugin system rework?
Yes there was but I would say that in 99% of all cases there were no plugins in it because all pre-installed plugins go into the system-space dir and I doubt many people have installed custom plugins before given the hassle of having to build them with the exact same compiler Mumble was built with in order for them to work.
You say "not really supported", but can the user still do it then in an "unsupported" fashion?
Yes but with the current state of the 1.4.0 installer that would require quite some work unless you are installing a 32-bit and a 64-bit version of Mumble. This is because the new installer currently doesn't allow you to specify an install directory so you would have to manually move the old install-dir somehow before installing another version.
Switching architecture would probably make this possible since then one version installs into Program Files whereas the other installs into Program Files (x86) :thinking:
In the case of the user manually installing multiple versions by moving install dirs I think ACRE should have no issue at all since the plugin for the old architecture also works for the new one and the user-space plugin dir is shared. And when switching architecture, the user will receive the already mentioned "Non-plugin found in plugin directory" error message.
Switching architecture would probably make this possible since then one version installs into Program Files whereas the other installs into Program Files (x86) :thinking:
And we come back to the problem of x86 and x64, which we should support if we can at all.
User-space plugin directory, as long as its well defined, is fine.
And we come back to the problem of x86 and x64, which we should support if we can at all.
The only way I currently see how this could work is executing Mumble from the command line and passing the plugin bundle to it, letting Mumble choose which version to install. Or accepting the error message that occurs for blindly copying both architectures into the plugin dir.
Other than that I don't see a different solution for this (except the "assume x64 on an x64 host" approach) :shrug:
Or accepting the error message that occurs for blindly copying both architectures into the plugin dir.
Does this break anything? As far as I know, it is more of a warning message. However I think it reads too much like "your plugin doesn't work!". Alternative would be a selection during auto-copy, but that's also just complicating things. I need to think more about this.
Does this break anything? As far as I know, it is more of a warning message.
No it definitely does not break anything. It is indeed only a warning.
However I think it reads too much like "your plugin doesn't work!"
Well that's exactly what is the case though. The reported plugin does not work. The fact that one and the same plugin is present in another architecture that can be (and is) loaded instead is something that Mumble can't know ^^
Alternative would be a selection during auto-copy, but that's also just complicating things.
Maybe this could be a selection that only has to be made for the first time the user starts Arma with ACRE and that then gets saved into the ACRE settings so that on next start ACRE already knows what to use/check for?
Personally I think a prompt would be almost as good as a completely automatic installation.
I need to think more about this.
Sure, no hurry :)
gets saved into the ACRE settings so that on next start ACRE already knows what to use/check for?
Don't even have to save anything, could check which plugin already exists. The only case not handled here is a change of which architecture of Mumble is installed. Although changing that would be even rarer.
Public Beta testing
The code as-is does seem to work as expected and therefore I think it is now time to get the build out to everyone interested in order for you to try it out yourselves. Mind yourself though: This really is only a beta test, so things might end up breaking/freezing.
Requirements
- A Mumble server running at least Mumble 1.4.x. You can download one at https://www.mumble.info/downloads/. If you don't have your own server hardware, you may also use my own Mumble server (see below).
- A Mumble client version 1.4.x (or higher - aka: self-compiled). The officially released 1.4 client can be downloaded from the official website.
- A build of the ACRE plugin that includes the Mumble plugin. You can either build it yourself from the branch of this PR (
mumble-plugin) or (probably more conveniently) download a pre-built version here. Note however that this version (atm) does not use SQFC (since the script compiler currently doesn't work on my system).
Server configuration
If you are using a fresh (unconfigured) Mumble server for your tests, you will probably want to configure it a bit, before diving in. To that end, perform the following steps
- Shut your server down
- Open a console and execute
mumble-server -supw <YourPW>where<YourPW>is the password you want to asssign theSuperUser(aka: administrator) - Start your server
- Connect to your server using the username
SuperUser. This should prompt you for a password, at which point you enter<YourPW>. - Once connected to your server as
SuperUser, use the context menu to add new channels to your server. I adise to create at least aLoungeand a channel calledACRE(you will be automatically moved into this channel once ACRE connects to the game (assuming you haven't configured a different channel name for that in-game)). - Re-connect to your server using a different username (As
SuperUser, you won't be able to talk to anyone)
Plugin installation
Upon starting Arma with ACRE loaded, the plugin will (most likely) be installed automatically. Ideally you should make sure that you don't have Mumble open at this point in order to not accidentally block write-access to the necessary files by having them open in Mumble.
The automatic installation may complain about missing access rights. Just click on Continue to start Arma normally.
Regardless of whether ACRE complained or not, it is advisable to check the plugin installation manually. For that, navigate to C:\Users\<YourUserName>\AppData\Roaming\Mumble\Plugins\ and verify that the ACRE DLLs are present in this directory. If they are not, you can manually copy the suitable DLL from the @acre2\plugin\mumble\ directory into here.
If ACRE installed the DLLs automatically, you will find two versions of the DLL in your AppData directory: one for 32-bit systenms and one for 64-bit ones. If you leave both DLLs in here, Mumble will warn about an invalid plugin file (the one using the foreign architecture). While this warning doesn't prevent ACRE from working, it may be annoying, so you might as well manually delete the DLL for the architecture that doesn't fit your PC.
Using my Mumble server
You can reach my Mumble server at 178.254.32.29 using the default port (Mumble will auto-fill that for you). You are free to use this server for your tests but be aware of the following:
- This is only a small server and it is probably not able to handle large amounts of clients - I don't know the limit but you will probably not want to create large-scale events on it
- This is my Mumble development test-server. That means that occasionally I will shut the server down in order to deploy a new version. That includes unstable versions that may do weird things when you are connected to it. While I generally expect it to work fine for you, most of the time, I can't guarantee that you won't connect to it and it will not work for you.
- For above reasons: If you are planning on performing a small organized test with a couple of people on that server, reach out to me first and I will try to make sure that I don't kill the server during that time :) Otherwise, you don't have to announce using that server for any tests, though.
- If you require any additional channels on the server, reach out to me and I will create them.
Feedback
I would love to get feedback from you. I think probably the best place at this point is the ACRE Slack channel which I am part of. Please report any issues you are encountering but also if the plugin seemed to have worked for you. This will help us/me evaluate how stable the plugin is currently functioning and which parts of it require more work.
The slack channel would also be the best place for asking questions about any kind of things related to this test (be it Mumble- or ACRE-related).
Fingers crossed it (mostly) works out well :crossed_fingers:
Yes, current plan:
- Update Plugin Auto-Copy to avoid warnings in Mumble about mismatched bitness.
- Release as a dev-build for testing.
Just need to find time for it.
Is this still being beta tested?
"still" might be too strong of a word. As of today, I have received exactly 0 (zero) reports of anyone having tried this out :shrug:
I've done a little bit of testing and have found the following issues.
- ACRE does not install the mumble plugins in
%APPDATA%\Mumble\Pluginsinstead it installs in%PROGRAMFILES%\Mumble\pluginswhich is a invaild folder and admin protected. See image at bottom - One player couldn't hear me while in zeus and they couldn't hear me while also in zeus
Everything else seems to work so far but I will still need to test more.
One issue unrealated to acre is one player could not connect to my mumble server or yours, they are on a edu network but my server logs show an attempted connection but says remote closed.
- is related to how ACRE currently tries to find the installation dir on its own and thereby bypassing the system that Mumble usually uses to install plugins 👀
- But other times the Zeus communication worked as expected?
The connection issues appears a bit odd to me... Maybe there was some kind of blocking involved that his network employed. But in that case I would have assumed that the connection wouldn't work at all (aka there is also no server log entry) :shrug:
Plugin auto-copy will now only copy to AppData/Roaming/Mumble/Plugins and only use Mumble installation itself to determine which architecture of plugin to copy (based on Program Files folder it is installed in). It will only install the same plugin architecture as the Mumble installation and avoid the warning in the chat window.
32-bit support for copying a 64-bit extension (or rather finding the architecture of installed Mumble) was also added.
Tested configurations (with fresh Mumble installs of version 1.4.230 and 1 time Mumble run to create AppData folders):
- 32-bit Arma/auto-copy to 32-bit Mumble -> copies only 32-bit plugin
- 32-bit Arma/auto-copy to 64-bit Mumble -> copies only 64-bit plugin
- 64-bit Arma/auto-copy to 32-bit Mumble -> copies only 32-bit plugin
- 64-bit Arma/auto-copy to 64-bit Mumble -> copies only 64-bit plugin
There are no official Portable installations for Mumble, so that was ignored, but it can still be done with the -mumblePath startup parameter. Both architectures of the plugin will be copied with that, as it is a development tool and not intended for general use.
See pinned items in ACE3 Discord #acre2 channel. It is an entirely separate build and the plugin will not work with stable release.
I'll just leave a small checklist of things that as of now require investigation/fixing:
- [x] ~~When ACRE shuts down, it seems like some thread is not terminating properly. Thus, Mumble seems to not be able to completely unload ACRE and if shut down while ACRE is active, the Mumble process will actually stay alive in the background and has to be terminated via the Task Manager.~~ EDIT: This seems to only happen when Tracy support is enabled. So probably unrelated to the core plugin code.
- [ ] Something in the processing loop appears to eat up a lot of performance when connected to Arma (with several other players). For further investigations Tracy support has been included in ACRE in my fork
- [x] The ACRE log in
C:\Users\<User>\AppData\Local\Arma 3still contains several error messages that should be investigated