Honeycomb Aeronautical Partnership -- Please fix input bugs

This makes sense to me it won’t work the same!

  • Mouse handling supports 3 events: press, hold, release

  • Starter switch on the start position supports 2 events: on, off

When looking at the default Alpha input binding in the protected WindowsApps folder, it shows:

  <Action ActionName="KEY_MAGNETO_START" Flag="2" ValueEvent="0">
    <Primary>
      <KEY Information="Button35">34</KEY>
    </Primary>
  </Action>

But when looking at the behavior file, which has all the default Asobo handlers for the cockpit elements, it shows in <Template Name="ASOBO_ELECTRICAL_Switch_Magneto_SubTemplate"> :

			<Condition Check="USE_STARTER">
				<True>
					<NUMSTATES>5</NUMSTATES>
					<INDEX_STARTER>4</INDEX_STARTER>
					<POS_CHANGED_CODE>(A:GENERAL ENG STARTER:#ID#, Bool) if{ 0 (&gt;K:SET_STARTER#ID#_HELD) }</POS_CHANGED_CODE>
					<STATE_COND>(A:GENERAL ENG STARTER:#ID#, Bool) ! and</STATE_COND>
					<ON_STARTER/>
					<ANIMREF_ID>0</ANIMREF_ID>
					<ANIMTIP_0_ON_PERCENT>0</ANIMTIP_0_ON_PERCENT>
					<ANIMTIP_1_ON_PERCENT>0.25</ANIMTIP_1_ON_PERCENT>
					<ANIMTIP_2_ON_PERCENT>0.5</ANIMTIP_2_ON_PERCENT>
					<ANIMTIP_3_ON_PERCENT>0.75</ANIMTIP_3_ON_PERCENT>
					<ANIMTIP_4_ON_PERCENT>1</ANIMTIP_4_ON_PERCENT>
					<ANIMTIP_0>TT:COCKPIT.TOOLTIPS.MAGNETO_START_SWITCH_OFF</ANIMTIP_0>
					<ANIMTIP_1>TT:COCKPIT.TOOLTIPS.MAGNETO_START_SWITCH_R</ANIMTIP_1>
					<ANIMTIP_2>TT:COCKPIT.TOOLTIPS.MAGNETO_START_SWITCH_L</ANIMTIP_2>
					<ANIMTIP_3>TT:COCKPIT.TOOLTIPS.MAGNETO_START_SWITCH_BOTH</ANIMTIP_3>
					<ANIMTIP_4>TT:COCKPIT.TOOLTIPS.MAGNETO_START_SWITCH_START</ANIMTIP_4>
					<STATE_MAX_TIMER>1</STATE_MAX_TIMER>
					<STATE0_TIMER>0</STATE0_TIMER>
				</True>
				<False>
					<NUMSTATES>4</NUMSTATES>
					<POS_CHANGED_CODE/>
					<STATE_COND/>
				</False>
			</Condition>

In other words, the hardware input is binding to:
KEY_MAGNETO_START

But the mouse handling is binding to:
SET_STARTER#_HELD

And this is where it is getting nasty to me: if this is not a coding error, it seems they have had to create a specific event just for handling the “HELD” state you’d typically get in keeping the mouse button down, but they are using the legacy event “START” which is a latch when using the hardware input.

I didn’t try it yet, therefore I don’t know if there is such event in the GUI, but you might want to try binding the Alpha STARTER position to SET_STARTER1_HELD (for engine 1)

Some issues are resolved but not all and still require experimenting to fix the issues.

Is there a list of unresolved issues?

They broke the Bravo trim wheel when they fixed the heading bug :roll_eyes: :face_with_raised_eyebrow:

Not quite true. It’s just that the acceleration that shouldn’t be there in the first place, is removed. Also removed from the trim wheel. The point is that there are a ridiculous amount of points to wheel through on the trim control. This should get some kind of fixed accelerator (with sensitivity setting).
Not a new bug (not even a bug), but an already existing weakness in the controls that has surfaced, I think.

You should not have to spin the trim wheel more than 1 revolution for it to respond. The trim worked perfectly before the last update. Microsoft has acknowledged it as a bug. Hopefully, it is an easy fix.

1 Like

Saw this topic in the Weekly Feedback Snapshot. Hoping fixes around this can also include the Bravo Trim Wheel being too insensitive as described here:

It looks like a lot of the issues have been solved. If there are remaining issues, please create a new thread for this so we can track it. Thanks!