I figured it out. Turns out the combined Warthog wasn’t well calibrated. I went into the USB control panel and calibrated the Y axis for the nib.

Not I need to figure out if I want to make any changes, especially the keybindings. My keyboard has custom labels on the keys and I haven’t decided if I want redo the labels or modify the scripts.

Thanks for letting me know. Glad its all working. :)

Now that you have said that, I recall some other users a long time back with similar issue but with different axes (showed as mapped but didn't work for some reason till they remapped the same command over it again).

Labels might be quicker, and avoid any possible issues with rebinding. Ultimately, you should not need to use the keyboard directly though as everything is mapped on the HOTAS, but just depends how you like to play at the end of the day. Best of luck!
 
Jan 2018 'Beta' Update!

Update 3.0.1: THE BEYOND CHAPTER 1 BETA UPDATE

-> Small update adding new bindings from Chapter 1 'Beta'.


List of Changes:

NEW: Added all Galnet Audio keymappings to PIP Hatswitch + Pinky Modifier [1]. (Up to Play/Pause, Right to Skip Forward, Left to Skip Back & Down to Clear Queue.)



[alien] Fly Safe CMDRs! [alien]

** Please visit the ModDB link to get the latest version *** Steam Guide can be found here **
 
Last edited:
Hi Aussiedroid , Im using your script and i totally love it ! ,

I'm trying to add some new functionality to it but i cant figure out the logic.
Could you help me out with a little bit of code to use a button and give it a "genuine" double tap function?

For example i want to be able to double tap the pinky switch so when i press it twice in a very short amount of time
( lets say 0.25 seconds ) it should hold the button down . Then when its in this state , pressing it only shortly again should "unlock" it

Any idea how this can be achieved , with some flags / maybe counters ?
 
Hi Aussiedroid , Im using your script and i totally love it ! ,

I'm trying to add some new functionality to it but i cant figure out the logic.
Could you help me out with a little bit of code to use a button and give it a "genuine" double tap function?

For example i want to be able to double tap the pinky switch so when i press it twice in a very short amount of time
( lets say 0.25 seconds ) it should hold the button down . Then when its in this state , pressing it only shortly again should "unlock" it

Any idea how this can be achieved , with some flags / maybe counters ?


Thanks Severn!

I tried a while back to see if I could find a way to do a genuine double tap function (seems to be the only thing missing that Target doesn't cater for), so ended up going down the press/hold using the Tempo command for a lot of things. I couldn't get something working properly for it at the time, but took another crack at the logic. The limitation that I see is that we don't really have a way to time when a key has been pressed. The only timer of sorts is the DeferCall command, so was thinking if something along these lines might work.

Will need to fill in the code, but this would track 3 states when fired from the button. First press DT (DoubleTap counter) fires the first line of code actioning the PULSE, setting a delay (DeferCall) to reset the DT counter to 0 (double tap speed). If button is triggered again before the DT counter is reset to 0, then it should fire 2nd line of code actioning the HOLD action, setting DT counter to 2 & sets HP (HoldPinky state tracker) to 1. If you happen to press a third trigger in the timeframe, it will fire the third line and simply release the hold with an UP. Any delay should result in reset of DT to reset the loop.


int initDoubleTap() {
if(DT == 0) if(HP == 1) UP Pinky & set HP to 0, else PULSE Pinky, set DT to 1, DeferCall DT reset 0
else if(DT == 1) DOWN Pinky, set DT to 2, set HP to 1
else if(DT == 2) UP Pinky & set HP to 0
}

Don't know if it will work in practice, just spit-ballin' an idea, but might give you something to try.

If it works, would be great to see what you did & how you are going to use it :)

AD
 
Last edited:
Thanks for the helpfull tips Aussiedroid !
I will tinker with it tonight and let you know what
I come up with .

Severn
 
Thanks Severn!

Don't know if it will work in practice, just spit-ballin' an idea, but might give you something to try.

If it works, would be great to see what you did & how you are going to use it :)

AD

Code:
include "target.tmh"

define DELAI	250	//ms -> Set this to 500 if you want the doubletap to pick up sooner
int S4_DBCLK=0;
int S4_Press=0;
int main()
{
    Exclude(&HCougar); Exclude(&T16000); Exclude(&LMFD); Exclude(&RMFD);
    if(Init(&EventHandle))return 1;

  MapKey(&Joystick, S3, CHAIN (TEMPO(EXEC("S4_Press=S4_Press+1;"),EXEC("S4_Press=0;"),150),DX3));
  MapKeyR(&Joystick, S3, EXEC("if(S4_Press)S4_DBCLK=DoubleClicked(&S4_Press)^S4_DBCLK;"));
  MapKey(&Joystick, TG1, EXEC("printf(\"S4_DBCLK=%d\\xa\",S4_DBCLK);"));
    printf("...ready\xa");
}

int DoubleClicked(alias f)
{
  if(f==1)
  {
    DeferCall(DELAI, &RazFlag, &f);
    return 0;
  }
  else{Activate();return 1;}
}

int RazFlag(alias f){f=0;}

int Activate()
{
  //char buffer;Dim(&buffer, 64);
  //sprintf (&buffer, "spawn e:\\wbeep.exe %d %d", freq, duree);
  printf("...testing\xa");
  //ActKey (KEYON+DX3);  => Uncomment this line if you want to have the pinky switch act as the dedicated double tap / then comment the 2 lines below
if(S4_DBCLK==1) {ActKey (KEYON+DX15);}
if(S4_DBCLK==0) {ActKey (DX15);}
 //system(&buffer);
}

int EventHandle(int type, alias o, int x)
{
	DefaultMapping(&o, x);
}

Hi Aussiedroid

Okay i did some googling around and found a piece of code and changed it to suit my own .
This is now working as intended .
When you double tap the pinky switch . you can activate the same or also a different button.
( in this example DX15 , gets an HOLD action while double tapping)
I now use the double tap PINKY (S3) for the following functions :

- When i'm in the air i switch between YAW - ROLL
- When in the SRV when doubletapping it puts on PARKING BRAKE

Offcourse you can try it on other buttons , although it might not be that intuitive on hat switches.

This is where if found the example : http://simhq.com/forum/ubbthreads.php/topics/3857928/DoubleClick_TARGET_Script

KUDOs To you and _Frenchy from SimHQ! [smile]

Severn
 
It's been awhile but I found this thread while searching for a solution to a recent issue with Win10 and the TM Warthog - has anyone else that is part of the Windows Insider Program had issues with running TARGET scripts under the more recent builds? I was seeing an issue with the drivers used by the Thrustmaster Combined devices where it was refusing to load the drivers with the error:

Error 39 ("Windows cannot load the device driver for this hardware. The driver may be corrupted or missing. (Code 39)")

Anyone else using the Insider builds? Seen similar issues? I reached out to Thrustmaster and they were of zero help
 
It's been awhile but I found this thread while searching for a solution to a recent issue with Win10 and the TM Warthog - has anyone else that is part of the Windows Insider Program had issues with running TARGET scripts under the more recent builds? I was seeing an issue with the drivers used by the Thrustmaster Combined devices where it was refusing to load the drivers with the error:

Error 39 ("Windows cannot load the device driver for this hardware. The driver may be corrupted or missing. (Code 39)")

Anyone else using the Insider builds? Seen similar issues? I reached out to Thrustmaster and they were of zero help

Hey Spectre-63,

Nothing has been reported on the thread or across on the Steam Guide in previous months around Win10 driver issues. I run Win7 again so I can't be much more help than that unfortunately.

AD
 
So on the FA-off part of the script, if I read your code right, you are just swapping out sensitivity curves correct?

I was thinking of taking the input time derivative, but found two issues. One is that the joystick only sends new packet when the position changes, meaning you need to keep track of time via the system clock or something. Second is that for my (probably horribly coded) solutions the loop time is inconsistent which means the derivative accumulates error over time. Not exactly what one would like. I'll dig out the code and edit this post when I found it. :)

Mad props for the script though, that is some nicely organized and function scripting!
 
Last edited:
So on the FA-off part of the script, if I read your code right, you are just swapping out sensitivity curves correct?

I was thinking of taking the input time derivative, but found two issues. One is that the joystick only sends new packet when the position changes, meaning you need to keep track of time via the system clock or something. Second is that for my (probably horribly coded) solutions the loop time is inconsistent which means the derivative accumulates error over time. Not exactly what one would like. I'll dig out the code and edit this post when I found it. :)

Mad props for the script though, that is some nicely organized and function scripting!

Thanks Torashuu!

With the FAOff function you are correct. For the hold action it will change the curve for the x & y axis via the SetSCurve. When hold is released it will go back to normal curve.

I'm not really following regarding the input time derivative - I don't really know what that is. Perhaps if I see the code I will know what you are discussing a bit clearer. :)

Cheers, AD
 
Last edited:
I am afraid I will have to owe you that code, as I apparently threw it out. :( I recall I had an implementation in the event handler where I would store the last 5 events, calculate the average change and send that out as stick output (with a multiplier). But the stick axis input wasnt spaced evenly in time so a derivative didn't work.

Latest version is a wonky AXMAP that converts the axis into keypresses with a non-working mode switch.

Code:
[COLOR=#1E90FF][B]include[/B][/COLOR] [COLOR=#A52A2A]"target.tmh"[/COLOR] [COLOR=#32CD32]//here we link this file to the file that contains the default Thrustmaster function code[/COLOR]


[COLOR=#1E90FF][B]int[/B][/COLOR] main()
{
[COLOR=#32CD32]//exlude throttle[/COLOR]
Configure(&Throttle[COLOR=#FFFFFF],[/COLOR]MODE_EXCLUDED);

[COLOR=#1E90FF][B]if[/B][/COLOR][COLOR=#FFFFFF]([/COLOR]Init(&EventHandle)) [COLOR=#1E90FF][B]return[/B][/COLOR] [COLOR=#FFFFFF]1[/COLOR]; [COLOR=#32CD32]// declare the event handler, return on error[/COLOR]

[COLOR=#32CD32]//axis[/COLOR]
MapAxis(&Joystick, JOYX, DX_X_AXIS);
MapAxis(&Joystick, JOYY, DX_Y_AXIS);

KeyAxis(&Joystick, JOYX, [COLOR=#FFFFFF]0[/COLOR], AXMAP1[COLOR=#FFFFFF]([/COLOR][COLOR=#FFFFFF]512[/COLOR], PULSE+[COLOR=#A52A2A]'a'[/COLOR], PULSE+[COLOR=#A52A2A]'d'[/COLOR]));
KeyAxis(&Joystick, JOYY, [COLOR=#FFFFFF]0[/COLOR], AXMAP1[COLOR=#FFFFFF]([/COLOR][COLOR=#FFFFFF]512[/COLOR], PULSE+[COLOR=#A52A2A]'w'[/COLOR], PULSE+[COLOR=#A52A2A]'s'[/COLOR]));

[COLOR=#32CD32]//buttans[/COLOR]

MapKey(&Joystick, TG1, DX1);
MapKey(&Joystick, S2, DX2);
MapKey(&Joystick, S3, 
    EXEC(
        [COLOR=#A52A2A]"DX3;"[/COLOR]
        [COLOR=#A52A2A]"LockAxis(&Joystick, JOYX, 1);"[/COLOR] 
        [COLOR=#A52A2A]"LockAxis(&Joystick, JOYY, 1);"[/COLOR] 
    ));

MapKey(&Joystick, S4, DX4);
MapKey(&Joystick, S1, DX5);
MapKey(&Joystick, TG2, CHAIN[COLOR=#FFFFFF]([/COLOR]PULSE[COLOR=#FFFFFF]+[/COLOR]DX5[COLOR=#FFFFFF],[/COLOR]D()));
MapKeyR(&Joystick, TG2, CHAIN[COLOR=#FFFFFF]([/COLOR]PULSE[COLOR=#FFFFFF]+[/COLOR]DX5[COLOR=#FFFFFF],[/COLOR]D(),PULSE[COLOR=#FFFFFF]+[/COLOR]DX5));

MapKey(&Joystick, H2U, DX7);
MapKey(&Joystick, H2R, DX8);
MapKey(&Joystick, H2D, DX9);
MapKey(&Joystick, H2L, DX10);

MapKey(&Joystick, H3U, DX11);
MapKey(&Joystick, H3R, DX12);
MapKey(&Joystick, H3D, DX13);
MapKey(&Joystick, H3L, DX14);

MapKey(&Joystick, H4U, DX15);
MapKey(&Joystick, H4R, DX16);
MapKey(&Joystick, H4D, DX17);
MapKey(&Joystick, H4L, DX18);
MapKey(&Joystick, H4P, DX19);

MapKey(&Joystick, H1U, DXHATUP);
MapKey(&Joystick, H1R, DXHATRIGHT);
MapKey(&Joystick, H1D, DXHATDOWN);
MapKey(&Joystick, H1L, DXHATLEFT);

[COLOR=#32CD32]//TG1,DX1, S2,DX2, S3,DX3, S4,DX4, S1,DX5, TG2,DX6, H2U,DX7, H2R,DX8, H2D,DX9, H2L,DX10, H3U,DX11, H3R,DX12, H3D,DX13, H3L,DX14,[/COLOR]
[COLOR=#32CD32]//                   H4U,DX15, H4R,DX16, H4D,DX17, H4L,DX18, H4P,DX19, H1U,DXHATUP, H1R,DXHATRIGHT, H1D,DXHATDOWN, H1L,DXHATLEFT[/COLOR]

}
[COLOR=#1E90FF][B]int[/B][/COLOR] EventHandle[COLOR=#FFFFFF]([/COLOR][COLOR=#1E90FF][B]int[/B][/COLOR] type, [COLOR=#1E90FF][B]alias[/B][/COLOR] o, [COLOR=#1E90FF][B]int[/B][/COLOR] x)
{

    DefaultMapping(&o, x);
}

What I mean with with time derivative is best explained in an image. What you want from your stick axis coordinate that you recieve ( top graph for 1 dimenion) you convert to the bottom graph, which would be the stick input you would want for the same result in FA-off.
6XakC4b.png
 
I am sorry, I'm feeling a little dumb as I am still not understanding all that well. The graph does help to explain time derivative better though just not sure how this ties in with the FAOFF etc :).

What is the practical application you are trying to accomplish with the FAOFF and the time derivative? When you press FAOFF what do you want it to do?

AD
 
so when you fly FA-on, and you deflect your stick 50% you command the thrusters to achieve and maintain 50% of max rotational rate (deg/s). When you center the stick again it commands 0 deg/s rotational rate.

When you switch to FA-off, this changes. Deflecting the stick to 50% commands the use of 50% of maximal rotational acceleration (deg/s^2, not speed). If you then center the stick again, no additional acceleration is commanded, hence you keep spinning.

Acceleration is the derivative of speed.

In the default game:
In FA-on you input stick position, and you obtain a speed. (which is also the derivative)
In FA-off you input stick position and you obtain an acceleration( which is the 2nd derivative, which is why stick behavior changes).

By changing the stick input in the second case (from stick position to stick speed (the 2nd graph), the output is the first derivative again of input. Thus it would give you the exact same behavior as the first case!

By changing the stick input from position (top graph) to speed (bottom) when you hit the FA-off button, it would mean controlling your rotation remains the same, but your directional/lateral thrusters still change behavior. You get the freedom of movement from FA-off without the hassle of crappy aim with fixed weapons.

So the goal is to achieve identical rotational control during FA-off as with FA-On. Such that FA-off only changes thruster behavior.
 
Last edited:
Feb 2018 'Live' Update!

Update 3.0.2: THE BEYOND CHAPTER 1 LIVE UPDATE

-> Soon-to-be-out of beta release, with a few more improvements & one exciting new feature, expanding on the previous point release which added the new Galnet Audio keybindings; ready for the live release of Chapter 1.


List of Changes:

NEW: Added a User Definable "Double Tap" feature to the Pinky Trigger on the Joystick. Squeeze trigger twice quickly to activate. Single press remains the Pinky Modifier key. By default, I have mapped this to ShipLights as it is safe & can demonstrate the double tap usage, but this can be changed to almost any frequently used command you want! I have listed a number of suggestions in the EDSettings file for you to try - Check it out! :)

IMPROVEMENT: Added a fourth PIP Preset mode. An Inverted layout of the dual tier configuration, which gives full PIPs on a short press and a single PIP on a long press. Choose '0' for UserPIPPref to enable.
IMPROVEMENT: Changed Fighter Focus mapping with Fighter Attack as it is a more frequently used order to give.

FIXED: Added missing Fwd/Back Thruster mappings to Toe Brakes for MFG Crosswind users. (If you prefer latteral or vertical thrusters instead, then you will loose the mapping for these on the throttle nipple, but can be remapped directly as desired in ED bindings.)



[alien] Fly Safe CMDRs! [alien]

** Please visit the ModDB link to get the latest version *** Steam Guide can be found here **
 
Last edited:
so when you fly FA-on, and you deflect your stick 50% you command the thrusters to achieve and maintain 50% of max rotational rate (deg/s). When you center the stick again it commands 0 deg/s rotational rate.

When you switch to FA-off, this changes. Deflecting the stick to 50% commands the use of 50% of maximal rotational acceleration (deg/s^2, not speed). If you then center the stick again, no additional acceleration is commanded, hence you keep spinning.

Acceleration is the derivative of speed.

In the default game:
In FA-on you input stick position, and you obtain a speed. (which is also the derivative)
In FA-off you input stick position and you obtain an acceleration( which is the 2nd derivative, which is why stick behavior changes).

By changing the stick input in the second case (from stick position to stick speed (the 2nd graph), the output is the first derivative again of input. Thus it would give you the exact same behavior as the first case!

By changing the stick input from position (top graph) to speed (bottom) when you hit the FA-off button, it would mean controlling your rotation remains the same, but your directional/lateral thrusters still change behavior. You get the freedom of movement from FA-off without the hassle of crappy aim with fixed weapons.

So the goal is to achieve identical rotational control during FA-off as with FA-On. Such that FA-off only changes thruster behavior.

Thanks for taking the time to explain it. Makes more sense now. Cool idea too!

I see what you mean by the timing issue, but I'm not sure how you could get around it to time it accurately to counter balance. Only timing function I have used in the past was the DelayCall but can't see how that could help in this scenario. I'm not sure if I can help with this one :(
 
Hey Aussiedroid- thanks for putting this script together - it's pretty cool! After flying with my own bindings for years, Ive recently taken delivery of a set of MFGs and decided to give your script a go. So far it's working reasonably well, except for a delay when toggling the cargo bay or landing gear. All the controls lock out for a few seconds, with is a PITA when you're trying to land or take off. What am I doing wrong?
 
Hey CMDR Awesome!

Thanks for checking out the script :)

That sounds like a very strange issue. I do have a few things mapped to the landing gear and cargo scoop now to allow overriding position, take off procedure etc but these shouldn't really be causing a several second delay. Only the take off procedure has a delay of sorts while it holds down the vertical thrust for a few seconds, but I assume you are just trying a normal toggle. Does the problem persist outside of the game (ie if you test in Event Viewer do you see the delay too)? Have you tried doing a full restart and reload of the game/scripts etc? Just wondering if something has glitched out. Few users have reported strange behavior on first runs but then after a restart or two, or moving usb ports etc it comes good. Might not be the case here if you have been using them fine for a few years already but worth a check.

Cheers, AD
 
Last edited:
Thanks AD. It did seem better after a restart, but not fixed. I will try doing some unplugging and replugging. I take the handle off my stick for storage, which sometimes causes issues.

The bindings all seem logical but relearning years of muscle memory is proving a challenge!
 
Issues with 3.0 keybindings

With the release of 3.0, I cannot locate the warthog bindings under controls. When I looked into the bindings folder I see an error log:

There where errors when loading preset file: Aussiedroid Warthog Enhanced 3.0.2.binds
Failed to find GUID for device: 16D00A38

I’ve changed USB ports with my device, restarted my computer, used saved bindings from before the patch with no fix... I played with 2.4 bindings in the beta with no issue.
 
With the release of 3.0, I cannot locate the warthog bindings under controls. When I looked into the bindings folder I see an error log:

There where errors when loading preset file: Aussiedroid Warthog Enhanced 3.0.2.binds
Failed to find GUID for device: 16D00A38

I’ve changed USB ports with my device, restarted my computer, used saved bindings from before the patch with no fix... I played with 2.4 bindings in the beta with no issue.

Hey MALjCE,

Another CMDR reported same thing across on the Steam Guide earlier today & found a solution (copied below). I haven't had a chance to test things out my end yet but should get a chance this evening. If I can replicate will try to fix (but may need Frontier to resolve).

What is your hardware setup by the way? SSOne hit this issue when using Saitek Rudder Pedals for example. I suspect it is not finding the MFG Crosswind devices which are mapped in the bindings file and instead of just wiping the mappings its causing an error. Below removes the 'problem' GUID to workaround the issue.


SSOne 10 hours ago Delete
Managed to resolve my issue, I had to replace the GUID's in the bindings file with {NoDevice}, then the file would load when I reloaded ED. I then reapplied some bindings, mainly relating to rudder pedals.

Hopefully this helps anyone else with similar issues.

Credit goes to GJ51 on the ED forums (https://forums.frontier.co.uk/showt...-issue-Joystick-hardware-not-recognized/page5)



SSOne 10 hours ago
After installing the 3.0 Beyond update my bindings no longer load, I get the following error in BindingLoadingErrors.log

There where errors when loading preset file: Aussiedroid Warthog Enhanced 3.0.2.binds
Failed to find GUID for device: 16D00A38

There where errors when loading preset file: Custom.2.0.binds
Missing devices: ThrustMasterWarthogJoystick, ThrustMasterWarthogThrottle

Anyone else get this? Or know how to solve it?

Everything ran fine last night before the update.




Hope it helps, AD
 
Last edited:
Back
Top Bottom