Missing files in repository

[remcoros]

I try to build this, but I get some errors on files not found (are these missing from the repo?)

WARNING: d:\3rdparty_projects\CrossTalk\CrossTalk.pro:98: Unable to find file for inclusion DSPFilters\DSPFilters.pri WARNING: d:\3rdparty_projects\CrossTalk\CrossTalk.pro:123: Unable to find file for inclusion src\positional_audio\PositionalAudio.pri WARNING: d:\3rdparty_projects\CrossTalk\CrossTalk.pro:98: Unable to find file for inclusion DSPFilters\DSPFilters.pri WARNING: d:\3rdparty_projects\CrossTalk\CrossTalk.pro:123: Unable to find file for inclusion src\positional_audio\PositionalAudio.pri WARNING: Failure to find: src\settings_radio.cpp WARNING: Failure to find: src\settings_radio.h WARNING: d:\3rdparty_projects\CrossTalk\CrossTalk.pro:98: Unable to find file for inclusion DSPFilters\DSPFilters.pri WARNING: d:\3rdparty_projects\CrossTalk\CrossTalk.pro:123: Unable to find file for inclusion src\positional_audio\PositionalAudio.pri WARNING: Failure to find: src\settings_radio.cpp WARNING: Failure to find: src\settings_radio.h

[thorwe]

Yep they are.

I had hold back the radio module for first figuring out how to elegantly include the DSPFilters in the repo without hard-copying. It's https://github.com/vinniefalco/DSPFilters?source=c btw. The git submodule technique would bring research papers, demos and what-not in, so I just had put it on make-my-mind-up about it later mode. I'm currently unsure why it leads to such an amount of Warnings, as I had used the include(DSPFilters/DSPFilters.pri) as conditional for actually including the radio module altogether in the .pro.

The postional audio module, well, I don't know what you're talking about! ;D That's gonna be the next module introduced, which I put it on a private repo due to plugin communication security flaw fearings (i.e. funny folks sending garbage to mess things up, the teamspeak environment seems to be not entirely free of those types..).

This issue should be avoidable by commenting out CONFIG += beta in the .pro, excluding the positional audio module.

[remcoros]

Ok, I can add the filters by hand and remove the beta config.

that still leaves these two:

WARNING: Failure to find: src\settings_radio.cpp WARNING: Failure to find: src\settings_radio.h

[thorwe]

Yep, they should've been put in the include(DSPFilters/DSPFilters.pri) {}, while they are in all-included HEADERS, SOURCES above. I have forgotten to move them.

[thorwe]

Will be committing the radio module excluding the DSPFilters shortly, so you can compile.

[remcoros]

ok nice, thanks.

[thorwe]

Commited. I think you should be able to compile the complete thing without positional audio starting with (https://github.com/thorwe/CrossTalk/commit/87509c173eaea57ed905753b6f8450c96e629f51). Fix for https://github.com/thorwe/CrossTalk/issues/5 is also included (though quick search'n'replace without proper double checking).

[remcoros]

Still missing the 'DSPFilters/DSPFilters.pri' file.

[thorwe]

https://github.com/thorwe/CrossTalk/commit/210acb491ad3a1b4dee67a2678731cf20e2ca709 Since I can easily correct this once I figured out the best approach, I just added the complete DSPFilters.

[remcoros]

It compiles now, nice

[remcoros]

Btw. what is the correct way to build the crosstalk_win32 / crosstalk_win64 dll files?

I have no experience with Qt / C++.

Using Qt 4.8.4 and Visual Studio 2012::

qmake nmake release

How do I build/make this so I can correctly copy these dll's to teamspeak and use it?

[thorwe]

I don't really know how I could export those settings in QT-Creator, so... I set up two "Kits", one for x86, one for x64, Resulting qmake is qmake.exe CrossTalk.pro -r -spec win32-msvc2008 "CONFIG+=release" TARGET=crosstalk_win64 qmake.exe CrossTalk.pro -r -spec win32-msvc2008 "CONFIG+=release" TARGET=crosstalk_win32

The kits are setup to use the msvc2008 32 and 64bits compilers to ensure users don't have to install some redist (Teamspeak includes and installs the 2008 redist).

[remcoros]

I only have VS 2010 / VS 2012. But I guess it doesn't matter for me.

I won't publish my compiled version anyway, and it would just be for personal verification to ensure it compiled if I make a change / pull request.

Thanks for the info and the quick responses !! great job.

[thorwe]

:) Yep, should be fine for that purpose.

Noteworthy caveeats if you happen to end up running a self-compiled version for testing:

TS uses Qt4.8.3 atm, but should be binary compatible. Nonetheless, stuff that's not fixed until 4.8.4 will be 4.8.3-state buggy since the applications dlls are used.

TS uses the ACTUAL filename of the .dll minus the _winxx at some API callback funcs when referring to the plugin name instead of the actual plugin name. If you compile to a different name or rename the dll, a couple of things will be broken, e.g. hotkeys. I had to figure this out the hard way and still got some hulk-ish itches when I remember.

[remcoros]

positional audio module is still ignored in .gitignore, so it's not in the repo currently.

[thorwe]

I know, as hinted I'm not comfortable at this point having the plugin communication open for potential abuse ("TS Spies", while destructive already, might get the positions, too, or sabotage feeding crap data I might've missed to handle). I'm lazily looking into options to have a basic Anti-Spy system, however have no ETA and that - however when done this would lead to me opening the Positional Audio module itself, but keeping the Anti-Spy system closed.

Does this pose a particular problem for compiling or is it more of a reminder if I have forgotten about it?

[remcoros]

It was more of a reminder, as I like to read random source code of interesting projects :)

Also, don't you think hiding the source is a form of 'security by obscurity' ?

[thorwe]

Hehe, ok. Yes I think it is. I'd though claim the argument against it - having the open soure community check your security trumping the closedness is highly dependend on the developer attraction of the project in play.

I haven't done anything security related yet, so I'd have to investigate my options - which may not be worth it for this particular appliance. After all, I could add a single line to Mumble Link to break it's gameserver security for Guild Wars 2 in regards to faking the game world to gain access to positional data (when already spying on the server).

All I came up with till now for the Anti-Spy is using certain information from positionalAudio context (game world id obviously included), some bits of the ts server info and such, create a sha-1 hash (already available via QtCore) and use this as a server specific password generation which could be applied to TS Channels. However, when the way the key is generated is known, it'd just be a matter of overwriting the world id part and recompiling the plugin to generate the fitting pw. I wouldn't like it to be that vulnerable for the work involved to get it working in the first place ;) Sure, it's better than nothing, but nonetheless. If you got any suggestions, I'm all open.

[thorwe]

Positional Audio module is up. The only thing excluded now is a tinsy class where I experiment with automatic channel password key generation for AntiSpy. Obviously that one would not really be a good idea to put up ;D