Coop

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

If you open the aircraft in plane maker, you can modify the G1000 variant on the Expert -> Special Equipment -> Airframe page, where the current mode is set to "Cirrus". There may be ramifications for changing to the other variants in terms of GCU functionality, as that is something we haven't designed for on our end, but you can give it a go and see.

It looks like something is preventing the X-Aviation activation plugin from being loaded by X-Plane. We've seen some false-positives from Windows Defender recently so that is likely the case here as well. The next step is to remove the plugin from the quarantine in Windows Defender. To do so in Windows Defender settings: 1. Open Windows Security 2. Click on Virus & Threat Protection 3. See the Protection History Tab Here you will find the likely quarantined file(s) that should not have been quarantined. Restore the files and you should be back up and running.

That call only looks to have been reported once, it would repeat on each attempted engagement if that was the case. Most of the other forced disconnect methods typically will output to the log, but I'm not seeing any here which is somewhat indicative of the turn knob not being fully centered. What FD modes were displaying on the EADI?

What you posted above are the requirements for AP engagement. If it still isn't working, please send your log.txt file and screenshots showing both the EADI and the AP center pedestal.

This is fixed on our end and will be in the next update

Based on the log file, it appears that the gyro breakers are popped (right side panel, row 4/5, columns 6) they are labeled "VG1" and "VG2". This is likely triggered by how the systems ungracefully get kicked offline during an X-Plane CTD

The G5 follows the X-Plane NAV1/GPS1 source. You may be able to manipulate the .acf file as well as the objects to switch which is set to be primary, but that isn't something I've done myself.