This allows plugins to use MUMBLE_PLUGIN_EXPORT
instead of __declspec(dllexport) -- but get the
same behavior on MSVC/Windows.
This is part of the effort to allow Windows PA
plugins to work with Wine games on Linux.
The mumble_plugin.h header is used in more places than on Windows,
but the HWND type is Windows-specific.
This has caused problems in the past, forcing all users of mumble_plugin.h
to define a fake HWND type.
We recently began passing 0 to the about() and config() plugin functions
unconditionally -- so they are practically unused.
Therefore, it makes no sense to use the HWND type anymore.
Because of that, this commit changes the HWND type to void *.
It is ABI compatible with HWND.
Probably it has been changed by this update: http://www.l4d.com/blog/post.php?id=22630
It mentions only fixes for the MacOS version, but also the Windows one got a small update.
Also:
Removed wrong comma in identity at line 103.
Moved "std:endl" in the identity item's line.
Removed extra zero in memory addresses.
Removed empty line at the end of the file.
Probably it has been changed by this update: http://www.l4d.com/blog/post.php?id=22630
It mentions only fixes for the MacOS version, but also the Windows one got a small update.
Also:
Removed wrong comma in identity at line 103.
Moved "std:endl" in the identity item's line.
Removed extra zero in memory addresses.
Removed empty line at the end of the file.
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.
If a plugin implements MumblePluginQt, it is a signal to Mumble
that the plugin wishes to use Qt-based about and config dialogs.
The MmublePluginQt interface includes two methods: "about" and
"config".
Mumble will call these methods with a pointer to a QWidget that
is suitable to be the parent for the plugin's about and/or config
dialogs.
The MumblePluginQt interface is only useful for plugins that use Qt.
That, for now, is only the "manual" plugin. In general, plugins can't
really use Qt unless they're very tightly coupled to Mumble.
The idea is that we can use the CONFIG option until we've fixed the
remaining plugins.
Once all plugins have been transitioned over to the new explicit
pointer types, we can drop the mumble_plugin_win32.h header and
point people to mumble_plugin_win32_x86.h and mumble_plugin_win32_x64.h.
This is accomplished by making a 'generic' header,
mumble_plugin_win32_ptr_type.h
This header requires files that include it to
define PTR_TYPE and PTR_TYPE_CONCRETE.
In the old-style mumble_plugin_win32.h, PTR_TYPE
is set to 'void *', and PTR_TYPE_CONCRETE is
set to 'BYTE *'. The pModule varaible and the
getModuleAddr functions return PTR_TYPE_CONCRETE,
whereas the peekProc functions take PTR_TYPE.
The new-style arch-specific headers use the same
value for PTR_TYPE and PTR_TYPE_CONCRETE. The x86
variant uses procptr32_t. The x64 variant uses
procptr64_t.
Added:
Context/Identity escape function
Map name in identity
Improved:
Horizontal and vertical view memory addresses changed, the new ones are updated in real-time
Team names
Fixed:
Avatar/Camera front and top vectors calculation
Wrong comment at line 140
Game version: 1069
http://steamcommunity.com/games/282440/announcements/detail/876328108049672536
Added:
- Correct avatar position (the one used before was the camera one)
- Camera position
- State value
- Context based on server ID
- Server name in identity
- Map name in identity
- Player nickname in identity
Game version: 2.1.4.6
http://www.l4d.com/blog/post.php?id=22240
The previous code accidently used the
C-string "host" and "serverID" variables
in the JSON output for the context and
identity.
To avoid too many changes, this commit
changes the JSON escape function to
work on C strings instead, and uses
that to escape the "host" and "serverID"
strings from the game before emitting
them into the JSON documents.
This commit also adds some extra code
to ensure that the game strings we
include in the JSON document are
within the printable ASCII range.