Throttle sync toggle does not respect reversed axes

[airforce2]

Hi Pete;

I'm using P3D 3.4.22 and FSUIPC 4.963 (same behavior also in 4.962a)

I have my throttle axes reversed in the joystick calibration page.

If I engage the throttle sync (with hotkey, or toggled using the control in the button programming page), my reversed throttle axes are flipped back to their unreversed state while sync is active, making full fwd on the power levers idle and full back max power.  When I hit the toggle again to disengage throttle sync, the axes go back to their (desired) reversed state.

Cheers

Bob Scott

[Pete Dowson]

8 hours ago, airforce2 said:

I have my throttle axes reversed in the joystick calibration page.

If I engage the throttle sync (with hotkey, or toggled using the control in the button programming page), my reversed throttle axes are flipped back to their unreversed state while sync is active, making full fwd on the power levers idle and full back max power.  When I hit the toggle again to disengage throttle sync, the axes go back to their (desired) reversed state.

Strange. All throttle sync does is copy one throttle value to all the others.

Is this something new in FSUIPC, or have you only just started using throttle sync or reversing your throttles?

Pete

 

[Pete Dowson]

Okay. I've verified this problem here.

Looks like it has ALWAYS been like this! Weird, no one spotting this all these years. Too late for FSUIPC3, but I'll fix it in 4.963c which will be up for download later today (DLL only -- in the Download Links subforum).

[LATER]

Arrggghhh! This is awful. The code for doing the syncing is very old. And it simply bypasses the REV option! And, yes, it has always been this way!

The clue was the fact that the normal axis logging doesn't show anything when SYNC is active. It gets the axis value written directly to the offsets instead, like an external throttle control program. I think this was to avoid unnecessary recursive calls back into the calibration routine

I'll add the REVerse check (only on Throttle 1 because that is the value copied to all of the others) before it writes to the offsets. It still won't be logged though.

Pete

 

[airforce2]

Thanks Pete.  Never saw this before, because I had never tried using the FSUIPC sync.  I have a custom hardware input handler that was managing that, but small differences in axis values, presumably due to DirectX calibration issues were bugging me.  The handler takes an input value from the hardware, applies a mathematical transform to convert the input to a linear transducer position, and then injects it into the sim with a virtual device driver.  When my sync code is active, the value injected on each throttle axis via the virtual joystick is the same for all axes, but apparently some sort of MS device calibration is being applied, and the values for the axes aren't equal by the time FSUIPC gets them.  Close, yes, but not equal.  So I decided to try the sync in FSUIPC and discovered this.

BTW, (I hate to ask) is the same issue present for reversed prop and mixture axes when "Throttle sync to sync Thr/Prop/Mix" is set?

Cheers

Bob

[Pete Dowson]

37 minutes ago, airforce2 said:

BTW, (I hate to ask) is the same issue present for reversed prop and mixture axes when "Throttle sync to sync Thr/Prop/Mix" is set?

Yes, it is all sync actions. They are all the same. I think I've fixed it properly here. I'll upload a fixed version for testing soon.

The other way of appyling reversal to axis inputs, through the add/multiply options via parameters on the axis assignment itself, wouldn't have been a problem because the values already reversed before trying to sync it. When done at the calibration stage it's a lot more complicated!

4.963c_TEST, soon. I'll post a link here.

Pete

 

[Pete Dowson]

Please try FSUIPC4963c_TEST.zip

Pete

 

[airforce2]

Hi Pete--no go with 4.963c--P3D (3.4.22.19868) crashes on startup consistently with the test version.  Never gets to the Scenario Setup page.  Reverted to 4.963 and it starts up again normally.

Last line in the FSUIPC log when it crashes is

FS UNC Path = "\\HUD\P3Dv3"

in a normal run the joystick scan would come next.

Regards

Bob

[Pete Dowson]

24 minutes ago, airforce2 said:

Hi Pete--no go with 4.963c--P3D (3.4.22.19868) crashes on startup consistently with the test version.  Never gets to the Scenario Setup page.  Reverted to 4.963 and it starts up again normally.

Last line in the FSUIPC log when it crashes is

FS UNC Path = "\\HUD\P3Dv3"

in a normal run the joystick scan would come next.

This is the exact same problem Sabrefly has. Can you check the last few messages in the pinned thread about new Joystick Scanning at the top of the forum please? i'm actively trying to sort it out. I need extra logging:

Debug=Please
LogExtras=x200000

and running 4.963d -- link at the end of that thread. Then show me the log please.

Pete

 

[airforce2]

Pete--I don't see a link to 4.963d anywhere in that thread.

Bob

[Pete Dowson]

9 minutes ago, airforce2 said:

Pete--I don't see a link to 4.963d anywhere in that thread.

Bob

The link is to "FSUIPC 4.963d_TEST.zip" and it must be there because Sabrefly has already downloaded it and run it!

I think it's in the last message on page 2.

I'm working on an extra few lines of logging, but so far it points to something actually going wrong INSIDE the EnumDevices function of Windows direct input (dinput.dll). I note you said "P3D crashes". Can you get any crash details, because Sabrefly couldn't.

What version of Windows are you using BTW?

Pete

. 

[Pete Dowson]

I've just asked Sabrefly to show a log from another update. i'mve nearly finished zeroing in, and it is starting to look like a problem with the Windows function I'm relying on. Are you using Win 10 too?

Anyway, since you can't find the links in that other thread, i repeat the very lst one here:

Please show me the log using this one: FSUIPC4963e_TEST.zip

So far I've only tested on Win 7. I'll see if I can connect my two game controller devices to my one and only Win10 PC. -- not easy. it's only got one USB port (it's a Surface Pro) so I need to free up a USB hub from somewhere ... :-(

Pete

[Pete Dowson]

Managed to test on Win10 ... and I get EXACTLY the same results. It's a Win10 bug!!!!

Drat. Win10 is the main one with the Joystick ID missing problems, and the very function I found which would enable it to be fixed is broken! :-(

Not sure what I can do about this ... I'll experiment here.

Pete

[airforce2]

Yep, Win 10, version 1607 (Anniversary Ed).  The Official Operating System of Purgatory.

If you still want error log info, I know I had some detail there, but that machine is shut down and I'm headed up to inspect my pillow now.

Cheers

Bob

[Pete Dowson]

1 hour ago, airforce2 said:

If you still want error log info

No, it's okay. I managed to repro the problem.

The work-around is to enumerate All devices, not just Attached devices.  Somehow they've broken the "attached" device checking in Win10, as it works fine in Win7. I've modified my code to cope, and will upload 4.963f to the DownLoad links subforum today.

Pete

 

[airforce2]

Pete;

One other thing I've noticed when tinkering with axis sync, is that if it is engaged with the synchronized axes out of sync, they remain that way until the "master" axis value is changed, at which time all the axes are written out the same as the master axis.  Not critical for me, but I'd recommend that the slave axes be actively set one time as part of the sync activation so that the axes are properly initialized into a synchronized state prior to master axis movement.

Cheers

Bob Scott

[Pete Dowson]

4 hours ago, airforce2 said:

I've noticed when tinkering with axis sync, is that if it is engaged with the synchronized axes out of sync, they remain that way until the "master" axis value is changed, at which time all the axes are written out the same as the master axis.

Yes, the threads dealing with setting the values in only activated by detectng a change in the input from the device.

4 hours ago, airforce2 said:

ot critical for me, but I'd recommend that the slave axes be actively set one time as part of the sync activation so that the axes are properly initialized into a synchronized state prior to master axis movement.

Not easy the way the architecture is, and I would have though hardly worth it. Surely there's really never a need to change the sync mode "on the fly"? If there is, why? I would reduce to idle on all axes before changing anything.

Pete

 

[airforce2]

Pete;

In my case, I have a "smart" sync coded that, when active, syncs the axes when the axis inputs are set close to the master axis for a second or so, and unsyncs them automatically if a throttle is moved out of the capture range (e.g. engine failure, use of inboards or asymmetric thrust during taxi etc).  So if I move a slave throttle axis slowly into the sync capture range, as soon as my code activates the sync, the slave axis freezes short of reaching the value of the master axis and becomes unresponsive to further axis movements.  Once I figured out what it was doing, I just coded the master axis to "wiggle" (briefly make a small temporary change and return it to its original value) after the sync is activated, forcing all the axes to line up with the master.  But it was something of a surprise to have sync active but the throttles remaining out of alignment until the master axis was moved.

It's not worth a lot of work...just thought initializing the axes to a synced state at activation would be simple.  It's easy enough to code around if you understand how it works.

Cheers

Bob

[Pete Dowson]

4 hours ago, airforce2 said:

It's not worth a lot of work...just thought initializing the axes to a synced state at activation would be simple.  It's easy enough to code around if you understand how it works.

Well, I'll take another look and let you know. If I see a way I'd need you to test it for me.

Pete

 

[Pete Dowson]

On 3/6/2017 at 5:46 AM, airforce2 said:

One other thing I've noticed when tinkering with axis sync, is that if it is engaged with the synchronized axes out of sync, they remain that way until the "master" axis value is changed, at which time all the axes are written out the same as the master axis.  Not critical for me, but I'd recommend that the slave axes be actively set one time as part of the sync activation so that the axes are properly initialized into a synchronized state prior to master axis movement.

I now realize I didn't really understand what you were getting at here.

When throttle sync is engaged, all 4 axes are immediately set to the current Engine 1 setting. That works fine here in all assignment modes I've tried, including both FS control assignment and Direct to FSUIPC assignment, with combinations of REVersed axes, and "NRZ" set axes.

It certainly doesn't wait before setting those other 3 axes. It is done immediately and internally by writing the current value for throttle 1 to the other three throttle offsets.

However, I have been experimenting here, and have found that when disengaging Throttle Sync, nothing happens visibly until you move one of the levers. With throttles 2-4 they will jump to their last actual axis position. I can't do much about that as I can't actually tell the axis what to send me. You'd need to approximate the sync'ed position manually before disengaging.

However, the throttle 1 axis was changing on disengaging sync too.  That shouldn't happen, so I checked and found the calibrated value used for synchronised throttles is actually different that the one used when they are not synchronised. Very odd.

I've corrected this in version 4.964b which I will upload soon for you to try. I'll post a link in this thread.

Pete

 

[Pete Dowson]

Please download FSUIPC4964c_TEST.zip for the test DLL, version 4.964b and let me know.

Thanks,
Pete