Pils

You just have to sync up the physical throttle levers with the virtual cockpit ones to regain control after ATS is disconnected, the throttle overlay is an aid for this, alternatively sweep the physical levers to full forward and then back to idle.

Please provide a full view screenshot.

What do you mean? Sorry I don’t understand. The default for what? Search for “control_wheel_steer”, it’s there.

I suspect it will interfere with the custom camera control in the Challenger, also it’s been reported as the cause of a multitude crashes to desktop. As it’s an unmaintained/abandonware product I would avoid it if I was you.

If you’re on radar vectors/heading (HDG) mode, it’s either required or encouraged, not sure which. But when on FMS navigation then under normal circumstances the system will take care of it for you, as @Graeme_77 has described.

I don’t think they’ll help as it has to detect an online network connection to disable the feature. It would be better for P2ATC to understand that temperature affects altimetry. Especially as this feature will be built into the simulator when version 12 is released.

Ask them.

May be easiest to upload to YouTube as unlisted video(s).

Bind a button/key to “confirm checklist item” (search for “check_item”).

Use the LSK L1 (first line) as the FROM.

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?