Oh, wow. Hadn't thought of that. What is the language behind this thing? Is it C? I'm familiar with C# and it looks a lot like that, but not quite. I'm pretty sure I saw a way to pull the axis values, so if the mapaxis can kick off a function I can definitely do this. I just need to figure out where all the parts go.

If I get it to work (probably not tonight) I'll post the function I end up using in case you want to play with it later (although, I'm sure you've already got it sorted in your head).

Not really sure, it seems like some sort of hybrid C language, but I am not a programmer (just a hack at best lol) so I may be wrong. Calling a function should be ok within the MapAxis (most commands you can as you can see in my script). Normally for me its just some trial and error to see what will compile then refining it down from there. Create a dummy function with some simple output and ensure it complies then build it up from there. Like with a lot of this stuff, there are many ways to do the same thing. If I think of anything else I'll let you know :)
 
Not really sure, it seems like some sort of hybrid C language, but I am not a programmer (just a hack at best lol) so I may be wrong. Calling a function should be ok within the MapAxis (most commands you can as you can see in my script). Normally for me its just some trial and error to see what will compile then refining it down from there. Create a dummy function with some simple output and ensure it complies then build it up from there. Like with a lot of this stuff, there are many ways to do the same thing. If I think of anything else I'll let you know :)

Wow, did that fail spectacularly. It works, in theory (and in test), but implodes in horrible ways in game. I'm pretty sure it's conflicting with your existing FA code, as at some point it would inevitably just stop working altogether.

On an amusing side note, spinning out of control in a docking bay is fun! :)

(I've commented it out for now. I may revisit later, but digging through all that code has my eyes crossed.)
 
I apologise in advance for what will certainly be a numpty question, but:

I use a Warthog (throttle+stick) but I've never installed any additional software, and just use Elite's default bindings (lightly tweaked).

What advantage would I get from installing the TARGET software and this script? I've really leery about messing with my setup, but I'm also insanely curious. It's been a bad combination in the past :)


Edit: I am indeed being a numpy, as all of this is answered in post #1.

Self:apply:LART
 
Last edited:
Wow, did that fail spectacularly. It works, in theory (and in test), but implodes in horrible ways in game. I'm pretty sure it's conflicting with your existing FA code, as at some point it would inevitably just stop working altogether.

On an amusing side note, spinning out of control in a docking bay is fun! :)

(I've commented it out for now. I may revisit later, but digging through all that code has my eyes crossed.)

LOL, sounds like you had a bit of fun :)

It shouldn't conflict with the existing FAOff functionality (unless you use the switch off course, otherwise should remain unused as such). Could try commenting out the function or FAOff mappings to test it out to be sure.

In the ED Bindings, it maps the key, and the button preference (Press or Hold). Depending on how you coded it, you could also try changing it to Press instead of Hold and see if that improves anything (sometimes its the simple things that just confuse the hell out of everything lol).

Happy to take a look, but will be AFK for a few days from this evening (as I mentioned before).


I apologise in advance for what will certainly be a numpty question, but:

I use a Warthog (throttle+stick) but I've never installed any additional software, and just use Elite's default bindings (lightly tweaked).

What advantage would I get from installing the TARGET software and this script? I've really leery about messing with my setup, but I'm also insanely curious. It's been a bad combination in the past :)


Edit: I am indeed being a numpy, as all of this is answered in post #1.

Self:apply:LART

Hey GreyAreaUK,

Yeah, OP probably covers most things. :) It's rather powerful and essentially, it can give you full control over how a button works, short presses, long presses, multiple keys to one button, combos, macros, LED controls, custom axis curves + more.

I have a combination of things used in the script and straight in the bindings file, but many choose to do everything through the script to keep it simple. Mostly the difference is that you will bind keyboard commands to the bindings in ED, but axes generally bind directly (but can be modified in the script for custom curves etc).

Being you already have your bindings setup in ED, it will likely need to be re-binded if you run a script over the top (so make a backup :)). The script will create a virtual device (combining both the Joystick & Throttle into a single device), which ED will see differently. Bind keyboard commands in ED, then in the script you map those same keyboard commands to a command in the script (so it all aligns). Then program the functions for each as much or little as you want.

A lot of the stuff in my script has grown rather complex over time, but loading it up will give you an idea how it all fits together (forgetting the finer details till you get a grip on it). Most stuff is commented to explain how it works and what it is to help.

Any questions, happy to help :)

AD
 
LOL, sounds like you had a bit of fun :)

It shouldn't conflict with the existing FAOff functionality (unless you use the switch off course, otherwise should remain unused as such). Could try commenting out the function or FAOff mappings to test it out to be sure.

In the ED Bindings, it maps the key, and the button preference (Press or Hold). Depending on how you coded it, you could also try changing it to Press instead of Hold and see if that improves anything (sometimes its the simple things that just confuse the hell out of everything lol).

Happy to take a look, but will be AFK for a few days from this evening (as I mentioned before).




Hey GreyAreaUK,

Yeah, OP probably covers most things. :) It's rather powerful and essentially, it can give you full control over how a button works, short presses, long presses, multiple keys to one button, combos, macros, LED controls, custom axis curves + more.

I have a combination of things used in the script and straight in the bindings file, but many choose to do everything through the script to keep it simple. Mostly the difference is that you will bind keyboard commands to the bindings in ED, but axes generally bind directly (but can be modified in the script for custom curves etc).

Being you already have your bindings setup in ED, it will likely need to be re-binded if you run a script over the top (so make a backup :)). The script will create a virtual device (combining both the Joystick & Throttle into a single device), which ED will see differently. Bind keyboard commands in ED, then in the script you map those same keyboard commands to a command in the script (so it all aligns). Then program the functions for each as much or little as you want.

A lot of the stuff in my script has grown rather complex over time, but loading it up will give you an idea how it all fits together (forgetting the finer details till you get a grip on it). Most stuff is commented to explain how it works and what it is to help.

Any questions, happy to help :)

AD

That's fantastic, thank you very much.
 
LOL, sounds like you had a bit of fun :)

It shouldn't conflict with the existing FAOff functionality (unless you use the switch off course, otherwise should remain unused as such). Could try commenting out the function or FAOff mappings to test it out to be sure.

In the ED Bindings, it maps the key, and the button preference (Press or Hold). Depending on how you coded it, you could also try changing it to Press instead of Hold and see if that improves anything (sometimes its the simple things that just confuse the hell out of everything lol).

Happy to take a look, but will be AFK for a few days from this evening (as I mentioned before).

AD

Here's the code snippets I ended up commenting out. First the function (which I stuck in AD_EDFunctions):

int axisUpdateFA() { // If Any Axis is 75% to 100% set FA Off, else set FA On
if(
(Axis[DX_X_AXIS].pos < -16383 | Axis[DX_X_AXIS].pos > 16383) |
(Axis[DX_Y_AXIS].pos < -16383 | Axis[DX_Y_AXIS].pos > 16383) |
(Axis[DX_XROT_AXIS].pos < -16383 | Axis[DX_XROT_AXIS].pos > 16383) |
(Axis[DX_YROT_AXIS].pos < -16383 | Axis[DX_YROT_AXIS].pos > 16383) |
(Axis[DX_Z_AXIS].pos < -16383 | Axis[DX_Z_AXIS].pos > 16383)
)
{
ActKey(KEYON+FlightAssist);
}
else
{
ActKey(FlightAssist);
}
}

(Note: The numbers are what I calculated the 75% +/- to be as the KeyAxis commands only trigger once when shifting over a boundary, and while they don't always report the same position they don't give a lot of wiggle room. I'm sure there's a function or property out there that will translate the actual position values into a percentage of max, but I had a hard enough time just figuring out how to read the position values at all.)

And then the KeyAxis commands you supplied got used as follows:

KeyAxis(&Joystick, JOYX, 0, AXMAP1(LIST(0,25,75,100), EXEC("axisUpdateFA();"), EXEC("axisUpdateFA();"), EXEC("axisUpdateFA();")));
KeyAxis(&Joystick, JOYY, 0, AXMAP1(LIST(0,25,75,100), EXEC("axisUpdateFA();"), EXEC("axisUpdateFA();"), EXEC("axisUpdateFA();")));
KeyAxis(&Throttle, SCX, 0, AXMAP1(LIST(0,25,75,100), EXEC("axisUpdateFA();"), EXEC("axisUpdateFA();"), EXEC("axisUpdateFA();")));
KeyAxis(&Throttle, SCY, 0, AXMAP1(LIST(0,25,75,100), EXEC("axisUpdateFA();"), EXEC("axisUpdateFA();"), EXEC("axisUpdateFA();")));

I decided to skip checking for the rudder as I plan to replace my thrustmaster rudder which I can't stand with a set of crosswinds next month, so would lose the functionality anyway.

In test this works great in test as it will keypress Z on turning and release Z on ending a turn. In game I had to go switch the FAOff command to hold instead of toggle. And after several rounds of fumbling it seemed to work... Except at some point it would just stop responding. Everything else worked fine. The script was still running, but hard turns or thrusts seem to stop sending the Z commands (which still works if you manually hit Z on the keyboard)..

At which point my geek curiosity just ran out of steam. I don't spend that much time in combat. This just seemed like a really cool idea to try out.

In any case, speedy recovery on the eye surgery. I'm actually envious. I would love to get rid of these glasses. :)
 
@Aussiedroid

hi mate,

how can i bind my F10 (Gameinternal) Screenshot Key to your L/G WRN (Silence) SteamScreenshot Button? I dont use the Steam / Nvidia Experience Shot...
Thanks, cheers :)
 
@Aussiedroid

hi mate,

how can i bind my F10 (Gameinternal) Screenshot Key to your L/G WRN (Silence) SteamScreenshot Button? I dont use the Steam / Nvidia Experience Shot...
Thanks, cheers :)

Hey!

Should only need to change the key mapping to (F10 -> USB[0x43]):

define TakeSteamScreenshot USB[0x45] // F12

Long press should still do Hi-Res ED screenshots.

Cheers,
AD
 
Hello Aussie,

sorry, that wont work as i like. it removes my center function of my HMD / HTC Vive...i would like to rebind the long pressed function...

any ideas?
 
Hello Aussie,

sorry, that wont work as i like. it removes my center function of my HMD / HTC Vive...i would like to rebind the long pressed function...

any ideas?


Ah yes I forget about the VR keys :)

The long press is on the following mapping:

define HighResScreenshot

If you change that from ALT+F10 to just F10 that should replace the long press instead.

Also, to make you aware, where there is the TrackIR center mapping on the up toggle on the Throttle base - this can be changed to center HMD devices instead for VR users. This would free up the screenshot button. In the EDSettings files there is a user variable you can change to '2' for HMD devices:

define HeadtrackPref 1

Just to add here, the default F12 is changed due to conflict with VA to CTRL+HOME. For non-VA users it shouldn't be any issues changing it back to F12 (but if you do use VA then change your HMD center to CTRL+HOME to ensure nothing conflicts). The mapping for this is:

define ResetHeadOrientation L_CTL+USB[0x4A] // CTRL+HOME

Few options for you depending on what you prefer :)

Cheers,
AD
 
Last edited:
Here's the code snippets I ended up commenting out. First the function (which I stuck in AD_EDFunctions):

int axisUpdateFA() { // If Any Axis is 75% to 100% set FA Off, else set FA On
if(
(Axis[DX_X_AXIS].pos < -16383 | Axis[DX_X_AXIS].pos > 16383) |
(Axis[DX_Y_AXIS].pos < -16383 | Axis[DX_Y_AXIS].pos > 16383) |
(Axis[DX_XROT_AXIS].pos < -16383 | Axis[DX_XROT_AXIS].pos > 16383) |
(Axis[DX_YROT_AXIS].pos < -16383 | Axis[DX_YROT_AXIS].pos > 16383) |
(Axis[DX_Z_AXIS].pos < -16383 | Axis[DX_Z_AXIS].pos > 16383)
)
{
ActKey(KEYON+FlightAssist);
}
else
{
ActKey(FlightAssist);
}
}

(Note: The numbers are what I calculated the 75% +/- to be as the KeyAxis commands only trigger once when shifting over a boundary, and while they don't always report the same position they don't give a lot of wiggle room. I'm sure there's a function or property out there that will translate the actual position values into a percentage of max, but I had a hard enough time just figuring out how to read the position values at all.)

And then the KeyAxis commands you supplied got used as follows:

KeyAxis(&Joystick, JOYX, 0, AXMAP1(LIST(0,25,75,100), EXEC("axisUpdateFA();"), EXEC("axisUpdateFA();"), EXEC("axisUpdateFA();")));
KeyAxis(&Joystick, JOYY, 0, AXMAP1(LIST(0,25,75,100), EXEC("axisUpdateFA();"), EXEC("axisUpdateFA();"), EXEC("axisUpdateFA();")));
KeyAxis(&Throttle, SCX, 0, AXMAP1(LIST(0,25,75,100), EXEC("axisUpdateFA();"), EXEC("axisUpdateFA();"), EXEC("axisUpdateFA();")));
KeyAxis(&Throttle, SCY, 0, AXMAP1(LIST(0,25,75,100), EXEC("axisUpdateFA();"), EXEC("axisUpdateFA();"), EXEC("axisUpdateFA();")));

I decided to skip checking for the rudder as I plan to replace my thrustmaster rudder which I can't stand with a set of crosswinds next month, so would lose the functionality anyway.

In test this works great in test as it will keypress Z on turning and release Z on ending a turn. In game I had to go switch the FAOff command to hold instead of toggle. And after several rounds of fumbling it seemed to work... Except at some point it would just stop responding. Everything else worked fine. The script was still running, but hard turns or thrusts seem to stop sending the Z commands (which still works if you manually hit Z on the keyboard)..

At which point my geek curiosity just ran out of steam. I don't spend that much time in combat. This just seemed like a really cool idea to try out.

In any case, speedy recovery on the eye surgery. I'm actually envious. I would love to get rid of these glasses. :)


Thanks for sharing the code mate!

I'll try to input this into my test scripts and have a play & see if I can get it working properly over the week. I'm out 12k lys from a station, but I think I could still test this in space safely (will make sure I am off a planet surface or something first lol). I have my roll mapped to my rudder pedals on my Crosswinds, so may need to try this with just pitch, yaw & throttle. In theory, I guess if it works for a couple then it should work for any combo though, so might try to get it working with just pitch and yaw combos and go from there. If its reliable with those axes, and still causes issues with Throttle then at least we might be able to narrow it down. I know my script has different axes curves for the throttle & joysticks so wonder if they might interfere?


PS - Surgery went well, and recovering quickly although looking at the monitor there are still some blur and halos around the text so limiting my time staring at it for the next few days. Still very happy with the result, although I still out of habit try to push my glasses up every now and then before realising I don't have them on any more & still go to take them off at night before bed without thinking lol. Old habits die hard! lol
 
So I just got my Warthog joystick (only) and I'm having a helluva time understand how to integrate it into my CH throttle and stick.

I understand that there is a way to make pips macro based on how long the button is held. Is that something that can be created in target, or is that a script/code-only setup?

Also, in my old configuration I had a button on my CH throttle serving as an ALT, which would be like a new layer on Target. So I had 4 "layers" if you will, with Shift, Alt, Shift+Alt, and neither. Is there any way to tell Target to use Alt or the Alt button from the CH throttle to activate the U, D or I layers? Right now it seems I can only drag and drop a button from my stick onto the layer configuration system.

Any insight or help would be wildly appreciated.
 
Hey H-H,

I think you might run into some limitations integrating the different controllers (but I haven't tried such a thing myself). What I can say, is that you can use combinations without using the built in layers U, D, I etc. I don't use the layers like that in my script, rather, I just do things like:

if(!Joystick[S4]) DO ACTION X;
if(Joystick[S4]) DO ACTION Y;

I haven't done any direct mapping to a keyboard command in the same logic, but it may be possible to do something like:

if(!L_SHIFT) DO ACTION X;
if(L_SHIFT) DO ACTION Y;

It would need to be tested out to see if that would compile OK. Above would assume you have mapped the left Shift key to something on your CH throttle/joystick (or just for testing use the keyboard first).

That may give you multiple mappings combining the CH (mapped to a keyboard press) & outputting something via the TM (using script code for macro/combo etc). If it does work then it may be possible to also map something in a TM script to a keyboard press, and do the same in reverse. I see it could get rather complex tho.

I've only managed to setup pip macros via script, but I haven't played with Target GUI for a long time so don't want to say its not possible - just don't know how it would be done.

Not sure if that is of much help to you (or if it would work at any rate). Was the only way I can think to integrate the two devices by explicitly calling the keyboard command somehow within the script, else the only other alternative I see would be to try to do button combos within the ED config/bindings (but that has its own limitations).

AD



PS - Fail Forward, if you are checking the thread still - I haven't forgotten your request above. Will hopefully get to try it out this week & see if I can get it working :)
 
Last edited:
Back
Top Bottom