Misbehaviours in autopilot (MCP) commands?

[Pils]

Hi Tom/Jan,

I was doing some basic hardware integration with V1.5 (specifically using @VirtualCPT's excellent XMidiCtrl), and I noticed some results that may be considered bugs and/or misbehaviours, as follows:

1. Custom autopilot "toggle" commands leave 3D cockpit buttons depressed

Current behaviour: After binding custom command, e.g. ixeg/733/autopilot/HDG_mode_toggle for heading select, to keyboard key, when the key is pressed (command phase “begin”) the 3D cockpit button for HDG SEL is depressed and the mode is activated, as shown by the lamps and on the FMA. When key is released (command phase "end"), 3D cockpit button stays depressed, see below:

Expected behaviour: Using custom commands should have same effect as using mouse button on 3D cockpit manipulator, i.e. after releasing key, 3D cockpit button is returned to normal "out" position. Also, while key is held (command phase "continue"), 3D cockpit button stays depressed.

 

2. Using default autopilot "up"/"down" commands does not animate MCP controls and no sound is played

Current behaviour: After binding default autopilot command, e.g. sim/autopilot/heading_up (or airspeed_up, etc.), to keyboard key, when the key is pressed the heading value in the "window" is changed, however the corresponding 3D cockpit knob on the MCP does not rotate, and no sound is played. Same applies to course knobs when using default "obs1" or "copilot_obs2" radio commands (there's no custom ones that I could find), and surprisingly the custom "HDG_bug" IXEG autopilot commands. (And possibly others?)

Expected behaviour: Using default commands should have the same effect as using mouse on 3D cockpit manipulators, i.e. value changes in "window", knob rotates, sound plays.

 

3. Default vertical speed commands have no effect

Current behaviour: After binding default autopilot commands for vertical speed, e.g. sim/autopilot/vertical_speed_up, to keyboard key, when key is pressed the vertical speed does not change, nor does the 3D cockpit wheel animate or play sounds.

Expected behaviour: See #2 above.

 

For context, the default autopilot commands are often the first thing people will try to bind, and are also part of default or hardcoded configurations for some hardware, e.g. Saitek panels. Additionally, they have the advantage (over the custom ones of many add-ons) of "auto-repeating" when "held".

 

Any questions please let me know. Thanks!

Edited September 24, 2023 by Pils

[VirtualCPT]

Thank you for the kind words @Pils

[Pils]

One other quick note: Not really a "bug" per se, but I also think it would be good for consistency's sake to have custom IXEG autopilot commands for the IAS/MACH speed knob.

[tkyler]

Thx @Pils

I hope these didn't work in XP11 and then just "stopped working" in XP12 ???  We really haven't changed any of our manips / command structures.  I will say that I think a really comprehensive "hardware compatiblity pass" for these kinds of things....similar to the MU2 hardware pass, is warranted.  X-Plane has introduced tons of commands that weren't available when we coded this thing up...and we didn't tie into all of them at the time.  Of course hardware wasn't as prolific and as full-featured as it is now.....so we do have some catching up to do here.

As usual..this post is logged on my list.

We're prepping a patch now for the obvious stuff from the last week...and I suspect we'll go a few more weeks seeing what else turns up, and once I feel we're stable...then I'll set about with the hardware pass.  

I'm also preparing 'MU2 like" online docs...and we have over 1200 custom datarefs....no telling how many commands.  So it needs a good audit.

-TK

Edited September 23, 2023 by tkyler

[tkyler]

and TBH....this UI with the cockpit is over 10 years old.  There are a lot of things I want to redo for more "natural immersion"...so usability will get its turn soon.

-TK

[Pils]

3 minutes ago, tkyler said:

I hope these didn't work in XP11 and then just "stopped working" in XP12 ???

I'm honestly not sure, it's been too long since I was last using the plane in 11, I'm sorry to admit.

4 minutes ago, tkyler said:

I will say that I think a really comprehensive "hardware compatibility pass" for these kinds of things....similar to the MU2 hardware pass, is warranted

I'm sure that would be greatly appreciated by the sim hardware-loving community.  

5 minutes ago, tkyler said:

I'm also preparing 'MU2 like" online docs...and we have over 1200 custom datarefs....no telling how many commands.  So it needs a good audit.

Quite the undertaking, but it'll be worth it.  Another one to add to your list for consideration... sim/annunciator/clear_master_caution.

Cheers!

[Pils]

On 9/23/2023 at 4:23 PM, Pils said:

One other quick note: Not really a "bug" per se, but I also think it would be good for consistency's sake to have custom IXEG autopilot commands for the IAS/MACH speed knob.

A couple of other thoughts for when this thread is referred back to again... I think the manipulator for the landing light gang bar (whatever it's called) should be able to be "held" down with mouse (and command). And it would be nice if the CDU buttons were animated and had a higher texture resolution for the labels. (I've already mentioned the panel texture resolution in another thread.) Also, the TO/GA buttons and A/T disconnect buttons. I know it seems small but for me it's always the little attention to detail things that delight.

Thanks!

Edited September 25, 2023 by Pils

[Pils]

On 9/23/2023 at 4:33 PM, Pils said:

I'm honestly not sure, it's been too long since I was last using the plane in 11, I'm sorry to admit.

I'm sure that would be greatly appreciated by the sim hardware-loving community.  

Quite the undertaking, but it'll be worth it.  Another one to add to your list for consideration... sim/annunciator/clear_master_caution.

Cheers!

sim/flight_controls/rudder_trim_left & _right

[rosseloh]

I can confirm Pils' observations. As a result, when I was designing my own XMidiCtrl profile for this plane, I ended up doing direct dataref manipulation instead of using commands. Which, mind you, works fine (as long as it's the "ACT" dataref I'm using and I configure it to set back to zero when I release the button!), but it's "safer" to use commands because then any input limits can be controlled by you, the dev, rather than me guessing what those constraints should be. As an example, take the DH knobs. I can see from turning the knobs by hand that the limits are -20 and 999. But if I hadn't respected those limits in my XMC profile config, the knob will gladly keep going both down and up (and the EADI will happily show numbers above 999, though as expected it does blank below 0).

So what this brings to mind is, when you're doing your re-evaluation, consider adding bespoke commands for everything the user may expect to manipulate in the cockpit. And I mean *everything*, which luckily seems like we're already well on our way for (most devs wouldn't add dedicated commands for the coffee maker buttons, but you did!).

On the bright side, I've learned enough about the datarefs the 733 uses that I'm well on my way to being able to write a "persistence" Lua script (mostly so the lighting knobs are where I left them when I load in...), unless of course you'd like to add that functionality as well, which I would appreciate (but this is not relevant to the topic at hand).

 

For reference, the commands I specifically noticed weren't working as expected this evening:

• All default autopilot commands (like OBS1_up, airspeed_up, etc) would change the relevant value but not animate the MCP knob.
• Bespoke commands for MCP buttons (CO_toggle, SPEED_mode_toggle, etc) would press in, but not "press out".
• Bespoke commands for the Heading knob specifically I know didn't animate the controls. I did not test the other knobs except VS, which *does* work.

Those are the only ones I tested for sure.

Edited October 4, 2023 by rosseloh