Coop

On the Honeywell control panel, you would need to select "NAV2" as the source, and make sure the right side GTN unit is in GPS mode, not VLOC.

Yeah, the white area is the takeoff trim range. But, that doesn’t mean you should engage the AP with the trim there, if you are holding control pressure on the yoke, don’t expect the AP to take over seamlessly. The plane should be trimmed throughout the hand-flying phase of takeoff and initial climb, then with the plane in-trim, you can engage the AP when appropriate.

The STEC AP being used is the internal XP STEC. It is an incredibly dumb autopilot (as it is in the real world). It definitely is night and day in behaviors compared to modern APs (DFC90 with the Entegra, or anything Garmin, etc.)

With IAS mode, it should never descend even when trying to catch a selected airspeed, if the altitude preselector is above your current altitude (and vice-versa on descents). If it is that dramatic, then perhaps something maybe with trimming and your flight controls? VS is much simpler, much less logic going on, it is just targeting the selected VS. If its dramatically oscillating around that or diving before capture a positive VS then it sounds like your plane was not in trim before engaging AP.

The warning light is not turned on in those photos. What light are you referring to?

Can you send a photo showing what you are referring to, showing both that and the main annunciator panel?

There is no ADF equipped with that config, as modeled

Hi Omar, The power available has many different variables associated with it, and with the non-turbo-normalized version, available power decreases with altitude. I would recommend checking the maintenance tab for the aircraft as some cylinders could have failed as 54% power at max sounds like something has failed internally to the engine.

This bug is logged internally for the next update. This is due to X-Plane changing the brightness feature in the X1000 and some internals need to be shuffled to accommodate that.

Thanks for the report, I’ve got these filed

Can you try changing this setting "disable_mtuploader" to 1 in the file: "D:\X-Plane 12\Aircraft\X-Aviation\TorqueSim BN-2T Islanders\TorqueSim BN-2T Turbine Islander\plugins\is_systems\settings\settings.cfg"

This seems to be an ordering but with plugin disabling within X-Plane that can surface with some systems. I've got it logged internally to see if we can find a way to replicate it to come up with a fix or workaround.

I don't have the honeycomb myself, but if you can bind to just standard X-Plane controls, these are the hardware commands that you can use. This will respect the dual-press logic on some of the modes in the DFC90 (that is not present in the virtual cockpit, as you don't have two mouse pointers) afm/sr/cmd/dfc90_hw/fd afm/sr/cmd/dfc90_hw/hdg afm/sr/cmd/dfc90_hw/ias afm/sr/cmd/dfc90_hw/nav afm/sr/cmd/dfc90_hw/gpss afm/sr/cmd/dfc90_hw/vs afm/sr/cmd/dfc90_hw/alt afm/sr/cmd/dfc90_hw/gs afm/sr/cmd/dfc90_hw/level afm/sr/cmd/dfc90_hw/ap afm/sr/cmd/dfc90_hw/appr afm/sr/cmd/dfc90_hw/ias_dn afm/sr/cmd/dfc90_hw/ias_up afm/sr/cmd/dfc90_hw/ias_sync afm/sr/cmd/dfc90_hw/vs_dn afm/sr/cmd/dfc90_hw/vs_up afm/sr/cmd/dfc90_hw/vs_sync

Auto-positioning and auto-popups will not work without the monitor profiling via the main RealSimGear plugin <-> hardware interface, but there shouldn't be anything stopping manual popouts onto any monitor.

The main X-Aviation activation plugin isn't shown here as being found or loaded by X-Plane. Ensure it isn't deactivated or quarantined by any antivirus system you may be using.

That is likely something with the aircraft being used, specifically the autopilot model equipped in the virtual aircraft being used.

The first crash is during X-Plane shutdown. Try letting it sit in sim for at least 5-10 minutes, that is possible with Windows when the G500 is building its initial caches (Windows is really slow with file handling so can take a few minutes there) Second log doesn't show the G500 installed or running.

Correct, the volt rise is your only indication. The battery switch off step there is due to the way most operators fly the jet. Prep everything, then turn it off and wait for the passenger to show up in their limo

In order to debug what is going on, we will need you to send us a copy of the X-Plane log.txt file. You can find a guide to get this file here: How to find the X-Plane log.txt file?

Hm, the fuel only gets touched by us when the sliders are actively being moved on the load manager window, otherwise that would be something with X-Plane. I haven't seen this myself.

There are a few things internally we are going to try with a future update. Not really sure where it is breaking down, our current going theory its its something with the way the M1 Ultra works and something going wrong with threading when its split across the interconnect between the two connected chips.

I'm seeing some very odd values in the TN_State file for some of those entries, not sure if that is the cause or symptom. Can you delete that file (while X-Plane is not running, and then load back up?)

Hm, this isn't something we can replicate. What conditions/weather are you using, and what airport? If you load with clear default weather at PMDY airport, does it still do that?

Are you using X-Plane with the option checked for starting with engines running?

There are prerequisites to when the GS will actually arm (vs just getting LOC following with approach sensitivity). Make sure to only arm APR once the GS has started to be received.