Thrustmaster TQS LED
-
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 ! -
@benco said in Thrustmaster TQS LED:
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 !Good luck with getting anything from Thrustmaster.
I have no experience of F4ShareMemory… yet. If were to (probably will) do it, I would create an app to get what you need from F4ShareMemory and write it to a file or to a TCP socket.
Target can read a file or handle TCP packet events.
-
@benco USB should be serial communication, right? So that might actually be relatively easy to reverse engineer. I’d love to help, but don’t have a TQS. Maybe try using Wireshark?
@scubapics I’ve used F4SharedMem now for two projects: the Virtual Crew Chief in VoiceAttack and to drive the panels of my simpit. Let me know if I can help with the shared memory part of the project.
-
@Ricky I’ve pretty much got it sorted. I’ll probably have it finished in a day or so with a fair wind.
-
@scubapics
Really looking forward to this! Thank you for taking on this project!
Regards,
Tomcattwo
(VoiceClone) -
@Tomcattwo wait no more. It is done.
The solution consists of Thrustmaster TARGET scripts and an executable called BMS2Target.exe.
BMS2Target.exe is a console application for 64bit Windows. I have not built a 32bit version and I would expect 99.99% of users will not be on Windows XP!
BMS2Target.exe reads the Falcon BMS shared memory and sends the relevant lamp data to the Thrustmaster TARGET software that is running the ViperTQSLEDSync.tmc script. The data is sent via TCP. Packets are only sent if the data changes and the script handles the packet through an event. Thus it is fairly efficient.
The BMS2Target.exe reads the Falcon shared memory every 100ms (0.1 seconds). Not too taxing on the system yet fast enough so that we humans won’t notice any lag.
Copy BMS2Target.exe to anywhere you like on your PC. Copy ViperTQSLEDSync.tmc wherever you keep your TARGET scripts.
If you are using a TARGET script to configure your ViperTQS, you’ll have to figure out how to merge ViperTQSLEDSync.tmc and your script yourself. Also don’t expect any support if you modify or merge ViperTQSLEDSync.tmc with your own. Ideally, you should be using the Alternative Launcher to map your ViperTQS to Falcon BMS.
You can run BMS2Target.exe before or after starting Thrustmaster Target and launching ViperTQSLEDSync.tmc script and also before or after starting BMS.
Give it a whizz. I’ve done basic testing. There is bound to be some fine-tuning to do. So let me know how you get on.
Oh, one more thing. The Threat Warning AUX lamps on the TQS have their limitations. The ACT/PWR switch has only one LED, not two as per the simulation. So I have programmed it to be off when there is no activity and on when there is. The ALTITUDE switch has two LEDs but they both illuminate the whole switch! One is red and one is green. So I have programmed it to be red when LOW is activated and green when LOW is not activated.
You can get the files from here:
https://forum.falcon-bms.com/topic/26193/bms-to-thrustmaster-vipertqs-led-controller
-
@scubapics
Fantastic Work! Based on this, I will disable Win 11 Core Memory Integrity and install TARGET Software and give it a spin! Thank you for the great work on this. Will let you know if I run into any issues.
Regards,
Tomcattwo
(VoiceClone) -
@scubapics ,
Now for the Speedbrake!F4SharedMem variable for SpeedBrake is:
CurrentFlightData.speedBrake
and it apparently reads speed brake position form 0 to 1, 0 being fully closed and 1 being 60 degrees open.
So if we can set BMS2Target to read speedBrake position = 0.2, 0.4, 0.6, 0.8 and 1.0, we can get the LEDs for speedbrakes programmed in the script to respond. Would need to code it to toggle light on if off and off if on when the changes occur.Also, is it possible to have BMS2Target work for any Block of F-16? Don’t know if that is a hard to do or easy to do…
Regards,
TC2