Unsolved Alternativce Launcher [TM Viper TQS/ButtonBox]: Some virtual DX keys don't trigger DX key in "awaiting input" field of key assignment dialogue
-
May be limited to TM Viper TQS or not. I have no other devices to compare. May be some kind of limitation that I didn’t catch in the documentation available (I didn’t read every page to be honest, shame on me ). Or I’m simply doing it wrong…things work fine at the end of the day because one can get away with press bar /release foo configuration, but I’m wondering if this is by desing, on purpose or a defect.
Version
4.37.3 / Falcon BMS Launcher 2.4.0 (x64) Vanilla Installation
Falcon BMS Launcher 2.4.1.3
Falcon BMS Launcher 2.4.1.4Build:
1329- Viper TQS with virtual buttons enabled
- T.A.R.G.E.T. software not running
Detailed Description
The TM Viper TQS and the ButtonBox can be run in two modes: a) without virtual buttons and b) with virtual buttons. Virtual buttons add DX mappings for switch positions that are non existent without enabling virtual buttons. Some of the virtual DX keys don’t trigger in the key assignment dialogue. Surprisingly they are catched by the Alternative Launcher as their keypress is shown in the ASSIGNMENTS help line in the lower left of the KEYMAPPING page.Two position toggle switches (e.g. UP/DOWN) work as follows:
In mode a) the toggle switch has a single DXn button mapping in the UP position whereas in mode b) the toggle switch has an additional DXn button mapping in the DOWN position.Examples:
A1. STORES CONFIG CATI (DX45), STORES CONFIG CATIII (mode b) DX59, else none) <- does NOT trigger
A2. LASER ARM (DX48), LASER OFF (mode b) DX61, else none) <- does NOT trigger
A3. JMR ON (DX49), JMR OFF (mode b) DX62, else none) <- does NOT trigger
A4. GEAR HANDLE UP (DX38), GEAR HANDLE DOWN (mode b) DX57, else none) <- triggersThree position toggle switches (e.g. UP/MIDDLE/DOWN) work as follows:
In mode a) the toggle switch has two DXn button mappings, one for position UP and one for position DOWN. In mode b) position MIDDLE has an additional DXn button mapping.Examples:
B1. RF NORM (DX46), RF QUIET (mode b) DX60, else none), RF SILENT (DX47) <- DX60 does NOT trigger
B2. PITCH ALT HOLD (DX52), A/P OFF (mode b) DX64, else none), ATT HOLD (DX53) <- DX64 triggers
B3. MASTER ARM (DX23), MASTER OFF (DX54), MASTER SIMULATE (DX24) <- DX54 triggers
B4. ROLL HDG SEL (DX50), ATT HOLD (DX63), STRG SEL (DX51) <- DX63 does NOT triggerSee https://ts.thrustmaster.com/download/accessories/manuals/Viper/Viper_Mission_Pack_User_Manual.pdf pg. 10 - 11 for reference of DX mappings and layout.
Reproduce trigger failing for a two way toggle switch:
- open Launcher
- click KEYMAPPING
Toggle switch Example A1 (CATI / CATIII)
- without opening a mapping dialogue
- without having any of the DX keys of that switch mapped*
ASSIGNMENTS help line (lower left) shows DX45: Viper TQS on UP and DX59: Viper TQS on DOWN
- double click any cell to open assignment dialogue
- move switch to UP position triggers DX45
- move switch to DOWN position does NOT trigger DX59
A1., A2. and A3. didn’t trigger their virtual button in the “Awaiting Input” field while being obviosly catched as a keypress as shown in ASSIGNMENTS help line in the lower left corner of the GUI. A4. did trigger fine in the “Awaiting Input” field.
Adapt the procedure to reproduce for three way switches. All positions of all three way switches are catched by the ASSIGNMENTS help line with their correct DX key but only B2. and B3. also trigger their virtual button (MIDDLE position) in the “Awaiting Input” field.
The problem is not limited to the ButtonBox. The Throttle handle DOG FIGHT and SPD BRK are also affected. On both buttons there seems to be some kind of a timing problem, tho.
The middle position (virtual button that is) of SPD BRK and DOG FIGHT does trigger sometimes but not reliable always. But this is the case in ASSIGNMENTS also.
The “more reliable” toggle switches outlined in the example above are triggering always in ASSIGNMENTS and either never in the dialogue or always in the dialogue.
I double checked the Thrustmaster Windows Joystick Panel to verify if any of the buttons itself could be the root cause. That is not the case. Every single button triggers fine according to the control lights in the Thrustmaster Joystick Panel.
Expected behaviour:
Either none of the virtual DX buttons should trigger or all of them.Notes:
While testing I noticed, that I actually have achived the currently impossible at some point in time. I tested stock Alternative Launcher that came with U3, 2.4.1.3 and 2.4.1.4, all behaved like outlined above. It only could have been in U2 or earlier, where I managed to get a trigger of a DX button that does not trigger now. I tend to U2, because this is where I chimed in with my TQS at earliest. Proof that what is outlined as “Example A1. NOT working” has been working someday (DX59 triggerd):[*] I noticed yet another misbehaviour if multiple DX keys are mapped on a single function (say, one release DXfoo and a press DXbar). The ASSIGNMENTS hint line does not show the correct DX values when a DX key is pressed. But i didn’t want to mixup two or three bugs in one report / question.
-
Just a couple quick notes… 1. I think Target needs to be running for the virtual buttons… (not sure)?
- There are some timing-sensitive issues in AL. For things like momentary-contact switches and rotary-encoders, you may have to try several times.
We’ll work on improving this, in future. But for now it is what it is.
-
@airtex2019 as far as I understand, virtual keys can be activated and deactivated in the Thrustmaster Joystick Control Panel (see below) . No need to run T.A.R.G.E.T. to use them. The lights for the virtual DX keys light up in the Thrustmaster Control Panel without running T.A.R.G.E.T. (only screenshot of btn 59 made):
I did a cross check with the VKB Joystick tester mentioned somehwere here. They show up there also (Example A1):
The AL is catching them reliably (besides the two on the throttle, different story) as far as the “ASSIGNMENT” line lower left of the AL window is a trustworthy source
-
@r00t ok I’ll take a closer look. definitely if one AL window can detect the input, the other should too
-
@r00t another quick point I meant to add … the UX for these “stateful” knobs and switches (ie. where 1 of a set of buttons is always ‘pressed’ state) is a little awkward.
I have a 4-way “mode” knob on my VKB, that is like this. If I want to assign, say, mode4… I first have to set it to the adjacent mode3 position, then doubleclick the callback I want… say, SimEWSProgFour (“PRGM Knob - 4”) … then, move the knob from position 3 to position 4.
(AL doesn’t have any knowledge that my buttons [51-54] comprise a mutually-exclusive set… all it sees is that I stopped pressing button 53 and started pressing button54.)
That awkwardness, combined with the nondeterminism (timing sensitivity) I mentioned, makes it a little frustrating… viz. if it doesn’t register properly, you naturally want to move it back to ‘3’ to try again but then (maybe) that press registers… so then you have to either close the dialog or click “Clear DX” and try again.
What’s weird, on my system, the key-assignment dialog is more reliable than the gridview… sounds like yours is the other way around. I’ll continue to look into it.
-
@airtex2019 That issue sounds quite familiar, I think it may be same thing we’ve talked just before u3 release. I’ll keep an eye on this one.
-
@airtex2019 Four and six way switch procedure puzzled me a bit the first time…AL inflicted some minor synaptic loss, but my brain recovered meanwhile
To be honest, it took me about 5 minutes and one forum post to understand what to do and why it must be done this way. Not that bad in terms of UX. I‘d say, don’t fix what ain’t srsly broken.
Mutually exclusive switches and buttons would involve Joe Average to manually group buttons. New UI elements and tons of logic to prevent us users from defining awkward things. I prefer the current, simple solution as long as it’s consistent.
Compare my 5 minute learning curve for AL to the two days it took me to figure out how T.A.R.G.E.T. works. And even there you have the very same issue. They are only hiding it behind complex UI elements in a way that you forget what bugged you five clicks before
It all boils down to the reliability and predictability of the data that is presented. I even can live with errors as long as they are consistent and predictable.
One thing that could be improved is the presentation of callbacks and DX keys in the ASSIGNMENTS help line. It tends to show only one of n mapped DX keys (not necessarily the one you pressed) and sometimes does not show the callback at all or does not jump to the correct section of the mappings list.
But that’s unrelated to virtual keys. It happens on all n-way stuff depending on various things. I think I cover that in one more bug report. But I need to,gather some data first.
-
@r00t if you get a solid repro case on that – stop, zip up your Config folder, and share it to me.
I heard another beta-tester describe something similar, but I could never repro.
-
@airtex2019 I think the behavior of not showing the expected ASSIGNENT in the lower left and not jumping in the corresponding line in KEYMAPPING is an easy one. To sum it up:
If you don’t assign a DX RELEASE and a DX PRESS event for two events that practically are fired always (two way switch like GEAR handle for example), and DX PRESS and DX RELEASE are not caused by the same DX button, ASSIGNMENT help line text freaks out if configured in one of two possible variants and the grey “active” thingy does not move to the entry in question
Multiply the level of confusion for toggles and knobs with >= 3 positions and having 4 of them not completely defined.
It’s related / caused by the defect outline in the bugreport above…kind of. I only stumbled upon this because I can’t properly assign all DX keys. But of course, as people are lazy, as soon as it works (in the Sim), they don’t care if it’s setup correctly. And it does work in the sim. It’s just the AL UX that goes fubar.
Tested with 2.4.1.4, config to reproduce can be found here: http://www.laosnet.de/falcon-bms/Config.7z
DX38 is a mode a) button, DX57 is a mode b) button, i.e only available when virtual buttons enabled. I cant eleminate the virtual button as root cause because there is nothing available on the TQS to achive that. It’s either two-way toggles (one being virtual) or three way toggles one being virtual unable to move from physical to physical without traversing virtual button position
- open AL
- click KEYMAPPING
- add PRESS DX mapping for UP position of a 2-way switch
- add PRESS DX mapping for DOWN position of a 2-way switch
- add RELEASE DX mapping for DOWN position of a 2-way switch (obviously the one used in 3.)
This rersults in
Move Lollypop UP:
Move Lollypop DOWN:
Note:
You may omit step 5… The result is the same as shown in the last two screenshots. It doesn’t matter if you define THIS one DX RELEASE or not. It’s just how my sample config (http://www.laosnet.de/falcon-bms/Config.7z) was as I wrote these very lines.Expected behavior:
Lollypop UP should readDX38: Viper TQS / Gear: LG Handle UP
AND should jump/highlight to the corresponding entry (which it does not),
More data for incomplete mapping. Replace Step 5. above with
5. add RELEASE DX mapping for DOWN position of a 2-way switch
This surprisingly produces the same results as if you are doing it “properly”, i.e. assign ALL events that occur in the sequence:
- open AL
- click KEYMAPPING
- add PRESS DX mapping for UP position of a 2-way switch
- add PRESS DX mapping for DOWN position of a 2-way switch
- add RELEASE DX mapping for UP position of a 2-way switch (obviously the one used in 4.)
- add RELEASE DX mapping for DOWN position of a 2-way switch (obviously the one used in 3.)
Move Lollypop UP:
Move Lollypop DOWN:
Expected behavior:
Lollypop UP should read:DX38: Viper TQS / GEAR: LG Handle - UP
Jump/Highlight entry works in this configuration.
Importand note:
When moving GEAR DOWN and all events are defined, ASSIGNMENT showsDX38: Viper TQS / GEAR:LG Handle - DN
for about 500ms before showing the final DX57 shown in the last screenshot. Can’t screenshot this because of race condition with my hands ;). This is kind of another bug. Lollypop UP should read DX38:…and Lollypop DOWN should either read DX38 RELEASE and DX57 (but then I’d expect a DX57 RELEASE on UP also) or no DX38 at all. The DX key finally shown seems to be the one that is last in the list of DX keys. Sorting is done by AL, no matter in what order I press/release them in the dialogue, they always end up in the order shown above. The callback is correct, tho.
The problem with “doing it properly” is outlined in the bug above. I’m unable to define every part of the sequence (i.e. RELEASE switches) for most of the virtual DX keys on the TQS because they don’t trigger in the Assignment Input Field…confused? I am.
-
@r00t
AL’s approach to input-handling polls for async device state (asking “which buttons and keys are down, right now”) , on a 30ms timer – and looks for differences between “now state” vs previous timer tick.Then, yes there’s also a ~1 second clock which is meant to drive the “flashing” UI text… which may be responsible for the superficial part of this bug.
I do plan to improve and simplify all this timer-logic, but it’s a pretty fundamental change – not a quick bugfix.
For now, I say simply avoid doing that? viz. don’t define separate ‘press’ and ‘release’ behaviors on buttons that are part of a mutually-exclusive grouping – it’s meant for cases where there’s not going to be roughly simultaneous button2down+button1up events.
(But thanks for the continued deep-dive bug reporting.)