Jump to content
Mumble forums


  • Posts

  • Joined

  • Last visited

Everything posted by LilyC

  1. I am trying to use the NamedPipe implementation to communicate with the Mumble JSON bridge in my code. I am a little confused on how to read from the pipe, because I cannot understand how to get a handle to it. In NamedPipe.h, the comments for create() say "If such a pipe (or other file) already exists at the given location, this function will fail." However, (if I am understanding correctly) it looks like that is what is happening (and not failing) in the test code: In Bridge.cpp in Bridge::doStart(), the pipe gets created with m_pipe = NamedPipe::create(s_pipePath); and then in test_pipeIO.cpp in setupPipeReader(), it looks like the pipe is created again to get the handle. m_testPipe = NamedPipe::create(pipePath); ASSERT_EQ(m_testPipe.getPath(), pipePath); test_read(); I am curious if I am interpreting this correctly, and what the proper way to get a handle to the NamedPipe would be?
  2. Yeah I think that makes sense Sure!
  3. I think adding a line to the README on the CLI page like that and an example of a successful response would be very useful. A few things I was also confused on during development was what the name of the pipe was supposed to be. I also didn't realize that there was a "--help" option for the CLI, and I think it would also be useful to mention that the JSON arg should be in quotes. I also didn't realize I was meant to use the vcpkg.json (most likely due to my inexperience with vcpkg) so noting this and how to install the dependencies could be useful.
  4. Gotcha. I didn't realize this was supposed to be the order of input. Whelp I guess I had a typo when I ran it last, because this time it gave the correct output and not a syntax error 🤦‍♀️ Thank you for your help!
  5. When hitting "Enter", "Ctrl + D", and "Ctrl + Z" it did not return. "Ctrl + C" returned, but kills the process. I tried adding the "--json" arg and sending the JSON itself with quotes, without quotes, tried escaping the quotation character in the actual JSON... mumble_json_bridge_cli.exe --json "{"message_type": "operation","message": {"operation": "get_local_user_name"}}" mumble_json_bridge_cli.exe --json {"message_type": "operation","message": {"operation": "get_local_user_name"}} mumble_json_bridge_cli.exe --json {\"message_type\": \"operation\",\"message\": {\"operation\": \"get_local_user_name\"}} mumble_json_bridge_cli.exe --json "{\"message_type\": \"operation\",\"message\": {\"operation\": \"get_local_user_name\"}}" and ended up with similar parser errors: [ERROR]: [json.exception.parse_error.101] parse error at line 1, column 2: syntax error while parsing object key - invalid literal; last read: '{m'; expected string literal [ERROR]: [json.exception.parse_error.101] parse error at line 1, column 17: syntax error while parsing value - unexpected end of input; expected '[', '{', or a literal I was at least able to get one method of input working (I changed the command to 'toggle_local_user_deaf' since it was easier to see if there was an effect or not): On the command line, I ran mumble_json_bridge_cli.exe then passed in the JSON { "message_type": "operation", "message": { "operation": "toggle_local_user_deaf" } } Then hit "Enter", then "Ctrl + Z", then had to hit "Enter" again and this gave the proper response { "response": { "function": "requestLocalUserDeaf", "return_value": 0, "status": "executed" }, "response_type": "api_call" }
  6. I've tried running the CLI and passing { "message_type": "operation", "message": { "operation": "get_local_user_name" } } and then hitting "Enter", "Ctrl+D", "Ctrl+Z", or "Ctrl+C" after the commands, but this does not output anything. I also tried passing in the same information as a command line argument (but formatted on one line): mumble_json_bridge_cli.exe {"message_type": "operation","message": {"operation": "get_local_user_name"}} But this produced a parsing error ([ERROR]: [json.exception.parse_error.101] parse error at line 1, column 1: syntax error while parsing value - unexpected end of input; expected '[', '{', or a literal). I also tried running the CLI from a standard command line and passing in the same information as above, but this also did not output anything when using the different signals. I also tried running the CLI from Cygwin in case it behaved differently in Unix, but got the same output.
  7. New question that I should probably figure out first: I enabled the JSON Bridge plugin in Mumble and ran the following in Powershell to see what named pipes were running: [System.IO.Directory]::GetFiles("\\.\\pipe\\") | Select-String -Pattern mumble The output was "\\.\\pipe\\Mumble" which I believe is for Mumble generically and not the plugin (if I disable the JSON Bridge plugin, the output of the Powershell command is still the same). No errors show in the Mumble log. Am I missing something to get the pipe created successfully? UPDATE: I am not sure what was wrong, but I rebuilt the plugin and the PS command above now shows that the mumble json bridge pipe is running.
  8. Oh yes I will definitely try to change the vcpkg name and get back to you! I am curious now how to properly use the mumble JSON bridge- I tried using the CLI, but I am unsure if I am using the proper syntax. I installed and enabled the plugin in Mumble, connected to a server, and ran the mumble_json_bridge_cli.exe. I tried passing the following code through the CLI from the example in the CLI readme: { "message_type": "api_call", "message": { "function": "getActiveServerConnection" } } but I am not sure where the output is supposed to be, or if I am missing steps. I also want to use named pipes in my C++ code. Is it required to use the headers from "include/mumble/json_bridge" in order to interface with the plugin?
  9. I ended up changing the code so that Mumble always looks in the plugins folder that's next to the executable. Not perfect, but portable enough for what I'm doing. Thanks for your info!
  10. Wow I feel very foolish... I had thought I built with Boost static libs but it turns out they were dynamic, and adding it to PATH like you said worked 🤦‍♀️ I am unfamiliar with vcpkg and I am now trying to figure out how to specify the static versions of the libraries, since I think this would be easier to deal with.
  11. Yeah I wasn't trying to remove m_bridge as an overall solution, I was just trying to narrow down what could be causing the issue. I downloaded Boost with vcpkg using the manifest file that was available. It looks like it chose the proper static libraries. I will probably do some digging around in Mumble as well. But it has also been about a month or so, so here is a friendly poke 😛 @Krzmbrzl
  12. Thank you for the quick response. I am a little confused about how the relative paths work in mumble.ini because if I specify a relative path for the database file such as [General] databaselocation=./mumble.sqlite it creates the sqlite file next to my mumble.exe (which is not in my Mumble cache). If I remove the databaselocation line, it creates a sqlite file next to the mumble.ini file (which is in my Mumble cache).
  13. I am trying to make a portable version of Mumble with the Link.dll enabled by default. In mumble.ini, I have tried setting the first line to be "./Plugins/Link.dll" and "%appdata%/Mumble/Plugins/Link.dll", but both do not enable the plugin. I do not think Mumble is properly seeing where the plugin is. [plugins] Link__c8cec245e7abc9a2c016ad60ba0fd87907bd8c68\path=./Plugins/Link.dll Link__c8cec245e7abc9a2c016ad60ba0fd87907bd8c68\enabled=true Link__c8cec245e7abc9a2c016ad60ba0fd87907bd8c68\positionalDataEnabled=true Link__c8cec245e7abc9a2c016ad60ba0fd87907bd8c68\allowKeyboardMonitoring=false I am also unsure what the hash value appended to the name of the plugin is- does the hash have to match up with the file location or otherwise affect how Mumble loads the plugin?
  14. Thank you for the quick turnaround on the fix! I was able to successfully build the project. However, I was trying to install the json_bridge_plugin.dll into my locally built version of Mumble (that supports the installation of plugins), but Mumble gave me this error: Unable to load plugin "json_bridge_plugin.dll" - check the plugin interface! If I place the plugin manually into Mumble's plugin directory, I get: Non-plugin found in plugin directory: "C:/mumble/out/build/x86-Release/plugins/json_bridge_plugin.dll" After poking around a bit, I realized that if I removed the m_bridge variable (specifically, if it is not in the constructor) in mumble-json-bridge\plugin\plugin.cpp then I am able to install the plugin. Is there a way to fix this so that the plugin can be installed properly?
  15. @Krzmbrzl That change fixed the error, thanks!
  16. Thank you. I ended up using Boost 1.77, compiled for Win32. I am also using Visual Studio 2019 command line to build, with toolset 14.29.30037. When I try compiling, I get the following error (and other similar errors): C:\mumble\mumble-json-bridge\json_bridge\src\NamedPipe.cpp(227): error C2664: 'Mumble::JsonBridge::FileHandleWrapper<HANDLE,BOOL (__cdecl *)(HANDLE),0xffffffff,1>::FileHandleWrapper(handle_t,close_handle_function_t)': cannot convert argument 2 from 'BOOL (__stdcall *)(HANDLE)' to 'close_handle_function_t' with [ handle_t=HANDLE, close_handle_function_t=BOOL (__cdecl *)(HANDLE) ] and [ close_handle_function_t=BOOL (__cdecl *)(HANDLE) ] C:\mumble\mumble-json-bridge\json_bridge\src\NamedPipe.cpp(229): note: This conversion requires a reinterpret_cast, a C-style cast or function-style cast I am currently trying to change to a newer toolset since I know FileSystem was handled differently in different versions of Visual Studio. Would you have any other suggestions of what to look into if this does not work?
  17. Hello, I am attempting to build the json_bridge portion of the Mumble JSON bridge. I am using cmake 3.18 and am unsure what version of Boost I am meant to have. I know that Boost is not great with backwards compatibility, so I am curious what version of Boost should be used to build this?
  18. @Krzmbrzl I could do that at some point in the next week 🙂 Also, an update to the previous post: since spawning the settings menu doesn't require any user input/data, I didn't actually need to make the OpenConfigEvent class and could just do iter = qmRequest.find(QLatin1String("settings")); if (iter != qmRequest.constEnd()) { qApp->postEvent(Global::get().mw, new QEvent(static_cast< QEvent::Type >(CO_QEVENT))); } in SocketRPC.cpp. And then I followed the logic for handling a OU_QEVENT in order to know what to do for my custom CO_QEVENT.
  19. Krzmbrzl was right, the action was being triggered too early (thanks for your help!). For anyone else interested, I ended up using an rpc command, and did something like this in SocketRPC.cpp: OpenConfigEvent *oce = new OpenConfigEvent(); qApp->postEvent(Global::get().mw, oce); I essentially just followed how the OpenURLEvent was set up/used and made my own custom OpenConfigEvent.
  20. LilyC

    Using MumbleLink

    I was trying to get my program to talk to the plugin using sockets. I am curious how onReceiveData() in MumblePlugin.h is meant to work- is it a listener on the address and port a user is connected to on Mumble, or something entirely different? What triggers it? If this is not the way to go for socket connections, is there a different easy way to use sockets with the plugin?
  21. Haha okay So in that case, would putting mumble.ini in the same directory be the same as what one would accomplish using the --config argument?
  22. Oh. I was able to load a specific Mumble configuration by putting mumble.ini next to mumble.exe. When using the --config argument, is it an ini file that is supposed to be passed, or a different file format?
  23. Is putting Mumble.ini next to Mumble.exe functionally different from using the `--config` option when running Mumble?
  • Create New...