Rodeo

Well, I just tried and got no errors whatsoever. Obviously you have to replace all files with a cycle ID in their header so they match, you can't just pick and choose, but Navigraph does provide all of those in their data. Lack of support from official HS/X-Aviation staff makes perfect sense though, I'm just pointing out it is quite feasible, provided you know what you're doing

Oh that's new. I did stop updating my default database manually a while ago, I guess I'll have to try again and see what happens.

Yes, by manually copying the files from Custom Data to Resources/default data/<whatever> (cannot remember the exact path off the top of my head). Definitely at your own risk, but quite feasible Regards, Tim

My bad-- I guess i just didn't expect an airport inn the middle of the route

macOS does provide useful crash reports that could help pinpoint the issue. Old crash logs are found in ~/Library/Logs/DiagnosticReports/

Did you fill and sign a handling request inside the FBO first?

(1) there is a discontinuity between MYGF and the rest of the route (2) you're requesting a waypoint along the route 5 miles before MYGF, but your route starts at MYGF -- a waypoint along the route before the route starts or after the route ends doesn't exist, to my knowledge

I think, if there is no visible ice on the airframe (in the case of the simulated Challenger here, you'd only have to look at the wings), you wouldn't need to use de-ice at all? Anti-ice is another thing, there are indeed guidelines for that but I cannot remember them off the top of my head. Regards, Tim

I think a Quick Start guide covering the FBO operations, the various user settings, use of hand signals and perhaps some of the most common issues covered in the pinned topics from this forum etc. should still be considered (even if it only comes in April or later). Regards, Tim

Not had any engine limiting issue yet, but this is somewhat ambiguous (IMO); to avoid running into this situation, we: shouldn't climb at slow speeds (i.e. using a lower climb rate if necessary to ensure we have enough airspeed) shouldn't climb at slow rates (i.e. using a lower airspeed if necessary to ensure we have enough climb rate) Regards, Tim

Ah, that makes sense, thanks

Actually it seems I was able to fully move the handle once engines were started. Very intriguing… anyway, as long as it works Regards, Tim

X-Plane does provide native scroll wheel manipulators since version 10.50 (they're used in e.g. the IXEG 737); I can even hack them in the .obj files myself but that doesn't benefit the community at large Regards, Tim

Many switches don't seem to have scrollwheel support (or at least it doesn't work on my end)? Thinking e.g. of the 3-position switches (lights, several switches on the overhead). Adding scroll support to those would be nice if possible Regards, Tim

No-one else can reproduce this?

I saw: …but aren't these type of limitations (maximum speedbrake extension on ground) implemented electronically? Here, the speedbrake handle itself seems stuck at 50%, as though there is some kind of hardware limitation preventing going past it -- is actually limited this way in the real aircraft? Regards, Tim

Turns out SimBrief was able to do that, it's available now

A 10-minute freeze is uncommon, but occasional drops below 20 fps may happen even with powerful systems. Might be interesting for the Challenger to adjust fuel flow based on the sim speed (which I suspect they already do for time acceleration, but maybe they're not using the one that accounts for time dilation)? sim/time/sim_speed int y ratio This is the multiplier for real-time...1 = realtime, 2 = 2x, 0 = paused, etc. sim/time/sim_speed_actual float n ratio The actual time-speed increase the sim has achieved - takes into account fps limiting. sim/time/sim_speed_actual_ogl float n ratio The actual time-speed increase the sim has achieved - takes into account fps limiting and time dilation if fps<19. …with the last one probably being able to work around the issue? Regards, Tim

I didn't mean the only global plugin installed by this user, I meant the only global plugin installed by the Challenger 650 installer.

I was reasonably certain it wasn't Gizmo, but since it's the only global plugin that's installed alongside the Challenger, by ruling Gizmo out, we can be 100% sure the problem is not related to nor triggered by installing Challenger; that's all.

Also, actually, the reason for the reject flight plan will likely be written to the Log.txt (might be easier to look at X-Plane/Output/CL650/CL650_Log.txt so you don't get generic X-Plane messages not related to the Challenger). Regards, Tim

Presumably this data specifically is not synced. But if you send the V-speeds from the CDU where you entered the correct data, both PFDs should get the speeds though. Edit: I suppose the fact that those inputs (like the actual landing weight) are not synced could be a feature (of the real aircraft), so that you can compared two different landing configurations side by side?

Would manually entering a custom N1 target via the CDU also work in this case?

If you quit X-Plane, temporarily move the folder X-Plane/Resources/plugins/Gizmo64.plugin to your Desktop, launch X-Plane, and load an aircraft (for example the default C172, the Challenger requires Gizmo to run), do you still have the log spam issue? Feel free to post another log if you do. Edit: don't forget to move Gizmo64.plugin back to X-Plane/Resources/plugins/ and re-launching X-Plane before attempting to fly the Challenger