Supports the 1.0 version of Grand Theft Auto: San Andreas, the only one supported by multiplayer modifications.
The camera's vectors are synced with the avatar's ones; in future we should locate the camera's CMatrix in the game's memory and retrieve the proper values.
No context/identity support; in future we should at least add the context (e.g. server IP address + port) for Multi Theft Auto and San Andreas: MultiPlayer.
We used to use DIST for referencing extra files that should be included
in our tarballs created by 'make dist'.
However, we've since migrated away relying on 'make dist' in release.pl.
Instead, we include everything, and have a list of items to exclude, such
as IETF RFC drafts distributed in 3rdparty/speex-src that do not adhere to
the Debian Free Software Guidelines.
The machinery needed to support the "manual" plugin as a DLL
file on Windows is very complex.
This is because we build Mumble itself as mumble_app.dll and link
our dependencies statically. And also because of various changes
made in Qt 5.
The manual plugin uses Qt. When Mumble linked dynamically against
Qt4Gui.dll, etc. - everything worked fine. The manual plugin simply
linked against the same DLLs.
With the move to mumble_app.dll, we also moved to statically link
against Qt for mumble_app.dll.
To accommodate the manual plugin, we implemented various hacks to
export the Qt symbols from mumble_app.dll that were necessary for
loading the manual plugin.
And that worked for a while.
However, right now, with Qt 5.6, the plugin is broken. And I get
a lot of weird crashes when interacting with the manual plugin.
Most of it boils down to the fact that both manual.dll and mumble_app.dll
have copies of statically initialized data, like QArrayData::shared_null.
Sharing objects between mumble_app.dll and manual.dll in this scenario is
impossible, because using the object in one module will cause one set of
statically initialized data to be used, while use in the other will cause
the other data to be accessed. This is especially bad for things that use
reference counting, because it'll get out of sync.
So, to get rid of this mess, we're moving the manual plugin into Mumble
itself. Functionally, it doesn't change anything. The manual plugin could
not be auto-updated because it depended on a specific Qt and Mumble
version. Mostly because it depended on the correct set of Qt symbols to be
exported from mumble_app.dll.
The plugin now works correctly, and we can safely remove a lot of the
hacks that were required to load the manual plugin in its earlier
incarnation.
The only downside is that we can't test the manual plugin in PAHelper.
But that wasn't really the case before either, because the plugin
practically depended on Mumble to run.
With this change, CONFIG(static) on Windows will cause the Mumble client's
application logic to be built into a .DLL called mumble_app.dll
(based on pcgod's previous DLL changeset).
Since src/mumble will now be built as a DLL, a wrapper executable is available
in src/mumble_exe. This wrapper is currently implemented such that it will
load mumble_app.dll from the directory that it resides in.
This means that when building statically, src/mumble and src/mumble_exe will
now give us the following products:
src/mumble: mumble_app.dll
src/mumble_exe: mumble.exe
Along with the two major points above, this change also adds a Python script
to the build, 'gen-mumble_app-qt-def.py', whose job is to construct a module
definition (.def) file for mumble_app.dll. The generated module definition
lists the Qt symbols that are needed for the manual positioning plugin to work.
If we need to expose more symbols in the future (say we want to implement
more plugin kinds than the current positional audio plugins), we now have
the infrastructure in place to do that.
