Drakoz

Ha, Weegie , SGT, we are all the same on this. My hobby isn't so much flight sims as it is flight sim controls. So funny to see. Part of why I help answer questions about TARGET is because it gives me an excuse to go figure new stuff out that I wouldn't have done on my own. :) That whole Train Sim World script I linked above wasn't because it was worth the effort. Very few in the TSW forums seemed to care as train simmers and flight simmers don't cross pollinate. Not a lot of TARGET users playing with train simulators. No, it was just a challenge I couldn't put down. So I'm glad you found the info interesting Weegie. Your question really got me thinking about custom shifted states in TARGET and completely changed my perspective how I might handle them in the future, especially the concept of a timed shift that resets. I use the MSP button on the Warthog Throttle for my shift button. But that means I can't shift the other Mic Switch buttons (MSR, MSD, MSU, and MSL). So thanks Weggie, now I can.

Berniyh, I am confused at your response on this. You own a Brunner don't you? Does it fall forward when you let it go (assuming it has no hand sensor or you have disabled it)? Perhaps only if you have the stick spring force set really low, but even then, if it falls, it should be really minimal. I am curious to know. What if you smack it (again with the hand sensor disabled)? Does it go into oscillation. A G940 (which will oscillate itself to pieces) or MS FFB2 (which will usually damp itself out in a couple seconds), both have horribly unacceptable oscillation because there is no PID loop involved (just the P part of it). Their solution was to add hand sensors (or maybe the lawyers required it), but that is also unacceptable to have the stick go limp just because you let it go. But a Brunner or Gauss should not have these problems because they should have good motors, no backlash in the gimbal/drive system, and because they are using the kind of servo loops that I am talking about. They would have to. And if they don't, they aren't worth the price. I think I hear you saying you are concerned (rightly so) that trying to solve these issues might add some aberrant force feeling (a bad feel in the stick - a bad "force profile"). Is that the concern? If so, don't be concerned. I don't know how I can say it better without writing another book. Again, I do this kind of thing for a living. A basic PID loop can achieve what I am talking about without any weird feeling or force profile. In fact a PID loop isn't a force profile - there is no profiling involved (i.e. custom curved force profiles). Just equations that achieve a specific goal (spring force which I guess is the force profile, but this is just a linear F = P * X force, damping, and holding accuracy), but are limited in their implementation so the only thing the user feels is smooth spring force application and maybe some intentional hydraulic or friction feel (which is what simFFB does). Compare that to a G940, where we feel horrible bounces in the force as the software fights to deal with its loose gimbal and gears, and sometimes even fights us (and the gear mesh and motor pole feeling is just horrible too). But that is due to slop, horrible motors, and bad software (which free41's patches helped improve a lot). A PID loop would not fix a G940 because the bad motors and gimbal slop are too much to fix in software alone. But on a good mechanical design, the end result of a proper PID loop is improved feel, not a ruined feel. The Gauss and Brunner should have that improved design.

You must have the Logitech G940 Game Controller control panel open in the background (this is through the Windows Game Controller screen). So yes, it is demonstrating it's demo mode which is the result of running this control panel. I'm sure by now you have rebooted and it isn't happening anymore because the control panel doesn't reload on a restart.

What SGT posted works great if you need the IO Shift button to influence all your MapKeyIO() functions the intended way. But for "shifting" one button or a small group of buttons, I'll just use flags as Svend said. It is sometimes easier than using the sometimes complicated MapKeyIOUMD() functions which get messy due to formatting. More often, though, I use flags just for special shifted states. For example, I might have a single button that I want to be multi-functional so I'll have it call a function (e.g. LTB calls LTB_Handler() and LTB_Handler may do a dozen different things depending on a bunch of other flags, or other enabled switches). (this is untested and incomplete!!) int flag1, flag2; int main() { ... MapKey(&Throttle, LTB, EXEC("LTB_Handler();"); ... } int LTB_Handler() { // just using psuedo code, not real C if flag1 and flag2 { if FLAPU {ActKey this and that} else {ActKey that and this} // Remapping an existing key due to LTB, flags, and FLAPU state) MapKey(&Throttle, APENG, PULSE+MyNewMapping); } if flag1 and (not flag2) { // Mapping back to original function perhaps... MapKey(&Throttle, APENG, PULSE+MyOriginalMapping); } if (blah blah blah) {} // you get the idea } Ya, I know, duh. I'm just making the point that depending on how you want your code to look, sometimes using special functions like the above might be easier to read, or easier to edit after the fact. You could create [ANYBUTTON]_Hander() functions for every button and switch and then freely use flags and all other kinds of information to change what a button does on the fly without having to figure out multiple EXEC("....") functions inline of a MapKey() function. In fact, you could set up an entire template of using the [ANYBUTTON]_Handler() functions and all the MapKey() functions already configured to call the Handlers, and then all your programming could be done using C in the Handler functions without having to type all those MapKey() and EXEC() commands again. Yes, it defeats the purpose of all the TARGET MapKey commands, but has other powerful uses. It's TARGET! There are several ways to do everything. Using EventHandle() for all functions You could even put all this in EventHandle() using 100% pure C code and no MapKey() functions at all. For example, for a long time I used the following to activate PTT in VAC (Voice Activated Control or Voice Attack) and cause a chirp like beep to tell me it happened. MSP is my IO Shift key. The Beep function calls an external CMD prompt program (c:\bin\wbeep.exe) that just causes a system beep. I or other people have posted such a program. I have a link below to download the one I created if you care to try it. //tested and working, paste in your existing program and comment out //the Beep() lines if you don't have wbeep.exe. define VAC_PTT 'a' //****************************************************************** // Beep function - calls wbeep.exe which must be located at the path below. int Beep(int freq, int duration) // Beep(frequency, duration in ms) { char buffer;Dim(&buffer, 64); sprintf (&buffer, "spawn c:\\bin\\wbeep.exe %d %d", freq, duration); system(&buffer); } //****************************************************************** int EventHandle(int type, alias o, int x) { // MSP - Allow IO shift button to cause an action (PTT for VAC). if ((&o == &Throttle) & (x == MSP)) { if (o[MSP]) { // If Shift key pressed, Beep(8000,30); // Beep for feedback ActKey(KEYON+VAC_PTT); // Press and hold VAC PTT key } else { // When Shift key released, ActKey(VAC_PTT); // Release VAC PTT key. } } DefaultMapping(&o, x); } //****************************************************************** In older versions of TARGET, I think it wasn't allowed to apply a MapKey() to the IO Shift button - but I was probably just confused. Anyway, this code shows an example of causing an action on a given button press without having to use a MapKey(...EXEC()) pair. You could call any function from EventHandle() like this and even program the entire set of your controllers using pure C code in this way. But make sure your code is efficient because every time an event occurs, including moving an axis which means thousands of EventHandle() calls per second, EventHandle() gets called and your code must be executed. Smart ordering of your if else statements could prevent bottlenecks. But you could use entire if else structures to do complex sets of commands. Ya, duh again. My point is, you can program your entire Thrustmaster Operation using pure C code. Another way to do a 3 Second SHIFT key Regarding wanting to have the shift key be "pressed" for 3 seconds, you might also look at REXEC(), or even better, DeferCall(). DeferCall() can be used like below. This allows us to avoid complex EXEC() commands in our MapKey() commands (this is untested and incomplete!!) //****************************************************************** // Define virtual buttons for IO Shift and UMD mode for Warthog JoystickF18 define VBI 40 // Mode I virtual button define VBU 41 // Mode U virtual button define VBD 42 // Mode D virtual button int main() { ... MapKey(&Throttle, APENG, EXEC("APENG_Shifted(0);"); ... } //****************************************************************** int APENG_Shifted() { Throttle[VBI]=1; DefEventHandler(EV_HID_INPUT_DATA, &Throttle, VBI); LED(&Throttle,LED_ONOFF,LED_CURRENT+LED1); DeferCall(3000, &APENG_UnShifted, 0); // Calls APENG_UnShifted() in 3 seconds } //****************************************************************** int APENG_UnShifted(int x) { // x is just a dummy var used to make DeferCall happy Throttle[VBI]=0; DefEventHandler(EV_HID_INPUT_DATA, &Throttle, VBI); LED(&Throttle,LED_ONOFF,LED_CURRENT-LED1); } This uses the virtual buttons like the example SGT posted, but it moves the code out of the EXEC() commands into two functions. One to enable the APENG shift mode and one to disable it again. The APENG_UnShifted() function is called 3 seconds after the APENG_Shifted() function using a DeferCall() at the end of APENG_Shifted(). The command line used above is: DeferCall(3000, &APENG_UnShifted, 0); which is the same as calling APENG_UnShifted as follows: APENG_UnShifted(0); Defercall must have 3 parameters (explained below). 3000 = 3 seconds, the length of delay before it calls APENG_UnShifted(). &APENG_UnShifted - This is just how we have to list the function to be called. The & means an alias for APENG_UnShifted(). It is the same as &Throttle, except that in this case, the & refers to an alias for a function, APENG_UnShifted(). In normal C, this would be a pointer to a function using * and &, but TARGET simplifies this with what they call an alias. If you know C, you know what I mean (and how I haven't totally said it right). If you don't know C very well, don't worry about it. It just works. :) 0 - the 0 is simply because DeferCall must have a parameter to pass into the referred function. APENG_UnShifted() doesn't need a parameter, but to appease Defercall, I gave it a single parameter (int x). Otherwise we get an error with DeferCall(). In the TARGET user manual, they give an example as follows: MapKey(&Joystick, H4U, EXEC("ActKey(KEYON+PULSE+'a'); DeferCall(1000, &ActKey, KEYON+PULSE+'b'); DeferCall(2000, &ActKey, KEYON+PULSE+'c');)); In this example, they are calling ActKey() and passing the parameters KEYON+PULSE+'b' or KEYON+PULSE+'c'. This is the same as ActKey(KEYON+PULSE+'b') and ActKey(KEYON+PULSE+'c') respectively. SHIFTING buttons wihtout using the IO or UMD Shift buttons at all Or let's just forget using TARGET style IO SHIFT and UMD buttons along with MapKeyIO() or MapKeyIOUMD(), and do the following. Here, we remap a bunch of buttons just for 3 seconds due to pressing APENG, and only using MapKey() for more readable code. // Tested and working - just paste and compile //****************************************************************** include "target.tmh" // Disable Beep() output - disabled =0, enabled =1 define BeepEnabled 0 // Handle for REXEC define REXEC_HalfSecHandler 1 int main() { if(Init(&EventHandle)) return 1; // Axis, MapKey etc. funcs here ... // ... APENG_UnShifted(0); // Set default unshifted functions MapKey(&Throttle, APENG, EXEC("APENG_Shifted();")); } //****************************************************************** // Unshifted commands - default MapKey() Setup int APENG_UnShifted(int x) { // x is just a dummy variable required by DeferCall printf("APENG_Unshifted\xa"); ActKey(PULSE+KEYON+LED(&Throttle, LED_ONOFF, LED_CURRENT-LED3)); //MapKey(blah blah blah); // Let's remap them back to their normal "unshifted" functions //MapKey(blah blah blah); //MapKey(blah blah blah); //MapKey(blah blah blah); //MapKey(blah blah blah); Beep(7000,100); // low beep } //****************************************************************** // Shifted commands - remap for 3 seconds when APENG is pressed int APENG_Shifted() { printf("APENG_Shifted\xa"); ActKey(PULSE+KEYON+LED(&Throttle, LED_ONOFF, LED_CURRENT+LED3)); //MapKey(blah blah blah); // Let's remap some buttons and switches to a "shifted" state //MapKey(blah blah blah); //MapKey(blah blah blah); //MapKey(blah blah blah); //MapKey(blah blah blah); Beep(8000,100); // high beep DeferCall(3000, &APENG_UnShifted, 0); // Calls APENG_UnShifted() in 3 seconds } //****************************************************************** // Beep() // Beep function - calls wbeep.exe which must be located at the path below. int Beep(int freq, int duration) // Beep(frequency, duration in ms) { if (!BeepEnabled ) return 0; // Disable beep sounds if (!freq | !duration) return 0; // Ignore beep - 0 given as freq or duration char buffer;Dim(&buffer, 64); sprintf (&buffer, "spawn c:\\bin\\wbeep.exe %d %d", freq, duration); system(&buffer); } //****************************************************************** int EventHandle(int type, alias o, int x) { DefaultMapping(&o, x); } //****************************************************************** Again the point above is the concept of putting all shifted or flagged key outputs in a separate function that is called when the "shift" of flagging state occurs, and we just remap everything on the fly. I kind of hate using MapKeyIO() or MapKeyUMD)(), which isn't too bad, but I really hate using MapKeyIOUMD(). It just gets messy when I start adding complex functions for all 6 possible states, and even worse when I want some MapKeyIOUMD functions to be different depending on the state, but I want other buttons to be the same for all states. Moving some of this, for the more complex Mapping arrangements, into separate functions like above can simplify viewing and editing the code later. The above uses my Beep() function, but it is disabled in the script by setting "define BeepEnabled 0". But you may want to try the beep because it is good feedback to know if the 3 second period has ended. If you want to try the beep, you'll need the wbeep.exe program (placed in c:\bin\wbee.exe in my example below). You can download it as part of this package http://akhara.com/drop/TrainSimWorld/TSW_TARGET_Script_Drakoz_v2_1.zip which is a script I wrote for Train Sim World. Sorry I don't have a download link for just the wbeep.exe program by itself. The above includes source code for wbeep.exe as well. Look in the "wbeep" folder in the .ZIP. It just calls the Windows system function beep() - literally that is it. In Summary The key to all this is to recognize that the functions in main() get called once to setup all the Axis and MapKey... functions. Then those functions are never called again period. From then on, EventHandle() deals with all button and axis events by using a lookup table. That table was defined by the MapKey commands or Axis commands. EventHandle() is our hook to do anything we want because it gets called anytime an event occurs. But note, there is no freely running code here. None of the examples above will work unless an event happens to call EventHandle(). That's fine, because through MapKey(EXEC("Handler();")); calls, we can make our own new functions to do anything we want. Or we can do it through EventHandle() directly. Making your own Event Handler - called at a regular interval without waiting for an event What if you wanted to create your own Handler that was called every half second regardless of a button press. This doesn't have much to do with the above, but just contemplating other nonstandard ways to make actions occur in TARGET. Say you wanted to check and set some LEDs based on changing events in DCS using DCS exports LUA scripting such as the led_update() function at this thread (https://forums.eagle.ru/showthread.php?t=174929). Then you would use REXEC(). It might look like the following. I didn't call the led_update() function, but instead, I show some example code that changes LED1 and LED2 every half second. I suggest putting such an REXEC at the end of main(), but main seems to execute very quickly, so it doesn't really matter where your REXEC is. // Tested and working - just paste and compile //****************************************************************** include "target.tmh" define REXEC_HalfSecHandler 1 // Handle for REXEC int main() { if(Init(&EventHandle)) return 1; // Axis, MapKey etc. funcs here ... // ... // Make sure LEDs are off ActKey(PULSE+KEYON+LED(&Throttle, LED_ONOFF, LED_CURRENT-LED1)); // set LED 1 OFF ActKey(PULSE+KEYON+LED(&Throttle, LED_ONOFF, LED_CURRENT-LED2)); // set LED 2 OFF // Call HalfSecHandler every 500ms ActKey(KEYON+REXEC(REXEC_HalfSecHandler, 500, "HalfSecHandler();", RNOSTOP)); } //****************************************************************** int LEDStatus = 0; int HalfSecHandler() { // Toggle LED2 on/off using the ^ operator ActKey(PULSE+KEYON+LED(&Throttle, LED_ONOFF, LED_CURRENT^LED2)); // Toggle LED1 on/off using if/else statements and the LEDStatus variable. if (LEDStatus == 0) { ActKey(PULSE+KEYON+LED(&Throttle, LED_ONOFF, LED_CURRENT+LED1)); LEDStatus = 1; } else { ActKey(PULSE+KEYON+LED(&Throttle, LED_ONOFF, LED_CURRENT-LED1)); LEDStatus = 0; } } //****************************************************************** int EventHandle(int type, alias o, int x) { DefaultMapping(&o, x); } //****************************************************************** You can run the REXEC'ed handler faster than 500ms. I tried every 100ms, but it didn't look like it was working that fast. If you aren't aware, you have to use ActKey(KEYON+REXEC...); because REXEC is not a normal executable function. Instead, like EXEC(), LED(), AXMAP(), LIST(), etc., these functions cannot be called without an ActKey or outside of a MapKey or KeyAxis, etc. Also, the defined value "REXEC_HalfSecHandler" is just a handle so you can differentiate different REXEC commands from each other and stop them later using StopAutoRepeat(REXEC_HalfSecHandler);. See REXEC in the manual for details.

I'm not a DCS Lua expert, but what I know from previous people trying to do this kind of thing is it works in single player fine, but not in multiplayer. The reason is because the parameters that everyone seems to find for their LUA script tends to only work in single player. You have to find the equivalent information which is available for multiplayer, but comes from a different source. This is related (I assume) to issues of cheat avoidance, or multipayer server settings locking out certain information. You might want to use hooks into DCSBios (or are you already?). The latest DCSBios which is being maintained by the guys working on DCSFlightPanels has hooks for all the latest aircraft, and is has always worked fine in single and multiplayer. I also assume DCSBios will make your task easier, but I haven't played with it directly to know. I just assume the whole purpose of DCSBios is to streamline the access to DCS information and control things in DCS as well even over a longer period of time where ED might change the LUA scripts, but DCSBios will always be consistent (assuming development continues on it).

As Supma says, make sure it isn't related to how you programmed it using a hold or press function, but since you also say it happens when flying the A10, and I assume that is not using Joystick Gremlin, it may indicate a problem with your Warthog Throttle. Do you ever see an issue with "splashed" outputs when looking at these buttons in the Windows Joystick control panel program. Or what about using the Thrustmaster TARGET Device Analyzer (run from the TARGET Script editor, or you can find it at "C:\Program Files (x86)\Thrustmaster\TARGET\x64\TARGETDeviceAnalyzer.exe"). Either should show you all buttons, but of course they only show you the DirectX version of those buttons (i.e. you won't see a positive "ON" for a button that is off like the APU Start in the OFF position). But this is good enough to tell if something is doing what it shouldn't be because it bypasses any possible programming you may have applied.

The issue which I am talking about isn't that you can't achieve it or do so with a good "force profile". The issue is whether a designer chooses to achieve it. The choice is mostly financial, but not impossible. From what I can see, Gauss has the right hardware - they chose to go with expensive motors, direct drive to the gimbal, and a good gimbal. What is left is the servo tuning. That is just software (a proper feedback or servo tuning loop) and time. Again, I am assuming they got the hardware right already, but sometimes tuning a feedback loop requires changing the mechanical stuff or maybe adjustments to the electronics. You need a strong enough motor to not saturate the motor (max it out), you need to reduce slop in the mechanism (hopefully done by choosing a direct drive gimbal), and you may need to adjust the electronics (to not over drive the motors or over drive the gimbal). But the feedback loop and software can tackle most of this. For a $200 consumer FFB stick, I don't expect such perfection - they can't achieve it because they made the choice to use inferior motors and plastic parts. The MS FFB2 almost got it right on their gimbal, but not enough buttons, some minor issues with the FFB firmware, and you can still feel the motor poles pulsing and gears grinding. For $1100, I expect the Gauss FFB stick to not have these issues. That is what you are spending the money for if you buy a Gauss (assuming they get the tuning right). Otherwise, why are we even here. No, I don't expect what I am looking for in a $200-$300 consumer level FFB stick, but for $1100, it better be able to hold a Warthog grip back against gravity. Otherwise I might as well keep using my Logtiech G940, which through custom tuning, does hold the stick back against gravity (thanks to fred41's firmware patches and some hardware modifications - but it doesn't work for all G940's - depends on the luck of the draw on the parts inside your G940). Yes, you are correct except I think you are thinking only in terms of a simulated spring or maybe just in terms of the simple FFB commands issued by the game. Feedback or servo loops do exactly what you are saying (an increasing force as you move away from zero), but also do what I am asking for (compensate for the heft of the mass, including gravity, and making sure the mass is moved to zero accurately and without oscillation). In a FFB stick, zero is a position that is commanded by the flight sim or game, and it commands that position using simple "go to" or "apply force" commands. This is no different than a CNC machine except that all CNC machines place a buffer between the commanding computer and the machine and that buffer is called a PID loop (a servo or feedback loop). I assume all FFB sticks do some form of feedback loop but I'm not impressed with what I have seen for consumer level sticks. PID loops (https://en.wikipedia.org/wiki/PID_controller) are used in everything from CNC machines to controlling the temperature of your heating and air conditioning. Advanced versions of PID loops have factors that explicitly counteract gravity while dealing with a mass moving in angular directions (just like a joystick), and they do this while maintaining accuracy within 0.0005 inch (0.001mm) or better. There is no reason why a 2 axis joystick can't do the same. It all depends on the gimbal, motors, and connection to the motors, and an accurate feedback source. For a joystick, a hall effect sensor is good enough. Beyond that, the rest is software. A PID servo loop is an equation that simulates spring or a proportional force (P - a force that increases the further you get away from the desired "zero" point), a damping or derivative force (D - a force that counteracts excessive movement such as overshoot and oscillation), and a "kicker" or integrated force that will nudge the mass into proper zero (I - a force that increases over time at a rate determine by the error between the commanded position and the actual position). This is some of the coolest stuff in engineering, and some of what I do for a living. It is easy to understand, a little difficult to implement, but very effective when done right. If you have any interest in DIY projects that involve AC or DC servo motors, the wiki page linked above (or a book on the subject) is a must read. One of the reasons so many DIY machines use stepper motors instead of AC or DC servo motors is because implementing a PID loop is often considered too difficult (the other is cost of course). A stepper motor doesn't need feedback (because they are commanded to move X number of steps and that is the "feedback" - they just go to X without error), but they are also not appropriate for a FFB stick, because they don't freewheel.

FoxHoundcn, thanks for the video. This helps. Though it looks like the forced position does not match the position where you hit the button - the stick is pulling back toward center too much rather than staying where it was when you hit the button. But that is fine for now because your video clearly shows it has enough force to pull the stick back up. I'll wait for a more official release and reviews to understand more. If you want to redo the video better to show it not moving at all when you hit the button and let the stick go, press and hold the force trim button, move the stick, then release the button and it won't (or shouldn't) jump at all. Then when you relax your hand, or take your hand off the stick, it should not fall due to gravity. This would work for the KA-50 and Huey for example, but the Gazelle is not a good choice for this test as force trim doesn't work right on the Gazelle. If you use simFFB, it will do the same thing without having to load DCS, as well as let you test other ideas like adding hydraulic feel, and friction. In fact, adding these kinds of effects through your software to your FFB stick in general would be a great feature. You can find simFFB here: https://forums.eagle.ru/showthread.php?t=84883 Use the version posted in this post (#43) on the above forum topic - it has some extra features that are important: https://forums.eagle.ru/showpost.php?p=1628706&postcount=43 Again, I'm good for now, just trying to be helpful. I'll wait for a released product to see more. Thank you!

I agree, in a real world in a helicopter like the Huey, you would not want to remove your hand from the cyclic. But this is a sim and I often have to take my hand off the stick for non-realistic reasons like using a mouse. In the Gazelle and KA-50, stability systems make this possible in the real world aircraft as well. But if the sim joystick falls forward even as little as 1mm (measured at the top of the stick, normal length), that is enough to overcome the SAS on the Gazelle or maybe the KA-50 stability systems and cause the nose to dip radically. For the Huey, force trim is practically useless with that kind of slop other than just reducing arm stress. Also, in a real world fixed wing, you absolutely take your hands off the stick or yoke all the time to mess with a map or do other stuff. That's why we trim the aircraft. I just suggested the helicopter force trim as the best way to test if there is slop. The MS FFB2 is very good at not falling forward due to gravity. The Logitech G940 is very bad about this - even after I have applied fred41's latest firmware patch, and taken all the slack out of the mechanical parts, it still falls forward 1mm due to weak motors. But these are consumer FFB sticks made mostly of plastic. For $1100, I expect a FFB stick to be perfect at this with the grips that are compatible with it. Otherwise, I might as well just keep using my G940.

FoxHoundcn, thanks for the video. Can you show the stick without the wiggle and using force trim (magnetic brake) effects like in a helicopter (e.g. DCS Huey, but you can use simFFB to create the effect if your software doesn't have this ability). The key effect to see is to force trim the stick forward (away from the pilot) and show that it holds the stick without falling forward due to gravity. Showing that it has the power to move the heavy Warthog stick is a good start (and it looked good), but the ability to hold the stick were commanded against gravity without falling further away from stick center is the real test. Thanks.

Ya, looks like a hardware problem. Is it under warranty? Or are you comfortable with opening it up. If so, make sure all the connectors are on tight and look for pinched or messed up wires as Sokol1_br suggests. You might get lucky. Sorry to hear it. Take it slow and careful if you take it apart. Some parts inside the throttle are not easy to reassemble (like the springs that hold the friction pads for the throttle levers - avoid taking that stuff apart if you can). But the main goal is to make sure all the wires are connected or not broken. The Thrustmaster TARGET Device Analyzer (for monitoring the analog axis and DirectX buttons) and the Event Tester (for monitoring keyboard presses) can be run from the icon bar along the top of the TARGET Script Editor. Or you can run the .exe files directly from the TARGET installation directory. I don't remember if they give you Start Menu icons.

I came up with 5 simple changes anyone can make to the stick (which includes one 3D printed part) which make a good improvement mechanically - takes out all the slack or backlash. I'll post a video of the changes soon, including the model of the 3D part for people to print their own, and I'll post it on Shapeways for people without access to a 3D printer. Other than the 3D printed part, getting some proper grease, and buying some Locktight if you don't already have some, everything can be done at home with a screwdriver and a file. Sorry for the teaser - give me a couple days to get the video done because doing the changes incorrectly could make things worse or ruin your G940.

Hmm the sensor switch issue sounds like a hardware issue but you said it worked in DCS without TARGET. So I don”t know what to say about that one. You also said that TARGET would sometimes “ABEND”. What did you mean by that? If you mean TARGET would unload or stop your current configuration, that is very likely an issue with Windows doing a power down of USB devices which has caused no end of issues for many people. TARGET dropping out is just the result but it is actually a Windows issue. I had that issue and the fix can require many different things from bad audio jack connectors to bad drivers to (my last one I found) bad firmware controlling the LEDs on my Corsair CPU water cooler. Ya that specific. There is an entire thread here on the forums about this USB issue, but it affects all Windows users not just DCS simmers. In DCS sometimes, the USB issue will cause DCS to freeze for 2 to 5 seconds. But the last issue I had just caused TARGRT to stop my current profile with no indication - until I tried to use an axis or press a button. New firmware for the Corsair water cooler fixed it. Does any of this sound like what you have seen?

I just added this comment to the first post as an update. Previous readers of this topic already know this, but I added it so new readers would see his patch right away in the first message and go get it. New Info June 2019: fred41 has created a patch for the v1.42 firmware that solves the reversal bug for ALL axis now, as well as improves some of the force feedback settings which improves the general feel of the stick. Finally after a decade since it was released, the G940 HOTAS works the way it should. You apply fred41's patch to the v1.42 firmware installer which is linked below. Then just run the v1.42 firmware installer like normal and fred41's patches will be applied to the stick. Thanks fred41!! Link to fred41's forum topic on the firmware patch: https://forums.eagle.ru/showthread.php?t=240114 Link to the patch: https://github.com/fred41/G940-firmware-fixes

Ah, ya that is a problem. As far as I know, DCS has no clue which grip is installed. The USB ID's and device names don't change with a different grip. I always use TARGET and I program all my TM controls to press the default keyboard key combos as defined in DCS. The only thing I define in DCS itself are to map the axis. Obviously this is one way to solve it. But if you want to do this by mapping buttons as DirectX buttons in DCS, I think the only solution short of buying a 2nd base is to swap the LUA configuration files for the Warthog when you swap the grips. I know a lot of people prefer to program everything through DCS instead of TARGET. Either is a good way to do it. But issues like what you describe, and also because DCS sometimes clobbers the controller config LUA files after an update, I avoid mapping controllers in DCS as much as I can. It is frustrating because DCS has an excellent system for mapping complex controller configs. Nothing is ever perfect I guess.

Some suggestions: Did you unplug the USB cable before mounting the stick. The F18 grip manual doesn't say, and it should! The Warthog manual might say, but who pulled that out to check. :) Anyway, these weren't really designed to be hot swapable, and even if your computer is off, the USB ports are still powered up. Though swapping them while powered is not likely to cause damage (just make sure you discharge static electricity between you, the grip, and the base before plugging it in), but the Warthog base's software does some initialization through the DIN connector when it powers up, or is reset. So that is one possible issue. Are you sure you have the latest firmware on your Warthog base? There was an update last year. the update doesn't specifically say it supports the F18 grip, but it might and they just didn't say anything in the release notes. Check out the support page for the F18 Grip for downloads: https://support.thrustmaster.com/en/product/f-a-18c-hornet-hotas-add-on-grip-en/ If you are using TARGET, you need to get the latest version also. It too was updated last year, so maybe same as the firmware - maybe they did the F18 updates last year and didn't list it in the release notes. Regarding rebinding keys in DCS, each aircraft has their own bindings. So if you bind the A10C grip on the DCS A10C module, then bind the F18 grip on the DCS F18, these should have no impact on each other. But I would un plug and re-plug the Warthog base not only to swap the handle, but also to make sure DCS sees that the stick has changed (if it matters). DCS does not require a restart when swapping any USB controller (Warthog A10C vs. F18 or anything else). It also doesn't need to be restarted just because you run a different TARGET profile. DCS accepts hot swapping of USB game controllers just fine. You can do it even while flying. You only need to refer to my previous comments about disconnecting the USB cable, and rerunning a new profile in TARGET. I.e. you don't even have to restart TARGET. It only looks for TM devices when you compile and run the TARGET script. I hope this helps.

The throttle quadrant that comes with the yoke has a 6 pin DIN connector. I took mine apart once but forgot the pinout. I couldn't find the pinout from an Internet search. However, because the USB Logitech/Saitek Throttle Quadrant sells for $60 retail. It is so cheap that your best bet is just go buy a new USB Quadrant. These are so cheap brand new, that I never even tried to buy one on eBay because used ones often are missing clamps or knobs, and replacing those parts is nearly impossible. You can get an Arduino or Bodnar board and make some or all of the Yoke's throttle quadrant work, but by the time you are done, you'll spend half the price of a new USB quadrant and still have to count your time. Do it only because it is a fun project, not because it'll save you anything. Anyway, for the adventurous... With only 6 pins on the connector, I think the 3 axis are brought out on 3 of the pins as analog signals, so you can make those work with an Arduino or Bodnar board with direct wiring to the analog inputs. But the buttons are encoded as a serial bit stream. I.e. they send the 9 button states as a bit stream on a single wire, and that bit stream must be decoded by the circuit in the yoke. This is exactly the same thing done with the DIN connector on a TM Warthog stick, for example. Very common in game controllers. The other 2 pins would be power (5V or 3.3V???), and Ground. I don't think a Bodnar board can be custom programmed to handle bit streams (by the user at least - maybe Bodnar added the feature to some of his products). An Arduino can certainly handle the task, but you have to write the software. Again, a fun project and very simple really. The (mildly) hard part is just decoding the pinout of the DIN, and decoding the bit stream. You'll need a simple logic analyzer or oscilloscope and a volt meter.

I noticed recently that BARO_ALT_VALUE for the Gazelle was not providing a very accurate altitude. I thought it used to be correct, but no longer (??). Anyway, I did the calculations to get an accurate reading from BARO_ALT_THOUSANDS. Here is the Formula you can use. Just paste this into one of the LCD Data fields for the Multi-Panel. Ifless (BARO_ALT_THOUSANDS 23311 (Ifless (BARO_ALT_THOUSANDS 16626 (Ifless (BARO_ALT_THOUSANDS 13350 (Ifless (BARO_ALT_THOUSANDS 9942 (Ifless (BARO_ALT_THOUSANDS 3408 (round((BARO_ALT_THOUSANDS-((BARO_ALT_THOUSANDS*0.039860)-19))*0.152588)) (round((BARO_ALT_THOUSANDS-111)*0.152588)) ) ) (round((BARO_ALT_THOUSANDS-((BARO_ALT_THOUSANDS*0.04)-287))*0.152588) ) ) ) (round((BARO_ALT_THOUSANDS-242)*0.152588)) ) ) (round((BARO_ALT_THOUSANDS-((BARO_ALT_THOUSANDS*0.02)-92))*0.152588)) ) ) (round((BARO_ALT_THOUSANDS-((BARO_ALT_THOUSANDS*(-0.04))+1304))*0.152588))) Here is the same formula but more readable in case you are curious what I did. Make sure you copy and paste the one above into DCSFlightPanels, not the one below!! FlightPanels needs the formula to be all one line. Ifless (BARO_ALT_THOUSANDS 23311 (Ifless (BARO_ALT_THOUSANDS 16626 (Ifless (BARO_ALT_THOUSANDS 13350 (Ifless (BARO_ALT_THOUSANDS 9942 (Ifless (BARO_ALT_THOUSANDS 3408 (round((BARO_ALT_THOUSANDS-((BARO_ALT_THOUSANDS*0.039860)-19))*0.152588)) (round((BARO_ALT_THOUSANDS-111)*0.152588)) ) ) (round((BARO_ALT_THOUSANDS-((BARO_ALT_THOUSANDS*0.04)-287))*0.152588) ) ) ) (round((BARO_ALT_THOUSANDS-242)*0.152588)) ) ) (round((BARO_ALT_THOUSANDS-((BARO_ALT_THOUSANDS*0.02)-92))*0.152588)) ) ) (round((BARO_ALT_THOUSANDS-((BARO_ALT_THOUSANDS*(-0.04))+1304))*0.152588)) ) It is accurate to 4000 meters and close enough above that. Since the curve keeps changing (did you see all those Ifless commands!!), I stopped at 4000 meters because who is going to fly that high anyway, right? :) Well, I did fly up to 8000 meters and it was only 100 or 150 meters off at that point. But I wouldn't trust that assessment. I mean at 8000 meters (26250 feet) the oxygen was so thin that everything was graying out on me (yes DCS does that). So I wouldn't trust that either I or my co-pilot had a clue what altitude we were at, much the less what an altimeter even looks like. :drunk: But it was an epic 8000 meter auto-rotation just for kicks with a socked in cloud layer at 3000 meter too. BTW., RADAR_ALT_VALUE was mostly spot on - a little fluctuation at < 100 meters, but spot on all the way to max (about 850 meters). ArturDCS, not sure if the above formula is useful for you to fix DCS-BIOS's BARO_ALT_VALUE, but if you want to fix it, let me know what you need. I have all the slopes and offsets in an excel spreadsheet if needed. FYI, 0.152588 = 10000/65536 which converts the 0 to 65535 value for BARO_ALT_THOUSANDS to meters. All the other numbers in the formula are slopes and offsets which I had to calculate from the spreadsheet.

Great work fred41. Thanks for your efforts! I had already started on some designs to fix this gimbal. I have a CNC machine shop and a good 3D printer (not a hobby printer). So making and testing the parts (machined, or printed) isn't a problem. I started working on this a while ago and fred41's firmware fixes has reinvigorated me to finish the task. Part of the slop on this stick is because of the software deadzone, or I call it the weakzone because the motors just stop trying at the stick's center position. So making a new gimbal was a waste of time if the software still didn't take up the slack, literally. But it looks like fred41's changes have done that. So now making a new tighter gimbal is finally worth it. Time to dust off the Solidworks models and see what I can come up with.

To many variables. Isolate just the throttle and make sure it is working in the Thrustmaster TARGET Device Analyzer (it will show you all axis and DirectX buttons). If you are programming the throttle with TARGET, also use the Device Analyzer as well as the TARGET Event Tester to see programmed key strokes. But more likely, it might just be that you need to clear all your DCS command configs (mappings for the Warthog and all other game controllers you use) because after major updates, they sometimes mess with the config tables and corrupt things. Do the two things above first and it will go a long way toward fixing or narrowing things down.

I must be tired. Which one is the sensor select switch? Or is that your name for something you are assigning to the Warthog? Are you talking about the Slew Control (the little finger joystick on the throttle)?

Propeler, I assume 2.4kg at 10cm is 0.24 kg-m which is 2.35 N-m. That”s what you just calculated, correct? If so, then that is just over half the torque of the Brunner which makes sense that this stick is much smaller than the Brunner. Correct? I’m confused about the comment “even with a 10mm extension”. A normal grip’s CG is about 10cm from the stick’s gimbal. An extra 10cm extension would move that CG twice as far away (ignoring the weight of the extension) which would halve the power of the FFB stick or rather require twice the torque to get he same performance. So really a Brunner with a Warthog grip and a 10cm extension is about the same as this new FFB stick at no extension and hence not powerful enough to handle the grip. Is that what you meant?

I'm making a lot of assumptions here, but mostly I'm happy with what I see. I've been on a slow burn designing my own FFB stick (just as a DIY project) and many of the things I see this stick doing is exactly what my own goals were intending to achieve. But such a stick isn't cheap even as a DIY project. FoxHoundcn, congrats on your efforts. Here is what I think I see. I hope you can confirm if I have some of this right. Even at that price, I am very interested. The biggest thing I see is what appears to be a well designed FFB stick but it isn't huge like the Brunner. Maybe that is good, or maybe it means this new stick is just underpowered or might have weak parts. But what I see implies a strong stick. Hence my congrats for making this small and powerful. Why so expensive? My comments... Aside from being a niche market, the big deal is direct drive, no gears! To get that kind of smoothness and precision requires expensive (relatively powerful and high quality) motors to drive that kind of torque without gearing. They also tend to be big motors, hence why I am wondering if the force is strong enough. Compare this to the $1000-$2000 direct drive race car sim wheels that are all the rage today for serious race simmers. My guarded thoughts are they did this one right at least in the mechanical/motor design and the price does not surprise me at all. Watch the videos carefully. The stick is moving more like a CNC machine with what appears to be proper PID feedback loops. In the video where it is vibrating like crazy (https://www.youtube.com/watch?v=vbo9mHjw4Sk&feature=youtu.be), he grabs it and moves it and when released, despite the vibration and large spring constant (fast return rate to center), it snaps back to center and does not oscillate back and forth or overshoot (other than the vibration). Do that with a Logitech G940, and it would go into a self destructive oscillation. A MS FFB2 would be better, but would still oveshoot or oscillate several times before hopefully coming to a stop. That is why these sticks have a hand sensor on them. Leaving any consumer FFB stick like the G940 or MS FFB 2 plugged in, powered up, and unattended (if you have taped over the hand sensor like most of us have), is a dangerous thing to do because a minor input could send the stick into a destructive oscillation. Ever had your cat play with your FFB stick? They will only do it once. :) But a better design can prevent this and not have to use a hand sensor either. It is done with PID feedback loops, good motors, and accurate position sensing. Or in this video (https://www.youtube.com/watch?v=mjz5KQghIks&feature=youtu.be), see how it snaps back initially kind of quickly, but decelerates as it approaches the center point. Again, this tells me the stick is using good software to control it's movements (good acceleration and deceleration along with PID feedback loops), and good hardware. This is exactly the kind of design I've been talking about for years. The right way to do a FFB stick. Direct drive (no notchy feeling due to gearing), and proper PID feedback loops. At least that is what I hope I am seeing. Maybe I'm reading too much into the videos. But it looks good so far. My questions... (I hope FoxHoundcn can respond to these questions.) If the chosen motors are not high pole count motors, or maybe planetary gear motors (which means they are geared, but the gearing is built into the motor and should be very smooth), then we will still feel significant notchiness due to crossing the magnetic poles of the motor. I can't tell about this from the videos of course. That requies holding one for real. Even on the MS FFB2, being the nicest feeling consumer FFB stick ever made, you can feel the change in magnetic field as you pass through the poles of the motor. It isn't bad, but definitely noticable. It is that good on the MS FFB due to gearing (abot 80 to 1 if I remember correctly). So to have no gearing, the motor is turning only about 40 degrees (so ratio is more like 0.3 to 1). The notchiness can be very prominent unless the motors are very high pole count. For $1100, I would hope this new stick has no such notchiness. Also, in the 2nd video linked above, it looks like the stick does not always return to the same center position. The first 2 releases, it was very precise with a perfect deceleration to center. The second two releases, it didn't look so precise, not returning to center. Maybe it is still early software or maybe I am mis-interpreting what is happening. I assume "TM Cougar, TM Warthog" compatibility means the grips from these sticks screw on. But I assume that does not mean any kind of TM TARGET compatibility. Does this FFB stick have any software for programming buttons? That's what I can gather from the pictures and videos. I'm looking forward to real information soon.

I use this one. I paid $76 for it last year. BrovSS- 10 Ports USB 2.0 Hub - USB Charging Splitter Hub LEDs with 5V 10A 120W Power Adapter https://www.amazon.com/gp/product/B07F7F5WV2/ref=ppx_yo_dt_b_asin_title_o01_s00 Or here is the slightly cheaper version, though I haven't used this one: BrovSS- 10 Ports USB 2.0 Powered Hub - USB Extension Splitter for Mining with 12V 5A 60W Adapter https://www.amazon.com/dp/B076HLY2L9/ref=sspa_dk_detail_2 Here is their product web page. https://brovss.shop/collections/all-products My goal was to make sure that power wasn't an issue. I don't trust half the power supply specs we see on USB hubs. Most game controllers take less than 100mA, but some want 250-350mA. At 120W, the one I bought is clearly capable of powering anything I plug into it, while also charging several iPads and iPhones at the same time (no, I don't do that). Overkill, yes, but after having some issues, I didn't want to mess around anymore. The cheaper one is half the power and but still way over kill for sim controllers. These things were sold originally for Bitcoin mining USB compute modules. So most the negative reviews on them are because the cheaper one (for example) couldn't run 10 power hungry CPU modules. We don't care about that for our simming as the cheaper 60W one is still over kill for our needs. Also, as said, for game controllers, get USB 2.0, not 3.0. A USB3.0 hub might actually mess with some game controllers due to driver or hardware issues.

Ya, TARGET Scripting is the way to go if you can type quickly. It is faster than doing it in the GUI for me. I start with a blank or previous script as a template where I have MapKey...() and MapAxis() commands for all my buttons and axis already entered, but zeroed out (disabled). It is already set up with all my common DCS configurations (zoom, SRS Radios, Discord, and common key configs I use on all aircraft). I fill out the .tmh file to define my key-combo macros in a single operation, then just copy and paste the macro names from the .tmh file into the .tmc file Mapkey commands, throwing in a few customizations like PULSE or CHAIN where needed. But I know for many, the GUI will always be easier. I'm glad TM did both, and the GUI is still very powerful. And the cool part about it is, as you use the GUI, you still get educated on how the scripts work even without looking at the actual script as the words and names used are the same.