Conflict between Fast Turn & normal assignment

[touchdown84 34]

Sorry to bother you again but I seem to have a bug when having a Fast Turn and a normal assignment to the same rotary, that also depends on the order of the entries in the ConfigDatabase_MSFS.xml.
This is with AaO 2.07 b12 and MSFS.

I made a very simple example to reproduce it with a Fast Turn and a normal assignment where on Fast Turn it should increase the heading bug and on a normal turn it should increase the altitude bug.

• When in the config xml the normal entry is before the fast entry (like in the xml example below), then on each input both HDG and ALT are increased, even when it's too slow for a Fast Turn.
• When in the config xml the fast entry is before the normal entry (the reverse of the example xml), then on a slow turn it only increases ALT as expected), and on a Fast Turn it increases HDG (as expected) but also ALT as well (what I would not expect).

Maybe it's possible to have a single assignment for normal/fast like with the Long/Short-Click option?

Thanks,
Jan

The example xml-snippet:

<buttons>
<GlobalHotkey>
  <downEvent>
	<Group>Autopilot</Group>
	<Description>Increments reference altitude</Description>
	<SimulatorEventName>AP_ALT_VAR_INC</SimulatorEventName>
	<MinValue>0</MinValue>
	<MaxValue>0</MaxValue>
	<ValueToSet>0</ValueToSet>
	<IsAaoVirtualEvent>false</IsAaoVirtualEvent>
	<type>SINGLE</type>
  </downEvent>
  <repeat>16384</repeat>
  <repeatFrequency>1</repeatFrequency>
  <joystickGuid>3e1d4070-447c-11eb-8001-444553540000</joystickGuid>
  <joystickName>Bravo Throttle Quadrant</joystickName>
  <joystickButton>12</joystickButton>
  <joystickPovControl>-1</joystickPovControl>
  <joystickPovDirection>-1</joystickPovDirection>
  <midiDeviceId>-1</midiDeviceId>
  <midiChannel>-1</midiChannel>
  <midiEvent>-1</midiEvent>
  <endless>false</endless>
  <midiEncoder>NONE</midiEncoder>
  <isSimKey>false</isSimKey>
  <comboSuppressesEvent>false</comboSuppressesEvent>
  <comboIsToggle>false</comboIsToggle>
  <longClick>false</longClick>
  <longClickTimeoutMs>0</longClickTimeoutMs>
  <fastTurn>false</fastTurn>
  <timeoutMs>0</timeoutMs>
  <assignedKeys />
  <vkModifiers />
  <vkKeys />
  <Action>AP_ALT_VAR_INC</Action>
</GlobalHotkey>
<GlobalHotkey>
  <downEvent>
	<Group>Autopilot</Group>
	<Description>Increments heading hold reference bug</Description>
	<SimulatorEventName>HEADING_BUG_INC</SimulatorEventName>
	<MinValue>0</MinValue>
	<MaxValue>0</MaxValue>
	<ValueToSet>0</ValueToSet>
	<IsAaoVirtualEvent>false</IsAaoVirtualEvent>
	<type>SINGLE</type>
  </downEvent>
  <repeat>16384</repeat>
  <repeatFrequency>1</repeatFrequency>
  <joystickGuid>3e1d4070-447c-11eb-8001-444553540000</joystickGuid>
  <joystickName>Bravo Throttle Quadrant</joystickName>
  <joystickButton>12</joystickButton>
  <joystickPovControl>-1</joystickPovControl>
  <joystickPovDirection>-1</joystickPovDirection>
  <midiDeviceId>-1</midiDeviceId>
  <midiChannel>-1</midiChannel>
  <midiEvent>-1</midiEvent>
  <endless>false</endless>
  <midiEncoder>NONE</midiEncoder>
  <isSimKey>false</isSimKey>
  <comboSuppressesEvent>false</comboSuppressesEvent>
  <comboIsToggle>false</comboIsToggle>
  <longClick>false</longClick>
  <longClickTimeoutMs>0</longClickTimeoutMs>
  <fastTurn>true</fastTurn>
  <timeoutMs>200</timeoutMs>
  <assignedKeys />
  <vkModifiers />
  <vkKeys />
  <Action>HEADING_BUG_INC</Action>
</GlobalHotkey>
</buttons>

 

Edited May 11, 2021 by touchdown84

[Lorby_SI 2,036]

At the moment, having two entirely different events on slow and fast turn is not supported. This logic is instead meant to emulate controller acceleration, so that you can make larger changes by turning the knob faster.

I will look into it, but I am not sure that what you want can actually be done in AAO. The "slow" and "fast" turn are not unique events that can be caught, they depend on how much time has passed since the first turn. But is that first turn a fast or a slow one? And what if you accidentally turn the knob slower or faster than you wanted to (when you run out of fingers) - you would change a completely different setting, unrelated to your intended goal. Personally, I'm not sure that this will ever work to your satisfaction.

Edited May 12, 2021 by Lorby_SI

[touchdown84 34]

The usecase you are describing is exactly what I want, I just used different events in the example to illustrate the problem better.

What I want is the e.g. the Heading to increase by 1 on a normal turn and faster, lets say by 10, on a fast turn.

Could you provide an example on how it is intended to be configured? Because when I only have 1 single assignment with Fast Turn, I get nothing for normal turns.
And when I make 2 assignments on the same event (e.g. I tried calling the same RPN script just with different values from both assignments) I get the behavior I described in my first post.

[Lorby_SI 2,036]

1 hour ago, touchdown84 said:

Could you provide an example on how it is intended to be configured?

ALT_VAR_INC and ALT_VAR_DEC with the value 100 on normal turn and 1000 on fast turn. Depending on how the timeout is configured, there may be the odd duplicate event, because a human operator usually can't turn the knob with the necessary precision. But on the whole it works quite well, even if you have to dial back a little bit. I have just tested it on my end, and I didn't pay any attention to what event has been configured first (slow/fast). 

This feature has been implemented as per customer request, and that person never complained. Overall people seemed to be happy with it, there haven't been any requests about this ever since (feature has been added in version 2.04) . Or nobody is using it at all, that is always hard to tell.

[touchdown84 34]

13 minutes ago, Lorby_SI said:

ALT_VAR_INC and ALT_VAR_DEC with the value 100 on normal turn and 1000 on fast turn.

I just tested tried that. That works (kinda, on a fast turn it mostly triggers the normal as well, so using 900 for a fast turn gives the intended result) when you create the Fast-Turn before the normal turn, such that the Fast-Turn is defined before the normal turn in the Config-XML.

But when you create the normal turn first (such that it comes first in the Config-XML), than you still have the bug I described that both actions are triggered no matter how slow/fast you turn.

So the logic is depending on the internal order of the assignments.

[Lorby_SI 2,036]

12 minutes ago, touchdown84 said:

So the logic is depending on the internal order of the assignments.

Weird. I will look into that. But you can always just assign the fast turn first, right?

Edit: I have double checked that the normal turn comes first in my config. Can't say that I see much of a difference. The fast turn may be quicker on the draw, so I may have to turn slower than I expected, but overall it works the same. Of course there are duplicate events, that can't be avoided. You would have to be a robot to turn the knob that way. And the first turn is always of the "other kind" anyway. That can't be avoided either - if I just omit the fist "click" of the rotary encoder, so the app can judge if you are turning slow or fast, people would complain too, because the encoder is not precise anymore (you need two clicks to make one small change).

I am testing with a Behringer X-Touch MIDI device btw. Maybe what you see is something specific to joystick events (assuming that the encoder that you use is sending joystick button events?)

Edited May 12, 2021 by Lorby_SI

[touchdown84 34]

I'm using the rotary on the Honeycomb Bravo, which is not a good rotary encoder to begin with, that's just registering as normal joystick buttons. So I'm not surprised that it works better with other devices.

At the moment, with the "fast"-assignments defined first, I got it working as good as the hardware allowsI think.
Also I got much better result using RPN-scripts controlling the increments, like:
(A:AUTOPILOT·ALTITUDE·LOCK·VAR,·Feet)·(L:0-KNOBS-ALT_INC)·+·(>K:AP_ALT_VAR_SET_ENGLISH)
Much less additional "slow" ticks on a "fast" turn than using ALT_VAR_INC.

Anyway, I think I got it working in a way I can live with now, thanks for the help.

Edited May 12, 2021 by touchdown84

[Lorby_SI 2,036]

21 minutes ago, touchdown84 said:

that's just registering as normal joystick buttons

OK. I cobbled together a similar "device" with a rotary encoder and a joystick button board, and I think that I know what is going on in AAO. What you are seeing is an inherent problem of the joystick logic. I need to think about that for a while, I have a feeling that by redesigning this, the overall logic may benefit. But on the other hand that may cost a bit of performance that AAO doesn't have to spare at that point. Tricky.