Looks like targets are now built concurrently, which results in the installer failing to find the G15 and x64 overlay helpers.
This commit marks the G15 and overlay targets as dependencies of the client, when they're enabled.
As a bonus, plugins are now tied to their own dedicated target rather than the client's.
This is required because the client's subdirectory is now included later on.
This `VirtualQueryEx()` loop is called for each module in a
process. It reads pages starting at the module address but seems to
continue past into other modules and into dynamic allocations also.
This check stops enumerating pages once it encounters one that no longer
belongs to the module for which pages are being collected.
(Also this function opens two handles, this adds a clean up for the
first handle if opening the second fails.)
Fixes#6558
The new header (as introduced via
2b35c0c28f) was missing a typedef and a
utility macro for dealing with the versioned MumbleAPI struct.
Furthermore, plugins that are only build in debug builds were still
including the old (and now non-existing) headers.
The bug was introduced in 13cbf72877.
It was only reported last year and because of a side effect: consistent lag for the entire application.
That's something that should be dealt with independently.
Having different include files that are needed (and which are
inter-dependent) to create your own plugin, makes things harder than it
needs to be.
Therefore, all plugin header files (those for the "new" (1.4) plugin
framework anyway) have been combined into one header file. Thus,
developers now only have to download a single file and include that
instead of having to figure out what files to download and what to
include where.
Taking the chance, the version number has been removed from the header
file's name. This allows one to track changes made to the API via git
(which is not quite as easy if you create a new file every time you make
a change).
The Link plugin uses an inherently racy protocol to communicate with
applications: shared memory with no means of synchronization. This
commit makes no changes to this protocol and shouldn't break anything
that was working before. That means it doesn't eliminate race
conditions, but it does allow the plugin to work without the risk of
*data races* specifically, which are undefined behavior.
This is done by using 32-bit atomic operations to copy the LinkedMem
struct out of shared memory before reading from it. This should work
well, since every field of LinkedMem has a size that's a multiple of
32 bits, and 32-bit atomics are widely supported.
With this change, applications can avoid data races with the Link
plugin by also accessing shared memory exclusively with 32-bit atomic
operations. Applications that already work with the plugin should
continue to work.
Previously all notification sounds were played as is, without
taking anything into account. The only way to change the
volume was to manually edit the sound files, or change the
overall volume of the entire Mumble application.
This commit adds the ability for the user to adjust the
volume of notification sounds and audio cues. There are two
new settings added "notificationVolume" and "cueVolume"
to adjust the volume independently. Sliders in the "Messages"
have been added and together with the existing TTS volume
slider make up the new group "Message Volume".
A side effect is the centralization of the db <-> factor
conversion functions in the "VolumeAdjustment" class.
Furthermore, this commit also introduces a change to the
"playSample" API call, accepting a volume parameter,
and therefore bumps the Mumble API version to 1.2.x.
Implements #3963
Without the change mumble build fails on this week's gcc-13 snapshot as:
plugins/Module.h:13:9: error: 'uint64_t' does not name a type
13 | typedef uint64_t procptr_t;
| ^~~~~~~~
plugins/Module.h:12:1: note: 'uint64_t' is defined in header '<cstdint>';
did you forget to '#include <cstdint>'?
11 | #include <unordered_map>
+++ |+#include <cstdint>
12 |
Co-authored-by: Davide Beatrici <github@davidebeatrici.dev>
The "spectator" property address was slightly off, which prevented the
plugin from working at all. Additionally, the previous "map" address
only worked for listen servers.
I've corrected the first, and found a new, properly-working address for
the second.
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.
