Pils

Sounds like it. There’s no means for automatic deployment of reversers so that’s not it. It would also help to keep track of thrust mode selection in the FMS during your testing. P.S. I’ve split your posts into a new thread.

When Graeme says the copilot side needs to be in FMS2 he means as a navigation source, as shown on the left hand side of the PFD. It’s part of the navigation database. If you select an ILS (or LOC, I think) approach in the DEP/ARR page then it will know the frequencies to auto-tune when the time comes. This seems plausible. Unlike a Boeing or an Airbus, the Challenger will do a fixed 3° angle descent path (by default, it is overridable on a per leg basis), not an idle thrust descent. As such if you’ve manually put altitude constraints on the descent I’m not surprised they’re not exactly on the 3° path, as such the aircraft plans multiple step-downs and shows a TOD for each. There’s no need to “help” it along, it’s capable of VNAV descents all the way to the threshold. Include a screenshot of this situation if you’d like to learn more. It’s actually the opposite, if I am understanding the query correctly. Without VNAV the plane will descend to the altitude you’ve selected via the flight control panel (blue) regardless of what’s in the flight plan. With a VNAV-enabled vertical mode, even if the altitude you’ve selected is lower than what’s in the flight plan the plane will not descend past any constraints (magenta). So the throttle icons (“ghost throttle”) came up but when you move your throttle levers (what hardware?) there was no change on the overlay? That’s quite odd. The overlay should show you the position of your hardware levers when they are desynced from the virtual cockpit levers. You’re 100% sure you weren’t accidentally in reverse thrust mode as far as X-Plane was concerned? This is where a video would help also, but I’m linking to another post just for more of a description of the “ghost throttles”.

Yes, the X-Plane log. If you can reproduce the crash and provide steps to do so alongside the log that would be very helpful. Thanks for the aircraft log, that’s at least something to start investigating with.

Uh. Weird. Maybe it thinks weight isn’t on the wheels for some reason. Guess would have to check the Study window with the data busses to get the WoW sensor data output. And so on. What exactly was the starting position?

Or the default “control wheel steering”, whatever it’s called.

I don’t believe so. Just the side which is coupled to the active FD so it gives proper guidance to the autopilot. Under normal circumstances you should not need to manually tune any ILS frequencies.

Are you making sure to select TO thrust mode in CDU during descent (below 15k)? It would help if you could record and publish a video of yourself doing an approach and landing from ~10,000 ft. Also include a shot of your complete user settings. Thanks.

As you’re using a CPU at the very minimum of requirements I think you’d be expected to be using graphics settings (especially those that impact CPU, e.g. number of objects, shadows, reflections, etc.) set to the lowest level/off. Also, minimise/eliminate all other applications running on the computer other than the sim, e.g. web browsers, flight trackers, anti-virus, etc. Any room for change there?

Please provide Log.txt, thanks.

You already made your own thread? If not, please do so with log attached. Thanks.

You already made your own thread? If not, please do so with log attached. Thanks.

Can we have full Log.txt and detailed reproduction steps, inc. flight plan, please?

Unfortunately this looks like a well known bug with AMD’s Vulkan drivers on Windows (known by AMD for over a year). It can be triggered by addons that use low-level custom graphics rendering interfaces, addons such as the CL-650, Enhanced Skyscapes, Q4XP, to name a few. Most aircraft addons don’t do anything as sophisticated with their avionics rendering, for example, and therefore are not affected. Laminar Research and AMD are well aware of the issue, but AMD seem reluctant or unwilling to allocate the resources to fix it. More reports of this issue by users to AMD may help change their minds. We all hope that maybe LR can workaround the issue in X-Plane 12, but there’s no reliable way to do so from an addon developer’s side without significantly degrading the product’s functionality. This is really on AMD to fix. As you’ve discovered the choice to reliably avoid this issue is using OpenGL, or Vulkan on Linux if one is willing change platform.

Are you using an AMD GPU and Enhanced Skyscapes?

What exactly is the command you’re using?

https://discord.gg/FFRwaF88

That’s correct, it’s not implemented as like a few things it was deemed low priority. Maybe in the future. Thanks for the continued feedback.

Some icing improvements will come in the next update.

Delete the …/Output/caches/CL650/chart.db directory. This will reset your authorisation.

That’s normal and expected. They’re based on different, independent sensor inputs, for redundancy. And those sensors have different noise/accuracy/etc.

If air-to-air is on that page then that works via the Hoppie ACARS network.

You can’t use the email page, it’s not implemented (and won’t likely ever be), it’s just there for completeness as the real thing has it. Sorry!

Thanks. It’s known by the developer.

Sorry to hear about your trouble. Try with XPRealistic removed from plugins. If that doesn’t help, remove all addon plugins and try with a “clean” X-Plane. Thanks.

Please provide your own log, and reproduction steps.