Thrustmaster TQS LED
-
@Tomcattwo no Win11 here, never will be in the foreseeable future. My Xeon CPU based MacPro running Windows 10 does not meet MS „requirements“ to run Win11. Can‘t help you with that as long as they insist on complying with their….ermmmm……“standards“….
-
I did receive a reply to my Technical case. See this thread for details.
<TLDR>: I received info from Thrustmaster (see below) that TARGET software is incompatible with Win 11 Core Security and will not likely be updated to be compliant for Win 11 in the future. As far as I know, TARGET is the only way to program the LEDs for the Viper TQS Button Box. A $500 piece of kit cannot be made fully functional in Win 11 without disabling Win 11 Core Security, and TM does not seem inclined to fix it. Those of you contemplating purchase of a Viper TQS with Button Box and whose OS is Win 11 should consider this before purchasing. </TLDR>
Regards,
Tomcattwo
(VoiceClone) -
Hey,
I’ve mapped the TQS LED with TARGET v3.0.23.608 (and Windows 11) :
- Gear Up/Down
- TWA buttons
You can try this sample profile (light) :
Just run TAGERT GUI / Run configuration (from the desktop without BMS) : https://drive.google.com/file/d/1EFBhPFH2jVWmZKSbBqtKeFA2loBJWXh_/view?usp=sharingYou should see the gear lights and TWA buttons come alive.
Hope it will help
-
@benco
Nice, Benco. Do the gear lights react on position of the lollipop or are they just on all the time?
R/
TC2 -
@Tomcattwo lights are linked with the lollypop position. (In my case)
-
I fiddled around with the Thrustmaster Script Editor today. First things first: The script editor is able to do stuff I wasn’t able to achive in the T.A.R.G.E.T GUI
One simple task I as an example:
Enable several LEDs on 1st press of button “A” and disable all of them on 2nd press of button “A”. The TWA: POWER BTN (Alt Numpad 0) would need exactly that. This wasn’t doable in the GUI. I had success with programming it in the script editor.Quick and dirty (just to outline excactly the task enable all TWA LEDs with the 1st press of TWA POWER BTN and disable them with the 2nd press of that button (if you bought the Viper Button Box standalone, You must swap ViperTQS with ViperBBox below:
include "target.tmh" int main() { Configure(&HCougar, MODE_EXCLUDED); Configure(&JoystickF18, MODE_EXCLUDED); Configure(&Throttle, MODE_EXCLUDED); Configure(&A320Pilot, MODE_EXCLUDED); Configure(&A320Copilot, MODE_EXCLUDED); Configure(&TCAQuadrant12, MODE_EXCLUDED); Configure(&TCAQuadrant34, MODE_EXCLUDED); Configure(&TCAYokeBoeing, MODE_EXCLUDED); Configure(&TCAQBoeing12, MODE_EXCLUDED); Configure(&TCAQBoeing34, MODE_EXCLUDED); Configure(&TCASidestickXPilot, MODE_EXCLUDED); Configure(&TCASidestickXCopilot, MODE_EXCLUDED); Configure(&ViperBBox, MODE_EXCLUDED); Configure(&T16000, MODE_EXCLUDED); Configure(&T16000L, MODE_EXCLUDED); Configure(&LMFD, MODE_EXCLUDED); Configure(&RMFD, MODE_EXCLUDED); Configure(&ViperTQS, MODE_KEEPENABLED); Configure(&Joystick, MODE_EXCLUDED); Configure(&TFRPRudder, MODE_EXCLUDED); Configure(&TWCSThrottle, MODE_EXCLUDED); Configure(&TFRPHARudder, MODE_EXCLUDED); if(Init(&EventHandle)) return 1; SetKBRate(32, 50); SetKBLayout(KB_GER); SetShiftButton(0, 0, 0, 0, 0, 0); MapAxis(&Joystick, JOYX, DX_X_AXIS, AXIS_NORMAL, MAP_ABSOLUTE); SetSCurve(&Joystick, JOYX, 0, 0, 0, 0, 0); MapAxis(&Joystick, JOYY, DX_Y_AXIS, AXIS_NORMAL, MAP_ABSOLUTE); SetSCurve(&Joystick, JOYY, 0, 0, 0, 0, 0); MapKey(&ViperTQS, QB_BTN16, SEQ( CHAIN( LEDV(&ViperTQS, 18, 1), D(), LEDV(&ViperTQS, 14, 1), D(), LEDV(&ViperTQS, 15, 1), D(), LEDV(&ViperTQS, 16, 1)), CHAIN( LEDV(&ViperTQS, 18, 0), D(), LEDV(&ViperTQS, 14, 0), D(), LEDV(&ViperTQS, 15, 0), D(), LEDV(&ViperTQS, 16, 0)))); MapAxis(&ViperTQS, VQ1_AXIS, DX_XROT_AXIS, AXIS_NORMAL, MAP_ABSOLUTE); SetSCurve(&ViperTQS, VQ1_AXIS, 0, 0, 0, 0, 0); MapAxis(&ViperTQS, VQ2_AXIS, DX_YROT_AXIS, AXIS_NORMAL, MAP_ABSOLUTE); SetSCurve(&ViperTQS, VQ2_AXIS, 0, 0, 0, 0, 0); MapAxis(&ViperTQS, VQ3_AXIS, DX_X_AXIS, AXIS_NORMAL, MAP_ABSOLUTE); SetSCurve(&ViperTQS, VQ3_AXIS, 0, 0, 0, 0, 0); MapAxis(&ViperTQS, VQ4_AXIS, DX_Y_AXIS, AXIS_NORMAL, MAP_ABSOLUTE); SetSCurve(&ViperTQS, VQ4_AXIS, 0, 0, 0, 0, 0); MapAxis(&ViperTQS, VQ5_AXIS, DX_Z_AXIS, AXIS_NORMAL, MAP_ABSOLUTE); SetSCurve(&ViperTQS, VQ5_AXIS, 0, 0, 0, 0, 0); MapAxis(&ViperTQS, VB1_AXIS, DX_ZROT_AXIS, AXIS_NORMAL, MAP_ABSOLUTE); SetSCurve(&ViperTQS, VB1_AXIS, 0, 0, 0, 0, 0); } int EventHandle(int type, alias o, int x) { DefaultMapping(&o, x); }
Ignore the Throttle Axis settings etc. It’s just a demo for the four buttons. Docs for the Script Editor: https://ts.thrustmaster.com/download/accessories/pc/hotas/software/TARGET/TARGET_Script_Editor_Basics_v1.5_ENG.pdf
If you want to give it a shot: open the TM T.A.R.G.E.T. Script Editor, select menu > new > “target code *.tmc”, Copy and Paste the code snippet above and click “run”:
Yet another bonus when using the script editor environment to configure the devices: you are able to exclude their DX buttons from being merged into the virtual controller when running your scripts. I wasn’t able to do that in the GUI either. Pay attention to the MODE_KEEPENABLED above:
Configure(&ViperTQS, MODE_KEEPENABLED);
My TQS is excluded from merging but available as a programmable interface in the editor wihtout changing any of the DX mappings on the device. If you don’t use MODE_KEEPENABLED, th DX button mappings change and limits # of DX keys and you need to programm every key on your own. With MODE_KEEPENABLED it works just like target isn’t running and preserves the DX button IDs you already know.
I excluded my Warthog Flightstick completetly (and my two MFDs) on purpose with keyword MODE_EXCLUDED, because there is nothing to programm there. This results in the following thrustmaster joystick panel view
when the script is started. Will experiment with it in the next days. Ideas welcome.
-
@r00t
Is the TM Script Editor a part of T.A.R.G.E.T. software or can it be accessed separately (i.e. without having TARGET software installed)?
Thanks,
R/
TC2 -
It’s also possible for the script to read files. So that means if the state of BMS or other sims can be live exported to a file, you can then set the LEDs as per the actual state of the simulator. For example the gear indicators and AUX threat warning LEDs.
Look in sys.tmh for the function definitions such as fopen, fread, fgetc, strcmp etc.
-
@Tomcattwo it‘s part of the T.A.R.G.E.T Software installation. The script editor is a separate executable that should be available as a dedicated shortcut in your startmenu, like the control panel and the GUi.
You can’t run the GUi and the Script Editor at the same time. You can’t import scripts into the GUI. But you could use „view script“ in the GUI, copy the contents into the clipboard, close GUI, open the script editor and paste the script contents into a new file as a starting point of a possibly existing configuration.
The editor is a bit limited in terms of syntax highlighting and other functions you are used to in your „favorite editor“. But it has a completion feature which be helpful when one starts his adventure there. But as it’s „plain text“, you could edit yo stuff in sublime, vim, notepad++ or even visual studio and copy it over later on. Header files with relevant definitions are available also.
The term „script“ is a bit misleading, tho. It‘s actually more or less a limited set of C. Your code gets compiled by the „editor“ and results in a dll that seems to get loaded. Haven’t figured out if it’s possible to check for return values of processes that are run by the build-in „spawn“ (basically this executes a arbitrary executable). But it seems like you can create your own functions with conditionals, loops, operators and keywords. Refer to page 41ff.
-
@r00t said in Thrustmaster TQS LED:
My TQS is excluded from merging but available as a programmable interface in the editor wihtout changing any of the DX mappings on the device. If you don’t use MODE_KEEPENABLED, th DX button mappings change and limits # of DX keys and you need to programm every key on your own. With MODE_KEEPENABLED it works just like target isn’t running and preserves the DX button IDs you already know.
Thanks for this. This is a game changer for me as I prefer to use the game/simulation to map buttons and axis to game functions.
This will make the scripting far simpler so that I can focus on just controlling the LED from game output. Not that I really need to as I am a VR flyer only but I am a software system engineer so I like to dabble.
-
@scubapics , @r00t ,
Reading thru the TARGET Scripting language basic .pdf last night and it alludes to being able to use C to allow interface with other programs. The crown jewel would be to find a way to connect TM devices using TARGET scripting language to pull info from F4SharedMem.dll to use in lighting LEDs. Could it be as simple as a short inline C program to include F4SharedMem.DLL and pass gamestate info to Target.h (or another Target Module). I say simple, but not for me - my C programming skills are far below what would be required. This seems similar to what others have done for Arduino boards with such interface software as DEDUino or BMSAIT.What do you think? If such a module existed, I would seriously consider turning off Win 11 Core memory integrity to install TARGET software.
And I agree.it is great to be able to exclude Viper DX Button and Axis assignment from TARGET and just stick with LED programming with TARGET using BMS AL for button and axis assignment to keep it properly organized and responding in BMS.
Regards,
Tomcattwo -
@Tomcattwo said in Thrustmaster TQS LED:
@scubapics , @r00t ,
Reading thru the TARGET Scripting language basic .pdf last night and it alludes to being able to use C to allow interface with other programs. The crown jewel would be to find a way to connect TM devices using TARGET scripting language to pull info from F4SharedMem.dll to use in lighting LEDs. Could it be as simple as a short inline C program to include F4SharedMem.DLL and pass gamestate info to Target.h (or another Target Module). I say simple, but not for me - my C programming skills are far below what would be required. This seems similar to what others have done for Arduino boards with such interface software as DEDUino or BMSAIT.What do you think? If such a module existed, I would seriously consider turning off Win 11 Core memory integrity to install TARGET software.
And I agree.it is great to be able to exclude Viper DX Button and Axis assignment from TARGET and just stick with LED programming with TARGET using BMS AL for button and axis assignment to keep it properly organized and responding in BMS.
Regards,
TomcattwoWe have no control over the compiler so I don’t think there is a way to load other DLLs. The way to do it may be to write another application that can uses F4SharedMem.dll and generate text files that are updated live. Then use a target script to read the file and pull in the information to set the LEDs.
-
@Tomcattwo haven‘t seen any code that does this with target yet. The code I found digging into this did only trigger LEDs depending on button states and press / release cycles without acting on real sim data. But that doesn’t mean much. Just did a short research on GitHub.
Plenty of very talented people here. IMO there are many ways to solve this, directly reading shm, calling an external api toy with arguments and react on return codes (that’s why I mentioned „spawn“)…
My C-foo is very basic too, but it‘s an interesting challenge. That said, my first step is to get TWA react on pressing buttons like it does in the sim. Usually someone with much better programming skills pops up and takes the challenge. I‘d say, @scubapics sounds like he knows how to implement a skeleton or even a proto that has some bells and whistles
-
@scubapics said in Thrustmaster TQS LED:
@r00t said in Thrustmaster TQS LED:
MODE_KEEPENABLED it works just like target isn’t running and preserves the DX button IDs you already know.
Thanks for this. This is a game changer for me as I prefer to use the game/simulation to map buttons and axis to game functions.
This will make the scripting far simpler so that I can focus on just controlling the LED from game output. Not that I really need to as I am a VR flyer only but I am a software system engineer so I like to dabble.
Headers contained a third mode called MODE_FILTERED, no idea what it is actually doing.
-
@r00t said in Thrustmaster TQS LED:
@Tomcattwo haven‘t seen any code that does this with target yet. The code I found digging into this did only trigger LEDs depending on button states and press / release cycles without acting on real sim data. But that doesn’t mean much. Just did a short research on GitHub.
Plenty of very talented people here. IMO there are many ways to solve this, directly reading shm, calling an external api toy with arguments and react on return codes (that’s why I mentioned „spawn“)…
My C-foo is very basic too, but it‘s an interesting challenge. That said, my first step is to get TWA react on pressing buttons like it does in the sim. Usually someone with much better programming skills pops up and takes the challenge. I‘d say, @scubapics sounds like he knows how to implement a skeleton or even a proto that has some bells and whistles
Well… funny you should say that. I am looking at it… but for DCS at the moment. I expect any code I write will be transferrable to BMS with a translation layer/wrapper to convert BMS output to a format readable by my code/script.
-
@scubapics don’t know if you already stumpled this, but there is a tcp/udp socket server according to hid.tmh. Couldn’t find any additional documentation, tho. I launched a script, it binds to the socket and listens for connections.
//Creates a server on the specified port to process external data //port - the port number used by the server //useUDP - 0(default) to use TCP protocol, 1 for UDP datagrams //interface - 0(default) to install the server on the local interfaces, // a string IP address to use the corresponding interface only //NOTE: TCP needs 2Bytes at the start of each frame indicating the size of the packet ( 2 + size of data that will follow) // this information will not be passed to the callback, but it is needed to separate the frame from the stream // (the size info can be added to the data buffer or with a separate call, before sending the data) // UDP sends the whole packet in one chunk, no extra size information is needed // maximum data size is limited to 4096Bytes int InitSocketServer(int port, int useUDP=0, int interface=0){}
This frozen Elite Dangerous Warthog github project has some bits and pieces that puts extracted game data from ED into json, and push this via the socket to the device.
This ED project was forked / evolved to this one which at got rid of the tcp socket implementation in more recent versions and use 500ms polling on it’s status file and push data to the device. Didn’t follow the code on how it then proceeds with changing stuff on the device, tho. But it looks promising Just wanted to heads up in case you get stuck somewhere.
-
Thank you for this profile, any ideas on how to make the “Programmable LED display” panel lights" work?
Thank You.
-
@ViperDriver if “Programmable LED display” refers to LED4 to LED13 on the ViperTQS:
a) see https://forum.falcon-bms.com/post/383845. This post outlines how it generally works in T.A.R.G.E.T. GUI. You need to create a press or release trigger from a button and enable/disable the LED of choice. T.A.R.G.E.T. GUI is kind of limited in various aspects (e.g. merging everything into one virtual adapter which may result in the need to re-map keys).
b) The TM T.A.R.G.E.T. script editor is the alternative way of getting this done. It’s much more powerful and eleminates the problem of merging joysticks, with the drawback that it’s C-code based, not GUI based. Basic understanding of C and a bit of reading the TM docs are needed to get things done there. I posted simple example here: https://forum.falcon-bms.com/post/385207. It’s using a two "CHAIN"s of commands (on/off 4 LEDs at once) as a "SEQ"ence (1st chain is triggered on 1st press, 2nd chain is triggered on 2nd press).
I’m currently playing around with the TM script editor to mimic the TWA stuff. My current code is the most ugly code in the world and hurts the eyes of knowledgable people… besides that, it is able to
- toggle all TWA LEDs on/off with POWER button
- ALTITUDE starts with red LED on and toggles red/green on each press
- SEARCH is steady ON by default and toggles endless flash loop/steady on press, if POWER is toggled, it preserves flash/steady state
The SEARCH button sometimes ends-up in a wrong state, And sometimes interruptions by other presses seem to result in unwanted states of LEDs.
Gear LEDs and Gear Handle LED doesn’t have any dependency to each other (at least as long as there is no sim data readout). Implementation is straight forward. It’s on as long as Gear moves (error conditions aside).
Currently there is no real sim data interaction…but hamsters may be working already… some ideas where thrown around here.
But back to the LED4 to LED13: what yould you like to do with them? When should they be on or of - considering that there is no interaction between the sim and the TQS. It must be something you trigger on the device for the time being.
-
I have this mostly working with DCS.
-
I’ve asked TM for a SDK or API to create an interaction tool linked to F4ShareMemory. No answer yet.
If someone know how to sniff out “usb communication” to build a driver’s overlay, you’d make me happy !