EnQ

Unfortunately not yet; I didn't find enough time over the past months. In the meantime some manuals appeared online but I think none included detailed performance data so far.

It's hidden in the "Route Menu": Press the IDX key, enter the Route Menu, select FPLN Wind Update and press Send. Downloading the winds will take a while but eventually you will get a pending flightplan modification which adds all leg winds; confirm via exec and it's in.

TMP© just reminds you that you have temperature compensation applied. If you look at the regular legs page (not the direct-to page) you should also see a © behind every affected altitude. Seems like the direct-to page hides the "compensation character" (copyright, actually ). I'm not sure if that's correct; seems a bit weird that it's shown on one page but not the other?

While on local barometric pressure, the addon conveniently synchronizes left and right side settings using either baro knob. While on standard QNH a local barometric pressure can be pre-selected using the baro knobs, the pre-selected altimeter setting is displayed in white on the PFD. However, inconsistent to the behaviour while on local barometric pressure, the pre-selection is not synced between both sides, both sides can be set independently. When activating the pre-selected value by switching from standard QNH back to local pressure the active setting is synchronized again. I wonder if this is intentional or might be considered a bug. It seems more consistent to also sync the pre-selection between both sides.

Please correct me if I'm wrong but at least a few years back the saying was that you would need an Nvidia GeForce card with the proprietary drivers to have full support on Linux, AMD/ATI Radeon is not fully supported on Linux (and shows weird bugs on Windows as well). Personally, I always bought GeForce cards due to those known issues, so I can't tell if the situation maybe improved (but I don't remember having read any comments about improvements over the past years). I've recently read about other X-Plane addons having issues with 3D rendering on "AMD" as well, even on Windows (not sure if those reports referred to CPU-integrated graphics or dedicated GPUs), so maybe the issues are not even limited to Linux drivers.

That's expected and has been reported for some offline tools as well in other threads already. Actually, both issues (temperature effects/custom altimetry in general and the bug regarding broken synchronization to default datarefs) are not just about online services being incompatible but they are caused by the way the Challenger's altimeter (which is simulated separate from X-Plane) is being presented on X-Plane's datarefs. Those datarefs (basically a huge dictionary of simulation parameters and instrument readings) will currently hold unexpected values which can have an impact on any interfacing software (external tool, plugin or script). I think the emphasis on online services was only made because there it will not only be noticed by yourself but everyone around you as well, especially ATC (and thus affect other people which is always a bad thing and should be avoided). X-Plane 12 will introduce native support for temperature effects (see https://youtu.be/PfkG2osqVrY?t=606). I hope that the Challenger will be able to interface with that new XP12 feature correctly in the future. Once temperature effects have become a widely used standard feature (and do not require hacks any more) I expect all tools interfacing with X-Plane to be updated over time so they will eventually be able to read correct values again. The Challenger really is ahead of its time (not only regarding temperature effects).

I remember having completed building libacfutils and librain in a Docker container but I don't recall if I actually also put an .xpl file into an addon's plugin folder (it probably would have been the Zibo as it looks like librain can easily be swapped out). Arriving at that point already took at least a full afternoon (for the third time...) and while it was compiling I read deeper into the source code and found that the C code probably looks good already. There were at least 2 reports on Github and/or .org forums by other people who were faster and actually tested librain after the latest commits changing anything regarding Vulkan. According to those comments the plugin would successfully load into X-Plane but the effects were not displayed correctly. While the container was still building I looked into the shaders, got surprised about the complexity (as I said I have almost no clue about shaders) and stumbled across several websites trying to explain generic compatibility issues between shaders originally written for OpenGL and Vulkan. Unfortunately I could not find anything like a migration guide and everything just got more confusing the more I read. By the time the code finally finished compilation I just called it a day, the weekend was over and the next week XP12 got announced, so I simply abandoned the idea. As some private beta (developer beta?) appears to have started for XP12 in December (there's a protected release notes page in the knowledgebase) I doubt that it's worth spending any more effort on librain. I wasn't able to use librain for more than a year now so I can as well just wait for XP12.

From what I tested earlier today: Fuel can be injected (and withdrawn) by manipulating individual tanks through CL650/fuel/tank/mass[], it's just the default dataref for fuel that does not have any effect on the Challenger. Fuel will immediately start to distribute/equalize between linked tanks (nice to watch on the study panel). Depending on where FSE writes fuel values to it might be possible to transfer them to the correct datarefs using a script. sim/flightmodel/weight/m_fuel_total appears to give the correct readout, though. Payload weight can be set via sim/flightmodel/weight/m_fixed and CG can be modified via sim/flightmodel/misc/cgz_ref_to_default. Both these datarefs are the default ones, matching the Weight & Balance dialog sliders. I'm not entirely sure if that really affects the Challenger how it is supposed to but at least it did have an observable effect on ground.

Should it do anything else than just tune the frequency alone? I'm not sure if I'm doing something wrong (or if I'm just too impatient) but every time I've tried to fly an ILS approach on LNAV so far, the ILS did not seem to activate by itself although approach mode was armed. The frequency gets auto-tuned but I appear to need to manually switch the Nav Source. The course also always remains pre-selected at 0°, even after the ILS has already been auto-tuned. What I would have expected to happen from similar auto-tune functionality on other aircraft systems if I remember correctly: localizer course for the selected approach gets automatically entered into the localizer pre-selection window ILS identification is being displayed while still on LNAV (maybe I just did not find it on the displays?) localizer & glideslope indicators become visible when in range that sort of appears to happen if I change from LNAV to heading mode (blue bars?) if approach mode is armed, AP should switch automatically from LNAV to LOC & GS Maybe the Challenger's systems just work differently and don't do that? But I think it's more likely that I'm still doing something wrong or maybe I'm just still a bit lost on the displays. Would be good to have a confirmation if any of the points listed above are actually being performed by the Challenger and when/how that happens.

Alternatively, it should be possible to write a Lua script to help conducting test flights and record all needed data (plus a small tool to compute the values needed for PFPX from those data sets). I'm currently checking feasibility in respect to the time I personally have to not only come up with such a script but also perform all required flights (even with some degree of automation that's still quite time consuming). The Challenger isn't alone. It's just one more aircraft addon that has no or only inaccurate performance data in PFPX (my last purchases, iniBuilds A310 and Felis B742 have exactly the same issue), so I feel like (even when HotStart provides us with more detailed performance data) that's a reoccurring and quite annoying issue with most addons, so it would be good if there was some general (although time-consuming) solution. It's also probably best to wait for a few patches before starting such data collection as any tweak or bugfix to engine performance, FMS or autopilot behaviour may to some degree affect the collected data. The initial release probably isn't the best candidate to collect data from. While I have a lot of ideas I am missing the time to implement all of them (even in best case conducting the flights alone would probably take several days to complete). So do not take this as a promise that I will come up with something usable, at least not in the near future. After all, I still want to fly and enjoy the plane. Please let me know if you are aware of any previous (successful?) attempt to collect data from X-Plane this way or have a better idea. Edit: I've checked it and it seems to be feasible, even with the Challenger. It may even be possible to almost completely automate "piloting" the aircraft (although it would be very helpful to be able to trigger IRU realignment via a command as it's easy to knock out the INS by repositioning the aircraft). I still can't promise when (or if at all) I could have something ready, though.

I know that's cheating but maybe "Realignment IRUs Immediately" works? It sounds like that might happen in the real world as well. My wild guess is that one way (in the real world) would be to tow/taxi the plane to an area that's better protected from winds (e.g. into a hangar, maybe a runup area with blast shields would also be sufficient?). I've never tried if X-Plane simulates objects shielding from wind though (and it might just not do it, it's usually not important to simulate that), so maybe the "cheat" is the only option. As an afterthought... If X-Plane does not simulate wind shielding inside hangars etc. we can still control the winds within the simulation. So to simulate shielding from strong winds e.g. inside a hangar it would be possible to temporarily override the winds to be calm in ASXP and restore live weather after the alignment has finished.

If HotStart has such data and can share it, it would be helpful to have that larger dataset shipped with the addon or maybe just available here in the forums. It does not necessarily have to be converted into a ready-to-use PFPX profile by HotStart but unless the community gets access to such data (as a spreadsheet table, PDF, text file, whatever format) it's impossible for anybody to write such a file. I didn't try to feed the very short and limited dataset that currently comes with the documentation into a PFPX profile as (having seen tables from airliner FCOMs where performance data is provided on several pages) I suspect that data is way to limited to end up with some reasonable results in PFPX.

Is that confirmed? There were a few people on Github who managed to compile librain but that alone didn't seem to be enough. The last time I wanted to take a look if I can support in some way I actually managed to finally get it compiled (for some time libacfutils was a bit difficult to get working, that was already my third attempt). While everything was compiling (libacfutils takes a long time to prepare) I dug deeper into the source code and figured that it probably cannot be enough to just recompile everything as the shaders looked incompatible with Vulkan and looked non-trivial to port (which meant I would have to read deeper into 3D programming first). Just one week after that small success, X-Plane 12 had its reveal presentation and showcased weather effects and (if I remember correctly) giving credit to Saso for librain. I'm not sure if that means Saso also actively supported integrating the effects natively to XP12. At least it would have perfectly explained the silence on librain. The improved and native weather effects of XP12 are just around the corner, so I also immediately stopped pursuing any plans for maybe looking into it any further after that announcement (not worth the effort any more; it seemed I'd have to read so much about shader programming that XP12 is public when I might have finally achieved something). For the same reason I wouldn't expect any addon developer (including projects Saso is working on himself) to continue on librain. It's basically the same as for the weather radar (with what Laminar showed so far, my guess is that XP12 might drastically change weather-related APIs). Expecting that most users will switch to XP12 as soon as it is available, any effort put into what already is predictable to become just legacy support for XP11 now is basically a waste of time.

Maybe I am too much a developer myself as I am asking for use cases (and confirmation of my suspicions) as I identify feature requests. If "life is too short", why do you bother at all? I would simply fly at (real) daytime then, using real-time weather. Nothing to mess with, no issues at all. Problem solved with the easiest possible solution.

Care to explain why? I really don't get it but maybe it depends on the location where you want to fly. I may also be just too comfortable here in Central Europe. At least in Central Europe the weather is basically the same during day and night, it doesn't matter (in particular there's no real effect on winds, as far as I know). We also don't have extreme differences in temperatures (usually less than 10°C difference). But I understand that it can be more significant in other parts of the world... it may of course also pose issues to fly in polar climate where day temperatures are already very cold and night temperatures are so cold that they might make flying almost impossible (or at least impractical). But except for such "edge cases" (sorry if I really might have no clue about something here) I don't see how a time difference on weather data poses issues and becomes implausible.

I was also wondering how differences between sim weather injection and real-time weather affect the addon - I saw that a GFS download occurs and Saso also mentioned on last week's streams that the addon would know/figure out if it was parked in icy conditions over night (which is a very neat feature). It also raises some general questions about what happens if external data sources change, are being relocated or become unavailable (maybe after support for the addon ends) - it would be nice to have some kind of locally injecting/replacing the possibly missing or inaccurate data from outside the sim. Regarding the issue of flying in daylight: If you can live with temperatures being offset (real night temperatures at simulated day time), why not simply change sim time but keeping ActiveSky at real-time weather?

Unless bugs are involved, I actually like that the wheels behave this way if it's realistic. Maybe it would be a good idea to add "cheats" to the Challenger menu to quickly recover from common user mistakes that aren't as easy to figure out. For example there could be some "Realign Nose Gear (fix STEERING INOP)" item in a "Quick Help/Fix" submenu. Maintaining the educative style of this addon, this could be followed by a popup that explains the most probable cause why the situation occurred and how it should usually be fixed (plain text popup or maybe similar to the F/O checklist reference images). It might also make sense to provide that as a command or even integrate as part of a full "quick fix"/"reset failures" command (basically like a "panic button") in case it's caused by some controls issues like a broken joystick axis which the user isn't able to fix/diagnose immediately. One of the first things I tried when the issue occurred to me was to actually check if any failures were active and if there was such a "panic button"/"quick fix" option in the menu. I was flying offline and had all the time in the world to figure out the issue (took me ~20 minutes on Saturday; I even went into datarefs to check if I can override the wheel alignment). Other's might run into that issue for the first time while being under time pressure (e.g. flying online*, already having started the engines and received taxi clearance) in which case it could be much more annoying. *) Of course it's not a good idea to take a complex airliner, study-level or not, immediately online without previous exercise - but the issue may not occur on the first few flights but only some time later when the pilot no longer expects to run into such basic issues. Or it could simply be caused at random by wonky control input...

Plugins which require keyboard input (such as FlightFactor's Airport Visual System AVS to enter airport ICAO codes) are blocked from receiving WASD key inputs while "Use WASD keys" option is enabled. Temporarily disabling that option makes the other plugins usable again. I looked through all commands and datarefs but the option does not seem to be controllable from outside the dialog. Use cases: If there was a command to toggle that function, it could be quickly enabled/disabled by a key/button press. If there was a dataref (readable and writable) it could also be controlled with a specific target value from scripts, thus allowing the option to be disabled while a plugin window like AVS is open and reenabled when closed. read-only together with a command would also be sufficient as a script could figure out current state and just toggle it if the opposite state is needed It would be nice if this could be added in a future release, so the user settings dialog does not need to be interacted with two times every time a plugin needs blocked input. Thanks for an amazing addon, so far.

I had to fly a missed approach and pushed TO/GA on the throttle but did not advance the F/O Go-Around checklist. I repositioned for another approach and let the F/O start with the Before Landing checklist using the "check" command. The F/O started working and reading items from both checklists simultaneously, resulting in speed increase above flap limits. I "aborted" using the "restart all checklists" function from the menu and did not continue to use the F/O checklist function on that session. My expectation as a user would be that the F/O function is protected against simultaneous execution of multiple checklists does not start/resume the GA checklist if the go-around has happened several minutes ago (it's no longer wanted/expected at that point) In general, maybe it could make sense to have the F/O raise an interactive prompt (like the phone call/ground crew dialogs) and ask what should be done, if unclear. (Maybe that could even be used to call for a particular checklist?) Also, I'm not sure if "restart all checklists" was the correct command as it brought up the flight compartment checklist. There currently does not seem to be any way to simply abort/abandon checklists?

I'm not sure if it's really an issue with the Challenger itself but it's the first time I noticed that Windows 10 did an OOM kill. I tried to fly EDDF-LOWS yesterday, route: CINDY2L CINDY Z74 HAREM T104 WLD T702 OLETU DCT EBEDA L173 TITIG TITIG1R At a reproducible point on that route (between AMDID and TITIG, roughly 30 minutes enroute, during descend) Windows killed X-Plane as could be seen in the Windows Event Log (Windows Logs/System, source "Resource-Exhaustion-Detector", just after crash messages). It seems that Windows does not like to overcommit memory and exhausted the sum of physical RAM + swap/page file. X-Plane at that point was reported with more than 22 GB of "committed" memory. I could solve the issue by increasing swap space. During the next attempt X-Plane successfully passed the 22 GB mark of "committed" memory. After landing (~26 GB committed) I kept the simulator running without interaction, Challenger was idle but kept powered up by GPUs. I observed that the committed memory continued to raise significantly. When I quit the simulator about 30 minutes later the committed memory showed around 36GB (10 more than during landing). Actual used memory also increases but only very slowly and diverging from "committed" memory. This looks like there's some memory leak in my installation (at least something requests way more memory than actually required). As I never encountered OOM messages on my system before (I check the Windows event log after every sim crash - Edit: there were two previous instances of OOM kills, see below) and had no issues flying long distances all across Europe within the same sim session a few months back (VATSIM Worldflight) it's likely that the Challenger might have a memory leak. It could also be caused by SAM which I recently updated a few weeks ago but I've flown a lot (and long sessions) since then and only had one spontaneous reboot which seems unlikely to be related to an OOM kill. The Challenger is the only other big change to that configuration. Specs: 32 GB RAM, previously 8 GB page file, now increased to 24 GB Note that Windows does not display any message, X-Plane just closes. If it is related to the Challenger, then I would suspect several crash reports can be attributed to that OOM kill issue. Unfortunately users need to lookup the event log to figure out what happened. Edit: I searched the log and it seems I missed two more instances of OOM kills that happened in the past (over a period of 7 months). The Challenger definitely is more demanding and may just be a more reliable way to trigger that (previously rare) condition on my system but the fact that the "committed" memory keeps increasing that quickly although the aircraft is idle on ground together with plenty of crash reports on this forum makes me believe there could be more to it and there might actually be a memory leak. I will observe memory consumption further during the next flights and also compare it to other aircraft.

That left me puzzled yesterday as well, nose gear was rotated at a 90° angle with no apparent way to rotate it from the cockpit (that extreme castering might have been the result of parking brakes not set correctly during engine start, plane went into a spin for me...). The way I fixed it after reading this thread like 5 times was to just set nose steering off, and apply some slight thrust while slowly releasing toe brakes (I might have used differential braking as well) to start moving in the direction the gear is locked at. If you observe that situation from an outside camera the nose gear should slowly come back into a 0° forward position as you start rolling. It just took a few meters to realign the wheel. While still in motion try to arm nose steering again. It took a few attempts but I eventually regained control. Once the steering is active the tiller will also no longer be "jammed" but visibly move according to your input.