Pils

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!

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.

Log?

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!

I moved the post to the Bug Reports forum. You can post here in the future.

Sending multiple emails isn’t going to do yourself any favours…

Not that we know of.

These will work well for the popular Thrustmaster TCA Airbus throttle quadrant. Thanks!

Is this a irl Classic quirk? It sounds quite dumb to reverse direction mid-turn.

Mod action: I've created a new thread for you; please don't post on unrelated threads, thanks.

You'll receive an e-mail, and there will be a post on the forum.

Y’all could also consider looking at Saso’s OpenGPWS.

It's in the panel texture buffer, so unless something really bizarre is happening, it's being rendered by the 733's custom instrument code. Why? Only @tkyler can answer that. P.S. I hope in the future the pixel density for the instruments is increased (though as these are meant to be CRTs--I assume--it would come down to what's necessary to give it an authentic analogue look, which probably involves a shader also), possibly when LR provide the custom avionics API?

Gizmo currently has no role in the (un)installation of X-Aviation published software, so that would be a huge change in its scope.

This one. And a bit of (c). Technically it’s a new purchase of the “Plus” product, with a substantial discount. If you didn’t receive a discount code in your email (check spam/junk), then you can email x-aviation support to obtain it.

X-Aviation have their own ways of doing things. The developers won’t be getting involved with SkunksCrafts to use theirs.

https://www.x-plane.com/kb/using-x-plane-11-addons-with-x-plane-12-on-mac-systems/

So we only really need it for the "Ready to Fly" state? That's understandable at least. If we use one of the other two as default state then it doesn't matter if the box is checked or not? Thanks.

Check your circuit breakers carefully.

For all pre-selected states? What's the reasoning?

No.

https://www.x-plane.com/kb/using-x-plane-11-addons-with-x-plane-12-on-mac-systems/

Maybe zoom out the screenshot a bit to show how everything is configured?

Going to be hard to solve with such little data to go on. Unfortunately Windows/X-Plane provide no real details of the crash in the Log.txt; it is just as possible to be some other plug-in or X-Plane itself crashing. Maybe you would consider removing SAM and SkunkCraftsUpdater first, both of which have been known to cause issues to general sim stability. (The latter can be removed permanently as they have replaced it with a standalone version.)