Drakoz

That is kind of true, but not likely to work. I wouldn't go around replacing Joystick witih joy2. Not unless you really understand how all this works. First of all, I said &Joystick = &joy2 only for my example. Depending on which controllers you have connected, it might be &joy1 or &joy6 or something else. I will explain this a bit more below. Also, I haven't tested this or played with these kind of things for a couple years so I would have to experiment to be sure. Besides, if you are going to search and replace all instances of &Joystick with something else, you should replace it with something like &devjoy as in my example above instead of using &joy1 or &joy2, etc. My example posted earlier worked by putting all configuration statements in a subroutine called MapJoystick(), but you could just as easily hard code a statement at the top of your TARGET script (after Init() of course) saying "&devjoy = &Joystick", and replace all occurrences of &Joystick with &devjoy. Then if you switch to a AVA F16, change the hard coded statement to say "&devjoy = &AVAF16". This is the eaiest way to switch back and forth between different Joysticks with the same button combos. Don't forget, you must define &devjoy, so place the following statement in your TARGET script before the main() statement. alias devjoy FYI, am explaining all this assuming everyone here has some basic understanding of C Language programming. TARGET is basically C Language with a few adjustments, and one of those big adjustments is they use an "alias" in place of a C Language pointer. They largely work the same, but not always. Understanding these advanced techniques in TARGET significantly requires understanding aliases. If you don't understand this, don't hesitate to ask questions, spend a little time reading up on C Language pointers, or just do some experiments to figure out how things work. Regarding &joy1, &joy2, &joy6 etc. How do we tell which will be assigned? The &joy1, &joy2, etc. are asssigned in order, 1, 2, 3, 4... to 16. As each controller is detected, it is assigned the next unused number. If a controller is not connected (or disabled using the Configure() command), then it is assigned &joy0. All controllers that are not connected are assigned to &joy0 as I explained in my last email. The order of assignments is determined in the Init() routine in target.tmh. I pasted the commands from Init() below that perform this configuration. Note the order of the commands - each one is written to identify and initialize a specific controller (Throttle, Joystick, JoystickF18, etc.). If you have a Warthog Throttle, Warthog Joystick, and a TWCS Throttle connected, and nothing else, then you will get the following assignment order: &Throttle = &joy1 &Joystick = &joy2 &TWCSThrottle = &joy3 Everything else will be set to &joy0. Note the F18 stick is 3rd in order below, but the AVA F16 and AVA F18 sticks are last. So if instead, we have a Warthog Throttle, Warthog base with F18 stick, and a TWCS Throttle, the order will be: &Throttle = &joy1 &JoystickF18 = &joy2 &TWCSThrottle = &joy3 If you have an AVA F16 stick, Warthog Throttle and TWCS Throttle, the order will be: &Throttle = &joy1 &TWCSThrottle = &joy2 &AVAF16 = &joy3 Hopefully this makes it clear how the joy0, joy1, etc. are assigned. So yes, if you have the same controllers connected all the time, you know exactly which joy1, joy2, joy3 etc. will be assigned to which controller. But add a new controller and it can all change. That is why I do not suggest using joy1, joy2, joy3, etc. directly in your scripts. I copied the statements below from rdalcroft's post earlier, and I assume this is from the latest version of TARGET. I haven't upgraded to this version yet. I see the list has grown a lot since I last saw it. This makes me wonder if they have more than 16 joy__ arrays now. If so, then maybe they have joy1 through joy24 or something like that now. You can tell by looking in the hid.tmh file. The joy__[] arrays are defined in that file. &Throttle = GetIndexJoy(Select(&Throttle)); // expect a Warthog Throttle to be plugged on USB &Joystick = GetIndexJoy(Select(&Joystick)); // expect a Warthog Stick to be plugged on USB &JoystickF18 = GetIndexJoy(Select(&JoystickF18)); // expect a Warthog Stick F18 to be plugged on USB &LMFD = GetIndexJoy(Select(&LMFD)); // expect a LMFD to be plugged on USB &RMFD = GetIndexJoy(Select(&RMFD)); // expect a RMFD to be plugged on USB &HCougar = GetIndexJoy(Select(&HCougar)); // expect a Hotas Cougar to be plugged on USB &T16000 = GetIndexJoy(Select(&T16000)); // expect a T16000 to be plugged on USB &T16000L = GetIndexJoy(Select(&T16000L)); // expect a T16000 left handed to be plugged on USB &TWCSThrottle = GetIndexJoy(Select(&TWCSThrottle)); // expect a TWCSThrottle to be plugged on USB &TFRPRudder = GetIndexJoy(Select(&TFRPRudder)); // expect a TFRPRudder to be plugged on USB &TFRPHARudder = GetIndexJoy(Select(&TFRPHARudder)); // expect a TFRPHA Rudder Pendular to be plugged on USB &A320Pilot = GetIndexJoy(Select(&A320Pilot)); // expect a A320Pilot to be plugged on USB &A320Copilot = GetIndexJoy(Select(&A320Copilot)); // expect a A320Copilot to be plugged on USB &TCAQuadrant12 = GetIndexJoy(Select(&TCAQuadrant12));// expect a TCA Quadrant Eng1&2 to be plugged on USB &TCAQuadrant34 = GetIndexJoy(Select(&TCAQuadrant34));// expect a TCA Quadrant Eng3&4 to be plugged on USB &TCAQBoeing12 = GetIndexJoy(Select(&TCAQBoeing12));// expect a TCA Q Boeing Eng1&2 to be plugged on USB &TCAQBoeing34 = GetIndexJoy(Select(&TCAQBoeing34));// expect a TCA Q Boeing Eng3&4 to be plugged on USB &TCAYokeBoeing = GetIndexJoy(Select(&TCAYokeBoeing));// expect a TCA Yoke Boeing to be plugged on USB &ViperTQS = GetIndexJoy(Select(&ViperTQS)); // expect a Viper TQS to be plugged on USB &ViperBBox = GetIndexJoy(Select(&ViperBBox)); // expect a Viper BBox to be plugged on USB &TCASidestickXPilot = GetIndexJoy(Select(&TCASidestickXPilot)); // expect a TCASidestickXPilot to be plugged on USB &TCASidestickXCopilot = GetIndexJoy(Select(&TCASidestickXCopilot)); // expect a TCASidestickXCopilot to be plugged on USB &FarmStickRight = GetIndexJoy(Select(&FarmStickRight)); // expect a FarmStickRight to be plugged on USB &FarmStickLeft = GetIndexJoy(Select(&FarmStickLeft)); // expect a FarmStickLeft to be plugged on USB &AVA_F16 = GetIndexJoy(Select(&AVA_F16)); // expect an AVA base + F16 handle to be plugged on USB &AVA_F18 = GetIndexJoy(Select(&AVA_F18)); // expect an AVA base + F18 handle to be plugged on USB Here is the joy__[] array definition from hid.tmh from my version of TARGET. short joy1[296]; //1st selected USB device input vector short joy2[296]; //2nd selected USB device input vector short joy3[296]; //3rd selected USB device input vector short joy4[296]; //4th selected USB device input vector short joy5[296]; //5th selected USB device input vector short joy6[296]; //6th selected USB device input vector short joy7[296]; //7th selected USB device input vector short joy8[296]; //8th selected USB device input vector short joy9[296]; //9th selected USB device input vector short joy10[296]; //10th selected USB device input vector short joy11[296]; //11th selected USB device input vector short joy12[296]; //12th selected USB device input vector short joy13[296]; //13th selected USB device input vector short joy14[296]; //14th selected USB device input vector short joy15[296]; //15th selected USB device input vector short joy16[296]; //16th selected USB device input vector

Oh, right. Yes, if the sticks have the same buttons, axes, etc. you are correct, it would be useful and easy to figure out which stick is connected and use a custom alias to represent the connected stick like I explained on my June 16th comment above. Of course, Home Fries CTS script doesn't support this, but below is one way to do it. Maybe Home Fries is already planning to add something like this? You would use a routine such as the following to generically map all the buttons, axes, etc. for an F16 or F18 like stick. This is similar to the example I posted above in my June 16th post. MapJoystick(alias devjoy) { MapKeyIO(&devjoy, TG1, ...); MapKeyIO(&devjoy, S1, ....); // etc.... } You call MapJoystick() with a line such as the following depending on which stick is connected. MapJoystick(&Joystick); or MapJoystick(&AVAF16); This makes it so that inside MapJoystick, &devjoy is the same as &Joystick or &AVAF16. Hence the same commands can be used to configure either joystick. But how to you tell which stick is connected? When the script starts, in target.tmh, a controller's handle (e.g. &Joystick) is defined as a string of text which is the USB ID (e.g. Joystick = "VID_044F&PID_0402"). This is just a temporary thing and will be replaced in the Init() routine by a line similar to the following. &Joystick = GetIndexJoy( Select(&Joystick) ); Select(&Joystick) calls the TARGET routine that initialized the controller USB port. This is the command that prints out in the TARGET console what devices are connected or failed to be detected. Select() returns a number from 0 to 16. GetIndexJoy() takes the number and converts it into &joy0, &joy1, &joy2, ..., &joy16. Hence, the line of code above sets &Joystick = &joy0, or &joy1, or &joy2, etc. depending on whether the stick is connected or not. Bottom line is..... If the stick is NOT connected, Select() fails with -1 which causes &Joystick to be set equal to &joy0. If &Joystick is connected, it will be set equal to &joy1, &joy2, &joy3, etc. up to &joy16 depending on the order the controllers are detected. That order is determined by Init(). This works the same if you use a Configure() statement to disable &Joystick such as the following. The following statement will cause &Joystick to be set equal to &joy0. Configure(&Joystick, MODE_EXCLUDED); // Exclude Warthog Joystick Below I copied a snip of Init() that sets a controller to &joy0, &joy1, etc. &Throttle is configured first, then &Joystick, then &JoystickF18. This may be different for the latest version of TARGET, but the concept is the same. int Init(alias h, int cfg=CREATE_JOYSTICK+CREATE_KEYBOARD+CREATE_MOUSE) { &Throttle = GetIndexJoy(Select(&Throttle)); // expect a Warthog Throttle to be plugged on USB &Joystick = GetIndexJoy(Select(&Joystick)); // expect a Warthog Stick to be plugged on USB| &JoystickF18 = GetIndexJoy(Select(&JoystickF18)); // expect a Warthog Stick F18 to be plugged on USB ... } In the example above, if a Warthog Throttle (&Throttle) and Warthog Joystick (&Joystick) are connected, but NOT an F18 stick (&JoystickF18), then these three controllers will be configured as follows: &Throttle = &joy1 &Joystick = &joy2 &JoystickF18 = &joy0 Now, anywhere you want to use &Joystick, you can say &joy2. They ware interchangeable. Any other devices that are NOT connected will be set to &joy0. Assuming only one stick or the other is connected, but not both at the same time, you can tell which one you need to configure. &joy0 is a dummy variable used for non-connected controllers and is not used for anything else. Here is an example of how to check which one is connected. I included the AVA F16 and F18 in the example below. If (&Joystick != &joy0) MapJoystick(&Joystick); else if (&JoystickF18 != &joy0) MapJoystick(&JoystickF18); else if (&AVAF16 != &joy0) MapJoystick(&AVAJ6); else if (&AVAF18 != &joy0) MapJoystick(&&AVAF18); Do the same for the Throttle Quadrant if using two throttles that have similar or the same key mappings. There are several ways you might choose to use this, but the key is to check if the &Joystick or &AVAF18, etc. is equal to &joy0. If so, that device is NOT connected. What is &Joystick and &joy0 or &joy1? The & just means Joystick, joy0, joy1, etc. are an "alias" (a variable of type alias). It is similar to a pointer in C programming. An alias with & in the name (e.g. &joy1) is just a pointer (memory address) to the contents of the variable joy1. In this case, joy0, joy1, joy2, etc, are just arrays of 296 elements. These arrays contains the current status of all buttons switches, hats, etc. on the controller. If TG1 on a Warthog Joystick is pressed, Joystick[TG1] = 1. Otherwise, Joystick[TG1] = 0. Looking at defines.tmh, we see that TG1 = 0, so Joystick[TG1] is the first element in the array. All controller handles (e.g. &Joystick, &Throttle, &AVAF16, &AVAF18, etc.) are set equal to &joy1, &joy2, &joy3, etc., so Joystick[TG1] is the same as joy1[TG1] if a Warthog Joystick is the only controller connected. Sometimes the code in target.tmh uses joy0, joy1, joy2 instead of Joystick, AVAF16, etc. That's all it is. Knowing this is useful for other purposes, but not important for this discussion. We only care if a controller is set to equal joy0 instead of joy1, joy2, etc.

Yes, there are several ways to know what controllers are attached and act on that information. It isn't difficult determine this after Init() has run as you suggest. But since each controller has different buttons, switches, and axes, you still have to configure each controller with a custom script. E.g. TG1 on one stick may not exist on another stick of be called something else. Normally people who use TARGET just have a different script for each controller or aircraft/controller combo. Normally it isn't worth the effort to create a single script that detects the controller and then runs the portion of the script for that particular controller. This is what I do for DCS. One script per controller/aircraft. For Train Sim World, I created a single huge script to allow changing configurations for different locomotives, but each script used the same controllers. I created different scripts for different sets of controllers. The permutations just gets to be too much for a single script to support all those options. It was complicated enough just allowing the ability to swap locomotives on the fly without reloading the script. Also, most people keep all their controllers plugged in all the time and maybe switch between different devices depending on the aircraft or purpose (e.g. one controller for DCS, but another one for a different game maybe, or fixed wing vs. helicopter). Now if your goal is to create a script that you pass out to other people with different controllers and have it just work for everyone generically, then yes, the stuff we discussed above about changing the script to detect and configure each controller applies. It is a lot of coding, and error prone due to complexity, but it can be done. I would still probably create separate scripts for each controller, but I would use several include (.tmh) files with the common code to reduce how much coding I need. Home Fries, has been creating such script to rule them all for many years. Bravo for his investment in time and effort to do this. It is a huge effort.

I am curious, what are the issues you have had with the stack? Do you mean you are running out of program stack (getting stack overflow crashes on TARGET), or do you mean you have issues with the keyalloc[] array which is used to store all key and function (e.g. EXEC) assignments? I know you have been developing your CTS script for over a decade now and it is a complex system that allows changing profiles (configurations) on the fly, so if anyone has reached a stack limit, I can imagine your script could. I have done a profile swapping system completely within TARGET, but not as complex as what you did (no external software to configure it, etc.). In my script, similar to yours, I can swap between dozens of configurations or profiles on the fly using several different Thrustmaster controllers. I use sub-functions that reconfigure everything for each profile swap. I only use main() to configure things that are common between all profiles like the button used to change profiles. If I understand correctly, you were trying to avoid having sub-functions to reconfigure for each profile, so my method is not directly useful to you. But I mention it only to say I have never seen a stack over flow, or run out of space in keyalloc[] using this method, even when I have had the script running for hours doing hundreds of profile changes without reloading the script. Anyway, just curious to know more about the stack issue and maybe I can better understand suggestions to help you. My script was made for Train Sim World, but I comment about it on the DCS forums at the link below. As the title says, the main purpose of this script is to create a better AXMAP() function in order to map controller's axes to do key presses better than what AXMAP1 and AXMAP2 can do. This is not very useful for DCS. I only point it out because of my implementation of a profile swapping system.

I believe the issue is that CJy0, etc, are not being initialized by Init(), which is part of the Init EventHandle line: if(Init(&EventHandle)) return 1; &joy1, &joy2, &Joystick, &Throttle, etc. are special and initialized by Init() once the first time main() is executed. These pre-initialized aliases point to data structures which must be initialized correctly the first time main() runs, or they won't work. Study Init() in great detail if you haven't already, noticing how the "alias Throttle = "VID_044F&PID_0404"" and similar aliases are initialize and turned into the device structures called joy1, joy2, joy3, etc. After Init() runs, &Throttle, for example, points to &joy1 if a Warthog Throttle is the only connected device. I believe either you must make CJy0, CJy1, etc. an alias for &joy1, &joy2 or &Throttle, &Joystick, etc. since now &CJy0, etc. will point to the correctly initialized &Joystick, &Throttle, etc. Or you must create your own version of Init() to initialize CJy0, etc. in a similar way how Throttle, Joystick, etc, are initialized. This is a complicated initialization and it is highly likely trying to do anything to create your own version of these special names will fail or require a lot of re-writing of target.tmh. Since I always try to avoid creating a custom version of the Thrustmaster files (target.tmh, sys.tmh, etc.), I suggest you re-alias your own names to point to &Joystick, &HCougar, etc. Or just write your routine to use the already initialized names... To do what I think you are trying to do, I would use an if/then/else (e.g. your if (secondary), else) to call a single MapAxisInit() routine that contains the series of MapAxis() commands. Something like the following: if (secondary) MapAxisInit(&HCougar) else MapAxisInit(&Joystick); Where MapAxisInit() is as follows. MapAxisInit(alias devjoy, alias devthr) { MapAxis (&devjoy, JOYX, DX_X_AXIS, AXIS_NORMAL, MAP_ABSOLUTE); MapAxis (&devjoy, JOYY, DX_Y_AXIS, AXIS_NORMAL, MAP_ABSOLUTE); MapAxis (&devthr, THR_LEFT, DX_THROTTLE_AXIS, AXIS_NORMAL, MAP_ABSOLUTE); MapAxis (&devthr, THR_RIGHT, DX_Z_AXIS, AXIS_NORMAL, MAP_ABSOLUTE); } My syntax might be wrong, but I hope you get the idea. My point is, MapAxis() works with &Joystick and &HCougar because these have already been initialized in Init(). To make your code work, you either need to actually pass in &Joystick or &HCougar, or you need to pass in your own variable which points to the same location as &Joystick, etc. I don't think you can just initialize your own &CJy1 and expect it to work. I believe your goal is to use aliases instead of individual routines to map each type of controller. I think what you mean by that is you don't want to MapAxis &Joystick and &HCougar since only one or the other is connected, not both, right? If so, the above method does that, but I probably don't understand the greater issue you are trying to achieve (saving stack space). I haven't looked at your CTS script. Is that a "one script to rule them all" kind of script? Again, spend some time studying how target.tmh handles &Joystick, &HCougar, &Throttle etc. and &joy0 (which is a dummy alias) vs. &joy1, &joy2, etc. on initialization in Init() and study how these data structures work. I am being loose on some of the details, because I believe you are already an expert on TARGET and things in target.tmh, right? If not, I can explain these things in more detail, or I can offer my notes and a more documented version of target.tmh that I always refer to to remember how all this works.

It has been a while since I looked this deep into target.tmh and the Map() function, so I am mostly guessing, but.... The issue might be the index for [T[3]-'0']. If subtracting '0' from the value at T[3] is going negative, that would cause an error. Or more likely, the value T[3], regardless of -'0' is too high. The reason for this is probably because these routines are meant to work with names like Joy0, Joy1, not CJoy0, CJoy1. T[3] is supposed to be 0, 1 for Joy0, Joy1, but for CJoy0, CJoy1, T[3] is y. 'y'-'0' is too high of an index number for devicedata[]. I assume you understand, but just in case... The purpose of the -'0' is to take the character '0' or '1' and subtract the character '0' which converts the ASCII character '0' or '1' to a number, 0 or 1 in order to index the array devicedata. '0' is 48 on the ASCII table, '1' is 49. Hence, '1'-'0' = 1 decimal. But 'y' is 121. 'y'-'0'=73. This exceeds the bounds for devicedata[]. Here is the definition of devicedata[] from target.tmh. It is only a 16 element array. So devicedata[73] would cause "index out of bounds". sDevice devicedata[16], devdata; For GetDeviceData() to work, you must use names like abc1, xyz2, Joy0. The number must always be the 4th character in the name.

Yes, it is possible for TARGET and DCS BIOS to talk to each other, but it requires custom programming in TARGET, and maybe using a helper app outside of TARGET to parse the data from DCS BIOS for TARGET. You might be able to do this using data files, or maybe using sockets. But it requires some knowledge about programming. If I remember correctly, DCS BIOS exports data to a file and you parse the file with a custom program to read data from DCS or write data to DCS. TARGET is a C language interpreter and can do most of what C can do including read files on your harddisk, or even send/receive network packets on a network using sockets. The problem is, TARGET lacks any kind of proper string handling functions. TARGET handles numbers fine, but strings (arrays of char) do not work properly in TARGET compared to C mostly because TARGET does not understand the \0 end of string nul (and does not have a full set of string handler functions). If DCS BIOS exports data to a file in a complex way (using words, strings, or more than just numbers), it is more complicated for TARGET to parses the file, but still possible. But it may be better to write an external program to take the DCS BIOS data and convert it (in real time) to a second file for TARGET to use in the form of straight numbers (integers). Another way to communicate with TARGET is to open a socket in TARGET. A socket is a network interface between one program and another, but sockets can be used between programs on the same computer. TARGET supports sockets, but it is not documented. There are a few examples how to do it on this forum or on elsewhere, but will take some searching. Only 3 or 4 people I am aware of have actually used sockets in TARGET in a working example. I have considered it, but never actually tried. DCS BIOS is perfect for using a socket. Meaning, if DCS BIOS doesn't already support sockets, someone has probably created a socket interface for DCS BIOS for a DIY controller. If so, maybe you could use that as a starting point to create a socket interface between DCS BIOS and TARGET. It would be more efficient for an external helper app to parse the DCS BIOS information and send TARGET only the data you want. I have seen some other examples of DCS BIOS wrappers or helper apps that send status information to a joystick in order to turn LEDs on and off. Somewhere on the DCS fourms, I believe there is one created for the Logitech G940 throttle button LEDs. Anyway, for someone that is savvy with programming, it is possible to use DCS BIOS to talk to TARGET and vice versa.

I just posted a comment on the above thread about dropping the USB voltage to make a non-working Warthog work. It is very uncommon that dropping the voltage to a power supply would make something work, but I have questions and suggestions in the other thread as to what might be happening. Not solutions, though, as the issue is definitely something wrong with the Warthog.

When the Warthog fails like this, does it show no sign of life when plugged in? Or does it fail a few seconds or a minute after being plugged in? Signs of life could include LEDs lighting up, Windows making the USB boo-beep sound when a USB device is plugged in, etc.? If I were to guess, something is shorting out, but not a hard short. It is probably something drawing more current than it should and the main power supply on the board is shutting off as part of an over current or thermal over run shut down. By lowering the voltage to the USB connector, it may reduce the current or heat enough so the power supply does not shut down anymore. So the problem could be something drawing excessive current, or the power supply itself is having issues at 5.0V, but not at 4.5V or so. If it is an over current, it could be just about anything. For this to happen at 5.0V and not at 4.5V, the power supply has to be right on the edge of thermal or over current shut down. So even a 10mA difference could push it over the edge. It would be interesting to see measurements on the USB connector for voltage and current using one of those USB voltage/watt meters that plugs inline. Comparing the current draw from a working Warthog to a non-working Warthog may be very informative. I'll try mine out and see what the current draw is. I have two of them, and both work normally. Watching the voltage/current throughout the process of plugging it into a hub over time would be very informative as the Warthog tries to startup and negotiate with the hub. Or maybe it doesn't do anything and just fails, in which case the voltage/current should be stable throughout. If the power supply is shutting down due to overcurrent or thermal shut down, the current would drop to nearly 0 mA. That is the detail I am looking for.

I leave the tape on mine always, so yes, it is OK to power it up with the tape in place. The G940 uses hall effect sensors and self calibrates. Or at least I have never had to calibrate it.

It is likely one of the parameters you passed into MapKeyIOUMD() is the issue, not the target.tmh file. What does your code look like?

The G940 notchy gear feel is OK, but not the best. I tend to set the force just strong enough to hold the stick for trim on an aircraft but not so much that it feels really notchy. What is important is how well the stick holds itself without any play. Unfortunately the G940 is pretty bad on that. fred41's firmware helps, and the mods I did to mine to tighten it up also helped a lot, but still has a little too much play to just let it go hands free sometime. The Microsoft Sidewinder Forcefeedback 2 has the best feel of any FFB stick I have used (at least for a consumer grade stick - there are a couple really expensive ones out there I haven't tried). Sadly, the FFB2 doesn't have enough buttons, and worse, it has as dead zone at stick center (not force center, but stick center) that makes it much less desirable for helicopters. It is not so bad for fixed wing, but still annoying. Force center is where the stick is being held, which might not be stick center. If the deadzone moved with the force center, it wouldn't be so bad, but if you trim the stick off center (which is going to happen all the time), you may move through the stick center and have a momentary pause as you move through the dead zone. There is no way to completely disable this deadzone, even using the MS FFB2 software. When powered off, it is OK to let it just flop over. There are no springs in the stick. It is entirely controlled by motors and gears, so it doesn't care what position it is in. What is important is, if you bypass the hand sensor (like putting a piece of tape across the sensor holes), so that the stick force is working even if you let go of the stick, make sure you don't leave it unattended whole powered on. A little noise in the feedback loop, or say, if a cat a person knocked it, can cause it to go into undamped oscillation and beat itself to pieces. They include the hand sensor to prevent it from moving when someone isn't using the stick but it defeats much of the purpose of trimming - so you can let go of the stick for a moment. Most sticks have a optical sensor that your hand covers up. Just put a piece of tape over the sensor holes, and it keeps the stick active even if you let go. Also, you can pull the power plug and still use it on USB as a springless stick. I never do that, but just saying it won't hurt anything. The USB circuit is powered by the USB cable. The power plug only powers the FFB circuit and motors. Yes, after using FFB, I can't go back to a normal stick. I thought I heard the patents have finally expired for the FFB haptic feedback stuff (the software portion of the FFB standard). If so, I hope that means we will finally see some serious flight sim FFB sticks being made. I have threatened to make my own for years as a DIY, but just don't have time.

Never heard of disabling core isolation. I'll check that on my system. If this is a Windows 11 vs. 10 issue, this might be important to know. I have several joysticks, but for helicopters I hate flying without FFB. Very glad to hear you got it working.

Are you running the Logitech Gaming Software v5.10.127? What OS? If you are using Windows 11, or maybe even the latest version of Win 10, there might not be very many people that have tried it with that setup. I'm on Windows 10 21H1 (the early 2021 update) and it works there. There is a 21H2 (most current Windows 10) which I am about to upgrade to so I can verify that. But chances are, if it isn't working, it is something with your install. Disconnect the G940 and try uninstalling the LGS software and re-installing. Follow closely any instructions about connecting the joystick. Many such installers require the joystick to be disconnected before installing or uninstalling the software. The v5.10.127 LGS software should install the driver. If you still can't get it working, you might want to make sure you don't have any newer versions of Logitech Gaming Software (either LGS or their replacement for LGS). I am reaching here. It shouldn't matter. I run a newer version of LGS along side the G940 LGS version and never had issues, but just a thought to try.

And I just noticed you found much of the above info already and tried the firmware (based on your post to fred41's topic). I will reply there.

A) The G940 is an old product and not supported by any recent (as in the last few years) Logitech software. You need to download the software that is specific to the G940. It should be available on the G940 support page. B) Go to the Logitech Support site, Downloads, and search for the G940. Below I pasted a link to the page. Select Windows 10 and you will see Logitech Gaming Software V5.10.127. This is an old version of the Logitech Gaming Software, and is the last version that supports the G940. I haven't tried it on Windows 11, but it works fine on Windows 10. https://support.logi.com/hc/en-us/articles/360024852233--Downloads-Flight-System-G940 C) The Logitech Gaming Software v5.10.127 can confirm the firmware on your device and also update your device to firmware v1.41. The latest from Logitech is firmware v1.42 which tries to fix the reversal bug (see comments below). This firmware is not available from Logitech directly because it was only released on Logitech's older support forum (now deleted). What you really want, though is fred41's hacked firmware which fixes the reversal bug on all axes properly. I have provided links to all this at the bottom of this message. In summary, though, fred41's firmware makes the G940 work noticeably more smoothly vs. v1.41 or even v1.42, and fixes the reversal bug on all axes, not just the X/Y joystick axis. D) Yes, the notchy feel is typical of the G940. The firmware update fixes this a little by allowing the force feedback to work more smoothly (not be so jumpy), but the gearing and design of the G940 still has a notchy feel. The notchy feel can be improved. Somewhere I thought I wrote a bunch of notes on how to do that, but I can't find that right now. I also started a Youtube video on the subject, but never posted it. I suppose I should just post it. There is some discussion about this in fred41's forum topic. Re: your comment that the old version of LGS didn't work either. Make sure you have downloaded LGS v5.10.127. It should install drivers and everything for the G940. Here are links to the things I mentioned above: My explanation of the G940 Reversal Bug and the v1.42 firmware fix: (my first post talks about fred41's firmware fix with links, but I have copied links below as well) https://forum.dcs.world/topic/189949-logitech-g940-reversal-bug-v142-firmware-update/ Archive.org backup of Logitech's support forums about the v1.42 firmware (and download link): https://web.archive.org/web/20120119090658/http:/forums.logitech.com/t5/PC-Gaming/G940-firmware-1-42-is-now-available/td-p/542496 fred41's forum topic about the G940 - a good read if you want to understand how to get the best use of your G940 - includes his discussion of his firmware hack: https://forum.dcs.world/topic/205420-g940-force-feedback-discussion fred41's firmware download (at github): https://github.com/fred41/G940-firmware-fixes

The burned part appears to be a ferrite bead (labeled FB9 and FB usually indicates a ferrite bead). Ferrite beads should appear as a 0 ohm short as they are intended to pass DC voltage, but act as a resistor for high frequency noise. If you have a multi-meter, measure the resistance across the bead. It should show about 0.2 ohms (where the 0.2 ohms is actually the resistance of your multimeter). If it shows a much higher higher result (like 1-2 ohms to hundreds of ohms or an open circuit), the bead has been damaged. Problem is, the burned ferrite bead is the symptom, not the problem. It just passes current, but there is a short somewhere else, and the FB burned because of excessive current due to a short. Inspect all the wiring that goes to/from that board. Maybe a wire got pinched and frayed, and it is shorting on something, or maybe the component the wiring goes to have a short. Check the resistance of both sides of the FB vs. ground on the board (just the board alone, not powered up). You can use the two electrolytic caps to tell what is ground (the two large black cylindrical parts that say 16V and Samcon). The pin soldered to the large white area is ground. The pin soldered to the non-white area is power (+5V or +3.3V). Anyway, If either side of the ferrite shows 0 ohms to ground, that helps prove there is a short on the board. Then connect the board back to the Warthog and repeat the test. If you didn't get a short before, but now you do, it means the short if off the board. I am guessing, but I believe the blown ferrite is for the power supply ferrite (it passes 5V or 3.3V). I assume this because it looks like it connects to a red wire which is often the color used for power. If I am correct, then one or both sides of the ferrite bead should show a short to the non-white side of the cap on the upper side of the board (the one marked 16V in your picture). If so, that is probably normal. There is also a black wire near the red wire. That is probably ground. If my assumption is correct, the black wire should show a short to the white connection for the electrolytic caps. Anyway, there isn't much on this board that would likely fail in a short. It is much more likely something off the board has shorted (what ever is connected to the 2 white connetors on the right side of the board). But it could also be that one of the wires soldered to the left side of the board is shorted. One other thing to check is, do the electrolytic capacitors show any sign of leaking, or bulging. If they are bulging, you can tell because the top of the cap will look like it is pushing out or expanding. These caps are only about 10 years old, so should be fine, but crappy capacitors can start leaking in 10 years. If they are bulging, they may act as a short circuit for too long (as they charge up) and cause over current on the ferrite as well. Probably not, but it is an easy thing to inspect since bulging is a visual clue. Do some investigation like I suggest and let us know what you find. As for repairing it, it might be best to get a new board from Thrustmaster if you can. But be aware, if you put a new board in, and the short circuit is somewhere else in the Warthog, it will blow the FB on the new board as well. So you need to make sure there is no short elsewhere in the Warthog. If Thrustmaster declines to help with this, it is because a problem like this is not so simple as replacing a single board. So they will likely strongly suggest sending the Warthog back to them. If it is a short circuit on a wire off the board, then if you can find and fix the short, you may get lucky and can just replace the FB and the board may be fine again. If desparate, you can just replace the FB with a piece of wire. The FB is to prevent bad radio emissions. It looks like a 100ohm or 1000ohm resistor to 100MHz frequencies, but looks like a short circuit for low frequencies. So replacing it with a wire does not affect normal operation. But again, you need to find the cause of the short or you will just burn something else up. It is also possible that what ever provides power or a signal to this board (though the FB), was damaged. Again, the FB is just a symptom, but not the problem, and other parts may have been damaged on other boards. You can find those parts by tracing the wires that connect to the FB (like the red wire probably). I hope this helps. Comment back with what you discover and I'll try to help more. But again, I strongly suggest, if you can, to get it repaired by Thrustmaster. Or if there is someone you can send to that does circuit repair. They don't need to understand joysticks to know how to repair this. A Joystick like this is a pretty simple concept for someone that understands electronics. Finally, even for an experienced repair person, they may not be able to find, or repair it without getting a new circuit board from Thrustmaster. Hence why I suggest your best option is to get it repair buy Thrustmaster.

Yes, if they did it, the "TWCS Dual throttle" would be more expensive of course. A TWCS can be bought for about $130, similar to the TCA Airbus and TCA Boeing throttles which have fewer and less complex buttons. I wouldn't be surprised if a Dual TWCS throttle had a price in the range of $150-$180 or maybe more. It is a little too far out of the cheap territory at that price.

There is merit to saying that the TWCS (T.16000M) throttle is the best throttle in its price range, and that would absolutely be true if it was a dual throttle. I often recommend the TWCS throttle to people because of features for the price, but I stop short on that recommendation because it is only a single throttle. So it doesn't work for many applications. The other major issue with it is the stiction, but for the price, for those who can't afford a $300-$400 throttle, the TWCS is a good alternative. I would love it is Thrustmaster made a dual throttle version of the TWCS, but I don't expect it to happen. I also love the TCA Airbus and TCA Boeing Throttles. They have hall effect sensors, good feel to their movement (stiction free, with adjustable friction), better build quality than the TWCS, but they lack the buttons to make them useful for a HOTAS application like what you would use a Warthog Throttle or TWCS. So they too are hard to recommend for serious HOTAS applications. FYI, another good inexpensive option for a decent throttle with lots of buttons (and horizontal movement, not pendulating movement) is the CH Pro Throttle. But again, it is only one throttle, not dual throttle.

Here is a complete script with a couple extra commands to test with. This worked fine for me. I am testing this with the Thrustmaster TARGET Event Tester to see the keyboard commands (it shows press and release times - much better for testing), and for checking for the DX button presses, I used the Windows "Game Controllers" control panel (press the Windows key, type "Game Controllers" and it will list "Set up USB game controllers". Run that tool. Run your script. The controller "Thrustmaster Combined" should show up in the Game Controllers List. Double click on it, and you'll see all the DX buttons. Of course, you can use the TARGET Device Analyzer as well for this. Sometimes Device Analyzer has problems in Windows 10, though, but it worked fine for this script on my system today. Note, any button that is not defined in a TARGET script will send its default DirectX button. But when defined in a MapKey command it will no longer send the default DirectX DX button. Hence why we must define DX13 in the example below. Just FYI if you didn't know. So in the example below, H3R should send DX12 as that is its normal default - I didn't define H3R. But H3U, H3D, and H3L will only send DX13 when commanded. And in the example below, that will only occur with H3D and H3L. If this isn't working in game, try it using the Event Tester, Game Controller control panel, or the TARGET Device Analyzer. It should work. I have often seen people have trouble getting something to work in DCS, but worked fine in external test programs. Then only to discover DCS wasn't configured properly. So simplify your testing. If it doesn't work in DCS right away, use the external test programs. And for sure, you must use CHAIN() to map two commands to a single button. So yes, the following will never work: MapKey(&Joystick, H3D, PULSE+R_SHIFT+'h', DX13); Here is my complete and tested script. include "target.tmh" //program startup int main() { if(Init(&EventHandle)) return 1; // declare the event handler, return on error MapKey(&Joystick, H3D, CHAIN(DX13, PULSE+R_SHIFT+'h')); MapKey(&Joystick, H3U, CHAIN('a', PULSE+R_SHIFT+'h')); MapKey(&Joystick, H3L, DX13); } //event handler int EventHandle(int type, alias o, int x) { DefaultMapping(&o, x); }

You need to use the CHAIN() command like the following: MapKey(&Joystick, H3D, CHAIN(DX13, PULSE+R_SHIFT+'h')); This will press DX13, as well as Pulse R_SHIFT+'h' pretty much simultaneously. DX13 will be held down as long as H3D is held but R_SHIFT+'h' will be momentary. Read up on CHAIN() and using D() in CHAIN() if you want to control delays between when the keys are pressed. You can use D(100), for example between any items in the CHAIN() to cause a 100ms delay.

Correct, Thrustmaster does not discuss anything about how to do this. People figured it out by seeing the TCP socket commands in the hid.tmh file (specifically the InitSocketServer() command). I believe you also need to use LoadLibrary() as shown in the sys.tmh file to load the Windows .DLL library that enables TCP sockets. People that understand TCP sockets on Windows were able to figure it out. I haven't done it myself, but there are a few discussions floating around about how to do it. It is definitely advanced stuff. I mean, with as much as I know about C programming and TARGET, it would still take a lot of trial and error for me to figure it out. Plus you must write an external program to talk to the TARGET TCP socket, which requires knowing how to do Windows programming (using tools like Visual Studio and C#, C++, or Visual Basic) and the Windows TCP Socket layer. I think I have seen a couple examples where people have written simple generic TCP socket programs to send and received data to TARGET (or other programs using TCP Sockets). These simple tools can be used with minimal effort to create a debugging tool to test communication with TCP sockets on TARGET. This is all about using TCP sockets as a method of interprocess communication. That is to say, one of the easiest ways for two programs to talk to each other is using TCP sockets. And since TCP sockets is a networking protocol (as in over Ethernet or WiFi), you can even do it from one computer to another. To talk to a program on the same computer, you access the localhost IP address (127.0.0.1:xxxx) where xxxx is the socket number. To talk to a program on another computer, you use the IP address of that other computer. It could even be an Android, iPhone, Raspberry PI, or even an Arduino as all computers that support networking protocols support TCP sockets. As I said, this very quickly goes way beyond simple C programming, but there are examples out there, not just on TARGET related forums, but many other forums about DIY stuff using TCP sockets. Once you understand TCP sockets on Windows, how to do it in TARGET makes a lot more sense because you realize that TARGET provides the basic commands to needed to load the proper .DLL, and create a server. P.S. I believe there is at least one discussion of using TCP sockets here on the DCS forums, and also I believe one or more examples on the SimHQ.com forums.

The simple C (not C#) application you need is the TARGET Script Editor. It is a C like language, and Thrustmaster included some very powerful functions like importing/exporting data using TCP sockets. All Thrustmaster device axes can be read and reported using simple commands like "position = &Joystick[JOYX]". You can print this info to the TARGET console, write it to a file, or send it to another application using TCP sockets, among other things. This is for reading Thrustmaster device axis data, but you can similarly see and manipulate DirectX axis data since TARGET takes the device axis data and writes it to variables that drive the DirectX axis. The same can be said for all buttons.

Glad to hear it.

Ah, force sensing Cougar. Got it. Nice. When you swapped to the Cougar stick, did you swap &Joystick with &HCougar in your script? And did you remove the Configure(&HCougar,MODE_EXCLUDED); line? Do those two things and it should work, or mostly work (I didn't study your entire script). Perhaps post the version of the script modified to work with your Cougar. Also, I assume you loaded the drivers for your Cougar, right? Just checking all the bases.