Post by 3noix on Feb 18, 2018 15:10:41 GMT
I went here to share with you a project I have been working on the last weeks. It is something like the "Target Script Editor" of Thrustmaster but with no limitation on the joystick brand (TM only supports their joysticks)... but let's go a bit backward so that you understand my motivations. I own the Thrustmaster Warthog joystick and throttle and the MFG crosswind rudder pedals. Since I have them, I did not played to many different games with them, only a little to DCS and a bit more to Star Citizen. I am quite comfortable with C++ (especially with Qt) and I still try to maximize the ergonomics of my setup (binding included) and the immersion. So as a Thrustmaster joystick owner I quickly tried Tartget HMI and then give it up for the "Thrustmaster C scripts". For pure aircraft simulations I felt no limitation not to be able to use my MFG rudder pedals inside my TM scripts, but in Star Citizen we can use an important variety of different vehicules and it begins to feel as a limitation for me since the release of Star Citizen 3.0 end of last december. For example, for "car-like ground vehicules", I wanted to try to bind the brake on the left pedal of my MFG and the accelerator on the right pedal (but function of the position of the TM throttle thrust levers, I wanted to go forward or backward... the throttle would be like an automatic gear box.
I first tried to integrate my MFG rudder pedals into Target scripts, but I quickly saw that non-TM controllers are voluntarily not supported, they are filtered by the TM function "SelectUsbDevice" whose code is not visible, it is compiled in a TM dll. And I saw no easy work-around.
simhq.com/forum/ubbthreads.php/topics/3126128/1
That is why I first had a look at the possible already-existing alternatives. I found UCR and joystick gremlin, but both are based on HMI. And even if I did not tested them thoroughly and that it is possible to do a more powerful HMI than the TM Target HMI, I am quite convinced that I will quickly find the limits (because I often want to do things that most people don't or didn't think about)... and I am just not comfortable with an HMI for such things, I feel more in control and with a more global view with code. So I decided to code my own tool.
I quicky noticed vJoy (thanks a lot for this powerful tool!). For reading real joystick positions I found QtGameController from Matthew Wellings on GitHub: github.com/openforeveryone/QGameController. So finally my remaining work was only to code what is between the real joysticks and the virtual ones... the easy part in fact, widely inspired by the functionnalities provided by the Thrustmaster library for scripts. So I wanted to know what you think of this project. Here are the kind of questions I have for you:
- Is there anything comparable that do the same and that I didn't heard about?
- Do you think it is useful?
- Would you use it? Why?
- To give you feedback you only read this post? You had a glance at the code? You looked at the code in details?
- ...
I attached the current code (very early version). To be able to make it run, you would need to install Qt 5.7 (it should work with later Qt 5 versions, but maybe with small adjustments) and vJoy. There is no need to download QtGameController, as I use a modified version: for now I only implemented a new "hardwareId" function for Windows, but I am thinking about removing some Qt dependencies (especially the signal/slot mechanism that I don't use here) and improving the POV support. To do so, you have to first compile the static library, then the main program. The definition of the "bindings" (in a very large meaning) are done in the "Mediator.h" and "Mediator.cpp" files. In the code I attached, many functionnalities are already available. If you have a Thrustmaster script, there is little chance that you cannot do the same even with the current state of the project. Hereafter I listed the main points that I'd need to work on:
- Implement a "plugin architecture" for the "mediator" (the object that links real joysticks to virtual ones). The window of the main program would ask you the plugin to run (as TM where you choose the script to run)
- Write a documentation!
- Add a few other functionnalities (the TM "REXEC", the gremlin "split axis", ...)
- Remove the "VirtualJoysticksManager" class and transfer the implementation of its functionnalities on the "VirtualJoystick" class
Before ending, I'd like give a few more details about what it is, what it is not and what I will not do:
- It is comparable to the Thrustmaster script editor, not the Thrustmaster Target HMI
- I don't consider to develop an HMI to allow non-coder users to more easily define their "bindings" as it is not the purpose of this tool and as it is already tackled by UCR and joystick gremlin
I'm impatient to have your feedback. Later, when some of the modifications I mentionned above will be done, I will put the code on my new GitHub page and communicate about it on the Star Citizen forum (at least) as I have seen that some people might be interested.
Have a nice end of week-end
