Anyone know how to detect the Shift key without hardcoding the key in your script? I'm trying to think of ways to make my code more portable for others. People like to use different shift keys, like the Nosewheel button and Paddle.

Here's a use case:



So instead of Joystick[S3] I want to detect whatever the Shift key is. I suspect it involves layer() or layer_sw[] somehow.

I don't know if what you ask is possible. At least the way I'm understanding your question. The following line should be near the top of your script:



Whoever's using your file can change the S3 to whatever they want, then move what was on the button they're using to S3. But I can't think of a way to automate this.

Yeah, there's a lot of bitwise math in the IO and UMD code, it's not easy to grok unless you recently took a computer science course.

I could simply use some alias variables, and abstract things that way. That might be the simplest solution, which is usually best.

Like so:




Not tested btw, that code might not work.

You can define the shift (and UMD) button to be whatever you want with "SetShiftButton"?

Yeah, you can define the shift as whatever you like. That's the issue... my code checks for MY shift button in several places. Explicitly it checks for Joystick[S3]. If a user wanted to change their shift key, they would have to go thru all kinds of code looking for all the occurrences of Joystick[S3] and replace them with whatever shift key they used.

Look at my example... perhaps it requires some explanation.



That doesn't work. MapKeyR remembers the state of the key when pressed, and sends the IO key of whatever it was when pressed. So pressing shift on the Release never fires, because it was in the O state when pressed. I needed a way to disable the key, regardless of what I programmed on the MapKey part of the key.



That checks to make sure my IO button is NOT pressed before PressSomeButtons. If the IO button is pressed, it does nothing. This allows you to fix those switches that get out of sync with your game. For instance, gear Up/Down on a switch. You die, then start on the runway with your switch in the Gear Up position. Instead of doing all kinds of awkward workarounds, I fix this by disabling the output when shifted. My code does this on several switches that hold position, because its the best way to fix them while in-game.

Now, instead of "if (!Joystick[S3]" I want to detect the IO key, no matter what key it is. This kind of thing isn't in the Target manual, it's buried deep in Target.tmh somewhere.

Ok, I think I have it



My Warthog isnt connected at the moment, so cant test. I'm assuming you can call a function with MapKeyR.

So maybe combine this with a logical flag so you can have one place to set your shift key.

Can you make an LED on the throttle light up when shift is pressed as part of these scripts?

Re turning on LED due to state of Shift key

You should just be able to do the following, but when I tried this in the past, I don't think it worked as well as I would like (or at all?). I'm using the Throttle MSP key for my shift key.



If the above doesn't work, or if you want to do more special control over the state of the shift key, in your EventHandle(), do the following. This can work with any key if you want to add special coding that is real time and does not play well with an EXEC() on a MapKey() function.

My shift button is the MSP button on the Warthog Throttle.
&o is an alias for the device (e.g. &Throttle or &Joystick).
x is the button that caused EventHandle() to be called (the shift button is what we are looking for)
o[MSP] gives the current state of the MSP button. Pressed = 1, unpressed = 0.
The two ActKey() calls are right out of the script manual for turning LEDs on and off.

Re: identifying the shift key without knowing what it is....

Yes, layer_sw[0] stores the value you are looking for, but how to use it is confusing. You have to understand the mapping of the &(devices) (e.g. &Joystick and &Throttle).

First some background. Bear with me here. Let's assume you have a Warthog Throttle and Joystick plugged in only (no other Thrustmaster devices). I'll use the Throttle as an example and the Throttle MSP button as the IO shift button.

&Throttle and &Joystick are simply referencing the memory addresses for joy1[0] and joy2[0]. Go look up joy1, joy2, etc. in hid.tmh (short joy1[296]). They are 296 element arrays of type short (a 16 bit or 2 byte integer). As each device is initialized by TARGET, the device is assigned to point to joy1, joy2, etc. in the order the devices are initialized. This is shown in the TARGET script editor output window as something like:

1: "Throttle - HOTAS Warthog" - "USB\VID_........"
2: "Joystick - HOTAS Warthog" - "USB\VID_......"
USB HID device "Throttle - HOTAS Warthog" (USB\VID_.....) selected
USB HID device "Joystick - HOTAS Warthog" (USB\VID_.....) selected

In the above, the Throttle is selected to be joy1, and the Joystick is selected to be joy2. It is the "selected" line that actually indicates a joy1 or joy2 has been assigned, not the 1: and 2: lines. For example if you used Configure(&Joystick, MODE_EXCLUDED); at the start of your script to exclude TARGET from using the Joystick, you would see:

1: "Throttle - HOTAS Warthog" - "USB\VID_........"
2: "Joystick - HOTAS Warthog" - "USB\VID_......"
USB HID device "Throttle - HOTAS Warthog" (USB\VID_.....) selected

No "selected" line for the Joystick. Only &Throttle points to joy1.

What is joy1[] or what is Throttle[]? Both represent the same thing - Throttle is an alias of joy1 meaning both are interchangeable. Hence Throttle[] is a 296 element array of short, and points to the same array as joy1[]. Being an array, we can access elements as Throttle[1] or joy1[1]. Both will return the same value as they are aliases of each other.

MSP is our current IO Shift button, and MSP = 1 according to the define statements in defines.tmh (define MSP 1). So Throttle[MSP] is the same as Throttle[1], and always contains the current state of the MSP button (1 means MSP pressed, 0 means MSP released).

So how do we use this to determine what the current IO shift button is without knowing?

&Throttle is the address in memory of the Throttle[] array. The & simply means "the address of". So &Throttle is the address of Throttle[0]. Since Throttle[1] is the value of the MSP button, &Throttle+2 is the address of the value of the MSP button. Why 2? Because Throttle is an array of short, and each short is 2 bytes long. So the address of Throttle[0] is &Throttle, and the address of Throttle[1] is &Throttle+2.

layer_sw[0] contains the address of the current IO shift button. So layer_sw[0] = &Throttle+2 when the MSP button is the shift button. If you assigned FLAPU as the IO Shift button, then layer_sw[0] = &Throttle+42 because FLAPU = 21 in defines.tmh.

Try the following. Add this to a script file and run it (add it anywhere before the end of main() and run the script and it will print out in the TARGET Script editor window).



The result will be memory addresses in hexidecimal. For example, I got the following:



The && is needed to properly use &Throttle in this case because we want to work directly with the value of &Throttle. Forgive me, I'm a little off on my understanding of & and &&, but I know how to use them.

So if you write a routine that can calculate and find out that layer_sw[0] = &&Throttle+2, then you know that the shift button is MSP.

Where you go from here depends on how you want to use this. That is why I explained it instead of just writing some code to do what you need. Now two examples - a complex one using EventHandle() and a simple example.

If you knew what the shift key was, you could simply use it in a script like my example above in the previous post to turn on/off the LED where I used o[MSP]. This is the same as saying Throttle[MSP]. But we don't know that it is MSP. We do know the address for the IO Shift button is layer_sw[0]. So we can get the same result with Throttle[layer_sw[0]-&&Throttle)] assuming we already knew that the IO shift key was on the Throttle. So in your EventHandle() routine, you could do the following:



Again, this assumes we know the IO Shift key is set to the Throttle (more on that below). In the above example, the user set IO Shift as the MSP key. I use an ActKey() in main() to turn off LED1 just to make sure it is off for the purposes of my example.

Anytime any event occurs (a key is pressed or an axis is moved), EventHandle() is called by the TARGET FAST service and passed the following:

- alias o is the device, so &o is the same as &Throttle if a key was pressed on the Throttle.
- x is the event that happened. E.g. if the MSP key was pressed, x = MSP = 1.

int ShiftButtonVal = (layer_sw[0] - &&Throttle) >> 1; calculates the value of the button that is the shift key. In this case, with MSP as the shift key, ShiftButtonVal should equal 1 now. (layer_sw[0] - &&Throttle) = 2, and the >> 1 effectively does a divice by 2 (a bit wise right shift by 2 bits performs a divide by 2).

Then we just use ShiftButtonVal as if we were saying MSP. ShiftButtonVal is interchangable anywhere you would say MSP.

If you want to use int ShiftButtonVal = (layer_sw[0] - &&Throttle) >> 1; globally, then you need to do the following - define ShiftButtonVal before main() and then calculate ShiftButtonVal at some point before you try to use it. Here's a simple example.



To do this with the UMD mode button, you would use layer_sw[3] for the U mode button and layer_sw[6] for the D button.

The only thing left is to figure out which device the IO Shift button is on. TARGET only supports 9 different controllers, so you could just brute force an if else routine to figure it out. The trick is to understand that layer_sw[0] is a number that is no greater than 296 * 2 from the address of joy1, joy2, etc. So you could update FindShiftButton() above with the following:



Putting it all together, here's my original EventHandle() routine using this to figure out when an unknown IO Shift key is pressed and turning an LED on and off as it is pressed.



Lengthy reply, but figuring this out as I wrote it helped me with greater understanding of &Throttle, &Joystick, joy1[], joy2[], etc. which is something I was working on this weekend anyway. The mud is a little more clear now.