INC and DEC jumps by factor of 10

[bpieke]

Not sure if this is an old or new problem, but as FSX conversions come out for P3DV4, like the Carenado TBM850, I see a random pattern of knobs that are supposed to increase a P3D value by 1, suddenly jump in increments of 10 (Heading Bug) or 10000 instead of 1000 (Target Altitude).

This is using standard SDK variables/commands, like (>K:HEADING_BUG_DEC)

Has anyone run into this, and possibly know of an action?

[Rob McCarthy]

I recommend contacting the aircraft developer as well to see if they are aware of the issue.

Regards,
Rob McCarthy

[Mike Schroeter]

That is expected behavior that attempts to make setting certain gauges easier. For some inputs such as the heading bug, the system detects that you are rapidly clicking and assumes you want a big change. Click slower and you get the single increment. Without the larger jumps it takes a long time to rotate something like this 360 degrees.

This behavior has been around since the early years of MSFS.

Hope this helps,
Mike

[bpieke]

In that case, it detects incorrectly.. no matter how carefully I provide the input, it consistently multiplies by 10, when it has one of its "moods"...

In the case of the heading bug in the VC, when it misbehaves, I can go to a minipanel view where I have an HSI, and set the bug there in increments of 1. When I return to the VC, it also works correctly again.

You may very well have pinpointed the root cause, but there is a defect there - I can only assume it is buried in the FS/P3D code somewhere.. since I am using standard SDK commands.

[bpieke]

I recommend contacting the aircraft developer as well to see if they are aware of the issue.

Regards,
Rob McCarthy

I have also contacted Carenado.

[bpieke]

In FSX, I had a full version of FSUIPC installed..

It has a parameter

FixControlAccel=Yes

which fixed similar issues.

Here is what the FSUIPC User Guide for V5 says:

· Fix control acceleration is not currently implemented. If it seems necessary in P3D4 then a way to implement it will be
investigated, but it will probably need changed [sic] from Lockheed-Martin.

[WarpD]

I have found that control acceleration is usually caused by addons flooding input events. It doesn't matter what input events it is... if it's flooded enough to trigger the acceleration logic in the sim... then it will affect all items that are coded to support acceleration.

[bpieke]

The Control Acceleration may well be a red herring.. sorry!

I am beginning to see a relationship between leaving the mouse hovering over the knob and 10x behavior.

If I move the mouse away from the knob and back between wheel increments, I can make it increment in 1s.

I've asked Carenado to look into this.

[bpieke]

Update:

I was using standard SDK commands like (>K:HEADING_BUG_INC) and (>K:HEADING_BUG_DEC).

They have the problems that I mentioned.

Now, I am using the same code Carenado is using:

(A:AUTOPILOT HEADING LOCK DIR, degrees) 1 + dnor (>K:HEADING_BUG_SET)

and that works reliably..

Clearly, there is some incompatibily between Carenado's knob handling in the VC and the
standard SDK commands.

For now, problem solved. Issue closed.

[Pete Dowson]

I have found that control acceleration is usually caused by addons flooding input events. It doesn't matter what input events it is... if it's flooded enough to trigger the acceleration logic in the sim... then it will affect all items that are coded to support acceleration.

FSUIPC's option in FSUIPC4 fixed it by dynamically changing the detecting timing value to zero in FSX/P3D32bit code when the next command was different to the last, provided the new one is not an axis command.

The error in the 32-bit sims seemed to be that it assumed close arrivals of commands meant they were for the same action. I would hope that is fixed in P3Dv4, but perhaps not?

Pete