Without the change the build fails on upcoming gcc-12 as:
/build/mumble/plugins/gtav/gtav.cpp:13:13:
error: 'unique_ptr' in namespace 'std' does not name a template type
13 | static std::unique_ptr< Game > game;
| ^~~~~~~~~~
/build/mumble/plugins/gtav/gtav.cpp:12:1:
note: 'std::unique_ptr' is defined in header '<memory>';
did you forget to '#include <memory>'?
11 | #include <cstring>
+++ |+#include <memory>
12 |
These addresses provide no additional meaningful data. The identity
context is supposed to identify an user, not provide meaningless info
about unrelated ingame objects.
Remove these unnecessary variables, as they only increase the amount of
work needed when reverse-engineering positional audio.
The username is already alone an unique identity, so instead of setting
the identity to a JSON of multiple values, we now set the identity to
just the username.
As per POSIX, basename(3) is defined in libgen.h. Without including
this header file the code presently does not compile (on musl) due to
`-Werror` and a `-Wimplicit-function-declaration` warning.
When performing a debug build, the "deadlock plugin" will be included
in the build, which uses the thread functionality of the std. However,
during compiling there would be an error about a symbol in thread.hpp
not being found (_beginthreadex). As it turns out, this was due to us
having a header file called Process.h, which would shadow the windows-
specific header file defining the mentioned symbol.
Therefore, in this commit we rename the Process base class to
AbstractProcess and rename the files accordingly, fixing that error.
See also: https://stackoverflow.com/q/27230258
This PR performs multiple things, all related to the Link plugin. For details, see the
individual commit messages.
Among other things, the Link plugin was ported to the new plugin API and the
different implementations for Windows as Posix where unified into a single implementation.
Fixes#5217
The sendData API call requires the server to be of version 1.4.0 or
newer to work. Thus, when calling this API function while connected to
an older server, we can already tell that this won't work. Previously
this was silently ignored.
This commit introduces a new API error that will inform the user about
this problem. This should clear up the confusion as to why the sendData
call is apparently not doing anything.
Fixes#5331
Co-authored-by: Davide Beatrici <github@davidebeatrici.dev>
This commit adds a small CLI program that just connects to the Link
plugin and sends random positions to it. It is meant to be used as a
test-case for the Link plugin.
This commit merges the two separate Link plugin implementations that
were previously used (one for Posix and one for Windows systems) and
merges them into a single one (abstracting away the platform differences
at most places).
While doing so, this commit ports the "Link" plugin to the new plugin
API (introduced with Mumble 1.4.0), such that it can make use of the
possibility to set a custom context prefix. Thus, this prefix is no
longer dependent on the plugin name (in Link's case it is set to
whatever the linked application declares as its name).
Fixes#5217
This typedef can be used by plugins that don't want to hard-code the
type of the Mumble API type (which contains the API's version) into
their source code.
If this typedef is used, a newer API can be used simply by including a
different API header.
Using the API functions from outside the "main thread" would cause them
to block until the request can be processed on the main thread. This
could easily produce a deadlock if used without caution.
These changes add a timeout for this waiting turning preventing
deadlocks because the calling thread won't be blocked indefinitely. In
case of a timeout, a special error code is returned.
Using the API functions from outside the "main thread" would cause them
to block until the request can be processed on the main thread. This
could easily produce a deadlock if used without caution.
These changes add a timeout for this waiting turning preventing
deadlocks because the calling thread won't be blocked indefinitely. In
case of a timeout, a special error code is returned.
Instead of excluding all plugins but the link one on OSes other than
Windows and Linux, the new approach allows for a more granular control
by introducing a list of plugins that is supported on the different
platforms.
This replaces the globbing approach which means that new plugins have
now to be included in this list explicitly.
The advantage of this is that this allows for a much greater flexibility
for handling plugins on different OS.
Furthermore the plugin's own directory is no longer added to the
include-path by default. If a plugin wishes to do this, it should do so
explicitly. This should help make the plugins easier to move around in
the future.
Our Source Engine plugin retrieves the interfaces on Linux through "s_pInterfaceRegs", an exported symbol.
Left 4 Dead 2 just received a big update and the binaries don't have the DT_HASH table anymore.
As a result, the plugin was not finding the symbol anymore.
This is basically a follow-up to 6f19d7ebfd, which implemented support for DT_GNU_HASH in the overlay code.
This particular API function was implemented to only set the respective
settings variable. However this would not notify any other code part
about the change resulting in a potential inconsistency between the UI
and the actual settings.
Therefore the implementation now delegates the actual setting of the
transmission mode to MainWindow::setTransmission mode that takes care of
emitting the appropriate signal and informs the user about a change in
transmission mode.
This particular API function was implemented to only set the respective
settings variable. However this would not notify any other code part
about the change resulting in a potential inconsistency between the UI
and the actual settings.
Therefore the implementation now delegates the actual setting of the
transmission mode to MainWindow::setTransmission mode that takes care of
emitting the appropriate signal and informs the user about a change in
transmission mode.
There were a few types left that were not prefixed with "Mumble" in one
way or another. In order to avoid name clashes, this was now changed.
Especially enum values are now also prefixed. This is because these are
not enum classes (C doesn't know those) and as such the enum values are
used without a namespace (thus they are effectively global names).
Furthermore the macros STATUS_OK and VERSION_UNKNOWN were turned into
constant variables in order to use the preprocessor as little as
possible.
The windows header was included for the definition of M_PI. However
given that we define _USE_MATH_DEFINES globally for all source files and
cmath is included already, this symbol is defined by cmath, making the
windows-specific header superfluous.
I was wrong in d7f0302ce7.
Turns out Toolhelp32ReadProcessMemory() is simply a wrapper for ReadProcessMemory() that takes care of opening an handle to the process and closing it.
For reference: https://github.com/MicrosoftDocs/sdk-api/pull/793
The windows header was included for the definition of M_PI. However
given that we define _USE_MATH_DEFINES globally for all source files and
cmath is included already, this symbol is defined by cmath, making the
windows-specific header superfluous.
PluginComponents uses this check to determine if Qt library is already used so we don't want to force a Qt include.
Unity build triggered this since I believe it moved the header into a different compilation unit or compiled it first.
QT_VERSION requires #include <QtGlobal> before using it.
From: https://stackoverflow.com/questions/24899558/how-to-check-qt-version-to-include-different-header
QT_CORE_LIB is set by CMake
From: https://stackoverflow.com/questions/30840176/what-preprocessor-can-i-used-to-detect-if-qt-is-used-to-build-my-codes
Alternate solution could be using __if_include per https://forum.qt.io/post/564320 . But that appears to require C++17 mode.
Error log:
In file included from src/mumble/CMakeFiles/mumble.dir/Unity/unity_1_cxx.cxx:4:
... /src/mumble/PluginInstaller.cpp: In member function ‘void PluginInstaller::init()’:
... /src/mumble/PluginInstaller.cpp:149:92: error: no matching function for call to ‘QString::QString(mumble_version_t&)’
149 | .arg(pluginVersion == VERSION_UNKNOWN ? "Unknown" : static_cast< QString >(pluginVersion))
Co-authored-by: Robert Adam <dev@robert-adam.de>
This commit introduces a new plugin framework into the codebase of the
Mumble client. Note that "plugin" here really refers to a (more or less)
general purpose plugin and is therefore not to be confused with the
previously available positional data plugins (only responsible for
fetching positional data from a running game and passing that to
Mumble).
The plugin interface is written in C, removing the compiler-dependence
the old "plugins" had. Instead plugins can now be written in an
arbitrary language as long as that language is capable of being compiled
into a shared library and also being capable of being C-compatible.
As already indicated a plugin is essentially a shared library that
provides certain functions that allow Mumble to interface with it.
Inside Mumble the so-called PluginManager is responsible for managing
the plugins and relaying events to the respective callbacks. Plugins
themselves can also interact with Mumble on their own initiative by
using the provided API functions.
Fixes#2455Fixes#2148Fixes#1594Fixes#2051Fixes#3742Fixes#4575Fixes#4751
Apparently the first commit (59ae429972)
did not include all files.
Furthermore the used script tended to produce funny results in certain
cases. This has been fixed and as a result thereof a few more changes
were made in this second run.
This is needed in order for the <cmath> header to also define constants
like M_PI. Instead of manually defining the macro every time before
including <cmath>, the macro is now defined via cmake and thus always
defined.
