Coop

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.

We don't mess with any of the radios ourselves, its all handled natively by the X1000 system (in the case of the G1000 powered SRs) or the X430s (in the case of the Entegra systems). Yes, those datarefs should be written to by those systems.

Regarding those failures, that is likely just the interaction of the custom systems overriding X-Plane systems, and not true failures. The AOA and pitot failures would be on if the pitot/AOA covers were left on. Regarding the standby gyro, I've heard an other report similar to this but haven't been able to replicate on my end yet, but we are looking into it.

Yes - we're looking into adding it!

Both the X-Aviation activation plugin and cj_systems main aircraft plugin both aren't being found by X-Plane. If you are using third party antivirus software, make sure they aren't being quarantined, and then try re-running the installer.

We'll be integrating it once X-Plane provides the SDK for doing so!

Nothing was changed with this update regarding the RXP integration, perhaps you had modified some RXP config files with the prior install or with this one?

It looks like something is failing or interfering with the rendering layer in your install. Not sure what that would be as I haven't seen this before, but I'd recommend a reinstall, and if you are running any 3rd party plugins that mess with rendering to remove them.

That is expected behavior for starting the second engine. It uses a cross-gen start, so the starter relay connects for both engines, so the started engine drives the starter on the other engine to reduce load on the battery.

Thanks for these, I've got these logged. Regarding the SC/CP and selected heading/alt, those aren't persistent with the real units. Course is just as the way X-Plane and its navigators work and how it persists those values.

It's an odd artifact of the checklist we referenced from real-world usage. I'm thinking that is more set under the guise of that checklist is run before your VIPs show up for their flight, and you don't want to drain the battery while waiting for them to show up. Turning the battery on prior to start is something that is assumed knowledge from their type rating