Krzmbrzl

I'm think I don't quite understand what you are referring to. You can already write direct messages to other clients (including bots) so I don't see what would be new in your suggestion... Could you elaborate a bit more on this?

Uhm removing m_bridge is certainly not a proper solution for this issue... My best guess without looking into it is that there was some update to the plugin interface during the development of 1.4.0 that has not been ported to the JSON bridge yet... Unfortunately I do not have the time to look into this myself right now but if you poke me again in about a month or so, I should be able to look into this. EDIT: Did you perhaps not build with static boost libraries and the dynamic ones are not in PATH so they can't be loaded when attempting to create m_bridge?

Normally the audio options are always saved and the audio wizard should only show up on first startup. Is perhaps the Mumble config file (~/.config/Mumble/Mumble.conf) removed between restarts? Which version of Mumble are you using?

Okay cool - I will adapt the code in the repo accordingly - thanks for reporting back 🙂

It should indeed be compatible but that is the wrong download link (it's for the windows version). Have a look at https://www.mumble.info/downloads/

@LilyC hm it seems as if the calling convention for the CloseHandle function is different for some reason. Could you try changing json_bridge/src/NamedPipe.cpp:157 (https://github.com/mumble-voip/mumble-json-bridge/blob/93a2aba680f3e9579842ff5b880532ed851fda0f/json_bridge/src/NamedPipe.cpp#L157) from using handle_t = FileHandleWrapper< HANDLE, BOOL (*)(HANDLE), INVALID_HANDLE_VALUE, true >; to using handle_t = FileHandleWrapper< HANDLE, decltype(&CloseHandle), INVALID_HANDLE_VALUE, true >; In theory that should automatically adapt to the required type whatever it might end up being. (And please let me know the result of this since in case this works, I would like this to be changed in the repo as well)

If you are looking into creating a Mumble plugin, I advise you to the following section of our developer documentation: https://github.com/mumble-voip/mumble/blob/master/docs/dev/plugins/README.md or more precisely:https://github.com/mumble-voip/mumble/blob/master/docs/dev/plugins/PositionalAudioPlugin.md I think the first thing that you should decide on is how you want the player positions to be fed from the game to the plugin. If you have access to the source code, using shared memory between the plugin and the game might be the easiest way to move the data around. Otherwise (especially if the game's code does not change (often)) you can also fetch the positions from the game's in-memory representation which does not require any changes to the game itself. You can take inspiration from e.g. the new Among Us plugin: https://github.com/mumble-voip/mumble/tree/master/plugins/amongus

Since you are building it from source, the only requirement is for your Boost version to already include the functionality that is used (the JSON Bridge does not ship with any prebuilt parts that you'd have to maintain compatibility with). Iirc the functionality required from Boost is quite basic so I would assume that pretty much any version of Boost that is not completely ancient should do. If in doubt, use the latest version.

If you are really concerned about your phone's lifespan I suggest not staying connected to Mumble while not needing it. And for me this does not justify making the UX for every other device worse.

No I don't think that will happen. Increasing the ping interval will also increase the time until the client realizes that it can't reach the server anymore (and is thus no longer connected to it). I don't think it would be good UX to increase this time...

Ah then I misunderstood your intent. You want to increase the ping interval - I thought you wanted to increase the amount of pings sent. But yeah as I said: This is a fixed property that you'd have to manually change in the source code and then run a custom build of the server and the client.

What do you mean? The ping-rate? That is hard-coded and can't be increased (I also fail to see why this would be useful)

I don't know the exact figure. I can only tell you that connected clients will send ping packets to the server (and the server sends them back) every (I think) 5 seconds. Each ping packet should only be a hand full of bytes big though. Other than that there should be no traffic. You can measure this data traffic easily though by connecting to a server with a local client and then simply monitoring that client's network usage with a tool of your choice.

@LilyC would you mind opening a PR on GitHub for this? Iirc there is also an open issue requesting (more or less) this feature so it would be nice if you could contribute that upstream 🙂

You'll have to implement that yourself or (probably easier) use a library in your plugin that provides you with this functionality. It will end up being exactly as easy/hard to do as in a regular C/C++ program.

It is something different. The plugin API allows for plugins running on different clients but that are connected to the same server to send messages to each other. And messages sent this way are then received via the onReceiveData function on the receiving end. The traffic goes through the regular Mumble connection though and not through any external ports or sockets.

Yes that seems to be the case

Well then I guess there is some logic implemented to pick that up first I guess xD It's expected to be an ini file (just checked the code to be sure)

Yes. By default Mumble does look for the ini only in specific folders and I think the current directory is not in that list...

Without looking into the details I'd assume that you are triggering the action too early. Instead setting a flag might be better that when set causes the window to show at a later point. However I think an RPC command is not the way to go since these are intended to remote control an already running instance of Mumble. Instead you should add this as a command line option

If the server only accepts users with a known certificate, then you will not be able to connect until an admin adds your new cert to the whitelist. However I assume that in your case you have been registered on that server with your old cert and are now connecting with your new one using the same username. That won't work. You'll have to pick a different (unregistered) name in order to connect. If you want your old name back, you'll have to ask the admin to delete the registration for that name for you.

I basically understood 0% of what you wrote. You'll have to draft proper sentences and at least partly adhere to correct spelling if you want others to understand you. From the location of this thread (in the iOS category) and from the bits I think I interpreted correctly from your message it seems that you are having issues with the Mumble iOS app. If that is the case I can only tell you that that app is currently completely unsupported since quite a while (a few years). Also none of the developers of that app is still part of the team and therefore we unfortunately won't be able to help you with it.

What do you mean by "in idle"? Connected to your Mumble server but not sending or receiving audio?

Feature requests should be made on GitHub and not here in the forums 🙂

Fancy 😄