Inverted throttle + idle detent not working

[RISCfuture]

Re: Virpil CM3 Throttle inverted axis

Just as a heads-up, 4.36 now allows for inversion of throttle axis

This is indeed true, however, when using the CM3 Throttle with the axis inverted in BMS (not in VPC Configurator), the idle detent doesn’t work.

Moving the physical throttle forward past the idle detent threshold causes the virtual throttle to go back into the cutoff position. Moving the physical throttle aft past the idle threshold causes the virtual throttle to move forward into the idle position.

I think the function of the idle detent threshold needs to also be reversed if the axis is reversed.

[Tumbler31]

@RISCfuture if i recall correctly, you have to set cutoff and AB detents after inverting the axis. They wont be automatically be inverted too

[RISCfuture]

@Tumbler31 Unfortunately, that didn’t do the trick. I launched BMS Launcher, reset the throttle axes to be unassigned, quit and relaunched BMS Launcher, bound the two throttle axes, inverted them, and set the detents.

The idle detent still works backwards. Moving the throttle backwards through the detent causes the in-game throttle to move to the idle position, and moving the throttle forwards through the detent causes the in-game throttle to move to the cutoff position.

[Tumbler31]

@RISCfuture said in Inverted throttle + idle detent not working:

I launched BMS Launcher

You’re using the alternative launcher? I’m guessing that then still needs an update. The in-game settings menu should work?

[airtex2019]

@Tumbler31 I think I reported this back in 4.36 … it’s very confusing, and maybe borken in a couple different ways.

Repro steps…

1;
set g_bUseAnalogIdleCutoff 1

2;
Set detents on the Setup / Controllers page.

Before pic:

3;
Go into Setup / Controllers / Advanced / Flight. Select ‘reverse’ checkbox for throttle axis.

Observe: the detents appear flipped, and the motion of the axis appears reversed. Seems legit!

But wait no that’s not right, because now both the detents and the range of motion are flipped, so it’s a double-negative… hmm…

4;
Enter 3D …

Observe: throttle motion is totally horked and unusable.

5;
Return to 2D setup screen. Re-establish detents with green on top, red on bottom. “oh I guess they were backward, wtf but ok”

6;
Enter 3D again …

Observe: throttle motion is less horked but still not right. Once moving throttle to near (logical) minimum, it sticks there, and can’t move forward again.

The [shift+3] overlay shows the correct logical throttle position. But the position of the 3d throttle lever (and the actual engine fuel flow) is out of sync with it.

[airtex2019]

Pic 1: Reduce logical throttle pos to flight-idle… note 3d throttle lever pos and 2d overlay pos … seems ok

Pic 2: Increase logical throttle a bit. 3d lever snaps back to idle-cutoff pos, but 2d overlay shows ~20%. actual jet fuel flow goes to zero

Pic 3: Panic and go full throttle … 3d lever stays stuck in idle-cutoff position … but 2d overlay shows full burner … actual jet fuel flow still zero

[airtex2019]

@Tumbler31 if it helps debug … I’m using a VKB not a Virpil, but symptoms are the same. I think the axes are all 16-bit [0-65535] range. (thinking, possible arithmetic-overflow if doing any math with int16 shorts)

actual realistic resolution is more like 11 or 12 bit, but iirc the HID layer reports [0,65535] or [-32768,+32767] logical range for all axes

I have some test code handy to output the HID report, if you need me to doublecheck that.

[Tumbler31]

@airtex2019 thanks for checking all this, all have a look. I also have a VKB and I thought it worked ok when I created this.

[airtex2019]

@Tumbler31 just to try to eliminate VKB/Virpil as a cause… I plugged in a Xbox controller, and mapped the Z-axis (the triggers) to throttle. everything I described above still repros.

but surprisingly, Joy.cpl shows the range of values is [0-65535] … and VKB joytester shows range as [-32768,+32767] (it was surprising to me, I assumed it would be an 8-bit range)

(in HID terms I think “physical range” is the unsigned int16 and “logical range” is the signed int16 … but I forget which of those you get from DirectInput API)

[Tumbler31]

@airtex2019 issue found, should be fixed in a next release.

dinput reads the values as long, and I think most devices will send 16bit. To prevent issues with some devices sending 0/+max and others -max/+max, bms forces the behaviour depending on the axis